subword-mode

subword-mode

[Stefan Monnier]

I just bumped into find-word-boundary-function-table, which lead me to
its only user: cap-words.el.

It seems both subword.el and cap-words.el provide the same feature (tho
cap-words.el is obviously not good at advertising itself, ahem).


        Stefan

Re: subword-mode

[Miles Bader]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
> I just bumped into find-word-boundary-function-table, which lead me to
> its only user: cap-words.el.
>
> It seems both subword.el and cap-words.el provide the same feature (tho
> cap-words.el is obviously not good at advertising itself, ahem).

Given that it's only about 3 lines long, and apparently works by taking
advantage of some existing low-level mechanism, cap-words.el seems by
far the more elegant implementation...

However.... it doesn't seem to actually work correctly in many cases;
perhaps the low-level feature has bit-rotted?

E.g.: given the example word in the file "capitalizedWorDD", and turning
on `capitalized-words-mode', moving _backwards_ from the end of the
string with M-b stops at the first "D", then the "W', then the beginning
"c" -- that's correct except that it should have stopped at the second
"D" first.  However moving _forwards_ from the beginning with M-f, it
only stops at the second "D".

-Miles

-- 
Absurdity, n. A statement or belief manifestly inconsistent with one's own
opinion.

Re: subword-mode

[Tassilo Horn]

Miles Bader <miles@gnu.org> writes:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> I just bumped into find-word-boundary-function-table, which lead me to
>> its only user: cap-words.el.
>>
>> It seems both subword.el and cap-words.el provide the same feature (tho
>> cap-words.el is obviously not good at advertising itself, ahem).
>
> Given that it's only about 3 lines long, and apparently works by
> taking advantage of some existing low-level mechanism, cap-words.el
> seems by far the more elegant implementation...
>
> However.... it doesn't seem to actually work correctly in many cases;
> perhaps the low-level feature has bit-rotted?
>
> E.g.: given the example word in the file "capitalizedWorDD", and turning
> on `capitalized-words-mode', moving _backwards_ from the end of the
> string with M-b stops at the first "D", then the "W', then the beginning
> "c" -- that's correct except that it should have stopped at the second
> "D" first.  However moving _forwards_ from the beginning with M-f, it
> only stops at the second "D".

It looks to me that those differences come from the regexps used.
cap-words uses those simple ones

  "\\=.\\w*[[:upper:]]" (forward)
  "[[:upper:]]\\w*\\="  (backward)

and subword uses those more elaborated ones

  "\\W*\\(\\([[:upper:]]*\\W?\\)[[:lower:][:digit:]]*\\)" (forward)
  "\\(\\(\\W\\|[[:lower:][:digit:]]\\)\\([[:upper:]]+\\W*\\)\\|\\W\\w+\\)"
  (backward)

Maybe just putting the subword regexps in cap-words.el achieves the
desired behavior.  If that's the case, then I agree with Miles that the
cap-words approach is more elegant.

If so, we should rename cap-words.el to subword.el.  Additionally, the
docs of cap-words need to be polished, because there it seems to be
intended to stop at each capital letter, but in general that's not
desired.  

With (the current) subword.el, the stop points are

    fooBarBAZ
    ^  ^  ^  ^

which seems correct to me and matches the behavior of Eclipse or
IntelliJ.

Ah, and of course, I'd volunteer to test and do that changes, although I
probably won't do it before the weekend.

Bye,
Tassilo

Re: subword-mode

[Miles Bader]

Tassilo Horn <tassilo@member.fsf.org> writes:
> and subword uses those more elaborated ones
>
>   "\\W*\\(\\([[:upper:]]*\\W?\\)[[:lower:][:digit:]]*\\)" (forward)
>   "\\(\\(\\W\\|[[:lower:][:digit:]]\\)\\([[:upper:]]+\\W*\\)\\|\\W\\w+\\)"
>   (backward)
>
> Maybe just putting the subword regexps in cap-words.el achieves the
> desired behavior.  If that's the case, then I agree with Miles that the
> cap-words approach is more elegant.

Just using the above regexps in cap-words.el doesn't work properly,
though perhaps it's closer.

With the new regexps, when moving forward with M-f, it stops one
character too early, and then the next M-f moves to the "proper" end of
the subword.  E.g. (digits mark the stopping positions):

 fooBarBAZ
   12 34  5   (actual)
    1  2  3   (desired)

Moving backward with M-b goes one character too far:

 fooBarBAZ
3  2  1       (actual)  
 3  2  1      (desired)

Thanks,

-Miles

-- 
Monday, n. In Christian countries, the day after the baseball game.

Re: subword-mode

[Stefan Monnier]

>> I just bumped into find-word-boundary-function-table, which lead me to
>> its only user: cap-words.el.
>> It seems both subword.el and cap-words.el provide the same feature (tho
>> cap-words.el is obviously not good at advertising itself, ahem).

> Given that it's only about 3 lines long, and apparently works by taking
> advantage of some existing low-level mechanism, cap-words.el seems by
> far the more elegant implementation...

Of course, it also has its disadvantages:
- the mechanism was not pre-existing (i.e. the implementation of
  cap-words.el included a patch to syntax.c to add the relevant hook).
- because it operates at a low level it sometimes does more than one
  asks for: e.g. since abbrevs are defined by default as "words", it
  means that "FooBar" cannot be an abbrev without extra work.

BTW, looking at both subword and cap-words I'm surpried at the use of
2 completely separate regexps when going forward and backward.
I'd expect the use of a regexp like
"\\([[:lower:]]\\)[[:upper:][:digit:]]" where (match-end 1) says where
to stop and that should work in either direction.  That can be combined
with "\\<" or "\\>" depending on the direction, (although I'd actually
prefer using forward-word to find that boundary, so it also obeys script
boundaries).


        Stefan