Weird order of switch-to-buffer with packages that augment completing-read?
I’m using vertico, consult, consult embark, and orderless and it’s OK but for switch-to-buffer specifically it kind of bugs me that the order isn’t connected to the last-used-order (the order that list-all-buffers uses). I’m like “I just used that buffer three seconds ago and now I need to search for it?!”
Why does replace-regexp backwards work so differently?
C-u - M-x replace-regexp w+
The - prefix arg replaces backwards but it hits one char at a time, as if the plus sign weren’t there. The same replacement forwards (without the prefix arg) does hit one word at a time. What’s going on, @emacs?
Consider the string abc. From the end, moving backwards, when does it match w+, and what does it match? When it reaches c, it matches c. And from the front, moving forwards? When it reaches a, it matches abc. This is why it acts differently.
Yes, I got that, that wasn't the weird part. The weird part is why the matcher is searching char-by-char backwards in the first place as opposed to skipping match-by-match.
I'll use "\b\w+", that seems to work well. \W\w+ was not good since it caught the spaces.
(Thanks for your patient repeated replies, BTW, I don't mean to come across as ungrateful.)
@Sandra@emacs According to the Gnus changelog, use-hard-newlines takes care of that. The code checking for that variable is used by message.el which is used in the composition buffers for seemingly all Emacs mail clients, so it should not need client-specific configuration. In theory at least.