This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2023-03-19
Channels
- # alda (1)
- # announcements (2)
- # babashka (14)
- # beginners (30)
- # biff (12)
- # clerk (2)
- # clj-kondo (18)
- # clj-on-windows (1)
- # clojure (98)
- # clojure-europe (9)
- # clojure-gamedev (4)
- # clojurescript (39)
- # conjure (1)
- # data-science (1)
- # emacs (25)
- # events (1)
- # fulcro (1)
- # hyperfiddle (13)
- # lsp (3)
- # malli (1)
- # membrane (10)
- # off-topic (12)
- # reagent (7)
- # scittle (21)
- # shadow-cljs (10)
also, what magit ediff command do you like to run to handle merge conflicts? smerge-ediff?
From a magit-status buffer and with point on a file that has a conflict, magit-ediff-dwim
(`e` by default)
It splits the screen in four quadrants,
A B
Merged Ancestor (C)
and opens a second, tiny frame that controls the original. You navigate with p/n (previous/next conflict chunk) and select the version you want with a/b/c. If you want more control, e.g. combine A and B, you can modify the merged buffer directly.
When you're done you quit (q)
It's quite handy for resolving conflicts and because it's semi-automatic it helps you avoid messing up >>>
s or <<<
sHaven't really used smerge. Back when I was figuring out which approach to use ediff seemed better to me but I don't remember why.
It might have been because smerge uses git's terminology (mine/other) which confuses me and the key chords are a bit awkward. :thinking_face: Edit: Magit's guide doesn't hold your hand but it did help me decide https://magit.vc/manual/magit/Resolving-Conflicts.html
I really like a smerge-mode. I tend to use smerge-keep-current
a lot. I disliked the separate frame that ediff opens and have disabled that (see https://emacs.stackexchange.com/questions/17064/never-create-frame-in-ediff). In the end, I use both. Smerge is really convenient for quick and easy merges, but when things get more complex ediff is better at highlighting the differences ...
5 seconds seems pretty abnormal. Is your project very large? IME the speed of buffer updates when switching branches ultimately depends on the amount of changes between two branches. e.g. if I switch away from a branch that changed dozens of files, then that takes longer than switching away from a branch where I changed just a few files
this happens on a project with nearly nothing in it.
i'm running on linux.
How would you profile this?
Ty @U0B1SDL67 I'll give that a try.
as for merge conflicts, I just open the file directly and solve them by hand 😄 magit will place some thing like
<<< UPSTREAM
code here...
>>> BRANCH
code here...
and then I see how to tie the two together, if possibleby hand is fine, just seeing if there are more options.
I typically use the basic smerge commands (not the ediff stuff). On my machine (and, I believe, by default) they’re on C-c ^. You can navigate between conflict markers, choose any of the three versions (or a combination), refine the conflict down to the exact changes, etc. IMHO, it’s definitely worth the (learning) investment.
I recently decided that I want to use en-dash – like this – for more typographically correct parenthetical insertions
Using this to get standard macOS keybindings for en-dash and em-dash
;; Use MacOS key-bindings (Option-hyhpen, Option-Shift-hyphen) for en-dash and em-dash
;; (define-key undo-tree-map (kbd "M-_") nil) ;; remove override
(global-set-key (kbd "M-_") (lambda () (interactive) (insert "—")))
(global-set-key (kbd "M--") (lambda () (interactive) (insert "–")))
(global-set-key (kbd "M-8") (lambda () (interactive) (insert "•")))
(global-set-key (kbd "M-*") (lambda () (interactive) (insert "°")))
hyphen-hypen July–August American style—with a long em-dash without spaces
Just wanted to share, curious what emacs typography nerds are using otherwise
(To be clear the difference between hyphen and en-dash isn't visible in my Emacs fixed-width font, but it does show when I copy and paste into a document)
I like typopunct-mode. Keybindings are simple enough that I can't forget: with the mode on, -- becomes en-dash, --- becomes em-dash.