bug#17558: 24.4.50; global-subword-mode breaks ERC

[Drew Adams <drew.adams@oracle.com>]

> Lisp code has no right to expect that "words" mean anything in
> particular.

Dunno whether it has any "rights" at all. ;-)  Is it a bad idea that
some Lisp code treats sequences of word-constituent chars as a group
in some way?  Should no Lisp code do that?

> The scheme for detecting word boundaries is a user customization
> point. find-word-boundary-function-table has been supported for
> a while now, if not heavily used.

I know nothing about that `*-table' - mea culpa.  But what are \b
and \B for in Elisp regexps, if not for matching word boundaries?

> Code can either use sexp movement or bind
> find-word-boundary-function-table (which has been in Emacs for ages,
> by the way) to a value they expect.
> 
> what's unsafe is expecting that users haven't customized
> word boundaries.

Not sure what that means.  But if a user changes a char so that it
becomes or stops being a word-constituent char, that customization
is handled by \b, \B, \w, and \W.

If the magic table complicates the picture, does it also change
how \b, \B, \w, and \W act?  Are they sometimes broken, depending
on user customization via that table?

> lots of packages invoke word movement commands on the user's
> behalf, expecting that movement happens by words. By changing word
> boundaries, we make subword mode work as expected everywhere instead
> of making everyone that deals with word movement handle the possibility
> of subword-mode separately.

Is this perhaps all about `subword-mode'?  Just wondering.

> The behavior of forward-word hasn't changed. We now make use of an
> Emacs core feature that was not heavily used before. Code that relied
> on this core feature going unused has always been broken. It's worth
> mentioning in NEWS, sure, but I'm against just rebinding the
> movement commands.

Sounds complicated, but I won't try to deal with it here & now.

Seems to me that both users and code can decide on the syntax
classes for given characters, and code should be able to move
over or otherwise manipulate "words" defined as sequences
of word-constituent chars.  If that's what's being proscribed
now, then I might be disappointed.

But it is probably more complex than my naive understanding of
these things sees.  Perhaps things are complicated because of the
existence of subword mode?  I will anyway wait for NEWS, to see
what, if anything, I need to change in my code.