GNU bug report logs -
#78863
31.0.50; Feature request: add option for greedy looking-back to abbrev-before-point
Previous Next
Full log
View this message in rfc822 format
> Date: Sun, 22 Jun 2025 16:42:59 +0000
> From: Alexander Prähauser <ahprae <at> protonmail.com>
> Cc: 78863 <at> debbugs.gnu.org
>
> "Eli Zaretskii" <eliz <at> gnu.org> writes:
>
> >> Date: Sun, 22 Jun 2025 14:17:15 +0000
> >> From: Alexander Prähauser via "Bug reports for GNU Emacs,
> >> the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> >>
> >>
> >> This is a feature request: I have a keyboard layout with many Unicode
> >> symbols like ∀ and such, which I would like to define abbrevs with, so
> >> for instance I would like to define "o∀" to expand to "overall". This
> >> doesn't work when the abbrev is isolated using backward-word
> >
> > This is because by default, word motion stops at the character-script
> > boundaries. But you could override that by suitable changes to
> > word-combining-categories, which see. Did you try that?
>
> Yeah, but I wasn't very successful. I changed the syntax-class of ∀ to
> "w", which lets `backward-word' consider ∀ a word-constituent, but then
> `backward-word' stops between the o and the ∀ in o∀. I tried to set
> other syntactic properties of ∀ equal to those of o using
> `put-char-code-property' but that didn't work either. Looking into it
> deeper I suspected that it was because the two belong to different
> categories as you say, so I used `char-category-set' and
> `modify-category-entry' to add and remove
> the categories of ∀ until it had the same categories as o, but
> `forward-word' still stopped between the two characters. I have no idea
> why.
I told you: it's a feature. See the doc string of forward-word.
> At that point I gave up and decided to use a regexp. I'd actually
> like to know why it didn't work with all categories set equally but I'm
> a bit out of my depth here. I can read lisp and use edebug to track what
> happens in lisp-code, but `forward-word' and the function it uses to
> determine word-boundaries are C-primitives and I know next to no C. I
> tried following the source code but, again, I have no clue why it didn't
> work after I equalized the categories. Maybe because I only did it for
> the category table of the local buffer (which was *scratch*)?
As I told, the way to affect this is to modify the list in
word-combining-categories so that a position between latin and symbol
script is not considered a border that requires forward-word to stop.
Both latin and symbol have known categories (see "M-x describe-categories")
so you could use them to customize word-combining-categories. Its doc
string is supposed to explain how; feel free to ask question if it
isn't clear enough.
This bug report was last modified 56 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.