bug#22560: forward-word etc should be interactive-only

bug#22560: forward-word etc should be interactive-only

[Glenn Morris]

Package: emacs
Version: 25.0.90

The new implementation of subword-mode means that forward-word etc need
to be marked as interactive-only, all existing uses of such functions
need to be reviewed, and the issue needs to be mentioned in NEWS.

See bug#17558, where this was all pointed out.

bug#22560: forward-word etc should be interactive-only

[Drew Adams]

> The new implementation of subword-mode means that forward-word etc need
> to be marked as interactive-only, all existing uses of such functions
> need to be reviewed, and the issue needs to be mentioned in NEWS.
> 
> See bug#17558, where this was all pointed out.

Commands such as `forward-word' are explicitly counted on by
thingatpt.el and 3rd-party libraries to be used non-interactively.
The thingatpt code moves forward and backward over things using
`forward-*' and `backward-*' commands noninteractively.

Why would/should/must we consider such a command to be
"interactive-only"?

I see this in Emacs 25 NEWS:

** New properties that can be specified with `declare':
*** (interactive-only INSTEAD), says to use INSTEAD for non-interactive use.

Presumably this means that if you declare `forward-word' as
`interactive-only' then you will at the same time provide an
alternative that replaces it for noninteractive use.

If you do that, you will break 3rd-party code (I assume that you
will update the thingatpt.el code to use the new replacement).

Why not instead create a new _command_ to replace the _interactive_
use?  That likely breaks no code, except for key bindings, which
are quickly discovered by users and updated.

Why would limiting function `forward-ANYTHING' to interactive
use be TRT?

bug#22560: forward-word etc should be interactive-only

[Lars Ingebrigtsen]

Glenn Morris <rgm@gnu.org> writes:

> The new implementation of subword-mode means that forward-word etc need
> to be marked as interactive-only, all existing uses of such functions
> need to be reviewed, and the issue needs to be mentioned in NEWS.

Or perhaps the interactive forward-word (etc) commands should be renamed
to something new, and the old versions of forward-word (etc) should be
restored so that no code that uses these functions to parse stuff will
unbreak...

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#22560: forward-word etc should be interactive-only

[Drew Adams]

> > The new implementation of subword-mode means that forward-word etc need
> > to be marked as interactive-only, all existing uses of such functions
> > need to be reviewed, and the issue needs to be mentioned in NEWS.
> 
> Or perhaps the interactive forward-word (etc) commands should be renamed
> to something new, and the old versions of forward-word (etc) should be
> restored so that no code that uses these functions to parse stuff will
> unbreak...

Yes.  That was my suggestion as well.  I, and I am sure others, have
a fair amount of code that uses `forward-word' (as well as other
`forward-*' functions).

bug#22560: forward-word etc should be interactive-only

[Glenn Morris]

Lars Ingebrigtsen wrote:

> Or perhaps the interactive forward-word (etc) commands should be renamed
> to something new, and the old versions of forward-word (etc) should be
> restored so that no code that uses these functions to parse stuff will
> unbreak...

This too was mentioned in bug#17558, where Danial was against it.

This leaves Someone (TM) needing to do all the associated cleanup work.

bug#22560: forward-word etc should be interactive-only

[Glenn Morris]

Glenn Morris wrote:

> This too was mentioned in bug#17558, where Danial was against it.

(Sorry for the typo, I meant to say Daniel of course.)

bug#22560: forward-word etc should be interactive-only

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Date: Fri, 05 Feb 2016 11:41:26 -0500
> Cc: 22560@debbugs.gnu.org
> 
> Lars Ingebrigtsen wrote:
> 
> > Or perhaps the interactive forward-word (etc) commands should be renamed
> > to something new, and the old versions of forward-word (etc) should be
> > restored so that no code that uses these functions to parse stuff will
> > unbreak...
> 
> This too was mentioned in bug#17558, where Danial was against it.

I'm also against it.  It would render the whole feature useless, and
we might as well rip it out then

> This leaves Someone (TM) needing to do all the associated cleanup work.

Guess who that Someone (TM) is.

bug#22560: forward-word etc should be interactive-only

[Glenn Morris]

I don't want to get involved, but purely as a data point:
C-n runs next-line, which does all kinds of fancy stuff and is marked
for interactive-use only, and forward-line is for use in Lisp programs.
But 'twas ever thus, AFAIK.

bug#22560: forward-word etc should be interactive-only

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Cc: larsi@gnus.org,  22560@debbugs.gnu.org
> Date: Fri, 05 Feb 2016 15:16:56 -0500
> 
> 
> I don't want to get involved, but purely as a data point:
> C-n runs next-line, which does all kinds of fancy stuff and is marked
> for interactive-use only, and forward-line is for use in Lisp programs.
> But 'twas ever thus, AFAIK.

I don't think forward-word should be interactive-use only.

bug#22560: forward-word etc should be interactive-only

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Date: Thu, 04 Feb 2016 16:02:10 -0500
> 
> The new implementation of subword-mode means that forward-word etc need
> to be marked as interactive-only, all existing uses of such functions
> need to be reviewed, and the issue needs to be mentioned in NEWS.

The documentation is now fixed, including NEWS.  There are 2 new
functions, forward-word-strictly and backward-word-strictly, that move
by words using only the syntax table and disregarding
find-word-boundary-function-table.  I've reviewed all the users of
forward-word and backward-word, and made those of them which IMO
should not heed to the likes of subword-mode (there were quite a few)
use these new functions.

I didn't mark forward-word and backward-word interactive-only, as I
don't think this is needed, or even TRT, since the sub-word feature
explicitly wants to be honored in many word-related commands.

I therefore consider this bug "done".

As an aside, I don't understand how could we admit such pervasive
changes into our codebase without proper documentation and without
carefully considering its non-trivial implications.

I also think that the implementation of sub-word mode, which uses
find-word-boundary-function-table, is a kludge, and shouldn't have
been accepted in its present form.  find-word-boundary-function-table
is a char-table, which should have made it crystal clear that
(ab)using it to have the same function called for _any_ character is
against the spirit of char-tables.  This char-table was introduced for
script-specific word motion.  Patches to fix this aspect of sub-word
mode will be very welcome (on master).

But all this is a ship that sailed long ago, sadly, so all we can do
is lick our wounds and hope not to make such mistakes in the future.

Thanks.

bug#22560: forward-word etc should be interactive-only

[Glenn Morris]

Thank you.
I think the doc of forward-word and backward-word should mention this
issue and xref to the -strictly versions. I also think an explicit
"by `find-word-boundary-function-table' (as used by e.g. `subword-mode')"
would be helpful.

bug#22560: forward-word etc should be interactive-only

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Cc: 22560@debbugs.gnu.org
> Date: Mon, 08 Feb 2016 12:48:23 -0500
> 
> 
> Thank you.

You are welcome.

> I think the doc of forward-word and backward-word should mention this
> issue and xref to the -strictly versions. I also think an explicit
> "by `find-word-boundary-function-table' (as used by e.g. `subword-mode')"
> would be helpful.

Done.