GNU bug report logs - #40460
26.3; Make arg of `forward-whitespace' and `forward-symbol' optional

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 40460 in the body.
You can then email your comments to 40460 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 26.3; Make arg of `forward-whitespace' and `forward-symbol' optional
Date: Sun, 5 Apr 2020 17:32:27 -0700 (PDT)

I see no reason why these commands are handled differently from
`forward-sexp', `forward-word', etc.  Why is their arg not optional?

That makes no difference when they are used interactively, but for Lisp
code, why not make they be like other `forward-<thing>' functions?




In GNU Emacs 26.3 (build 1, x86_64-w64-mingw32)
 of 2019-08-29
Repository revision: 96dd0196c28bc36779584e47fffcca433c9309cd
Windowing system distributor `Microsoft Corp.', version 10.0.18362
Configured using:
 `configure --without-dbus --host=x86_64-w64-mingw32
 --without-compress-install 'CFLAGS=-O2 -static -g3''

Message #10 received at 40460 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 25439 <at> debbugs.gnu.org, 40460 <at> debbugs.gnu.org
Subject: Re: bug#40460: 26.3; Make arg of `forward-whitespace' and
 `forward-symbol' optional
Date: Mon, 01 Mar 2021 16:37:58 +0100

Drew Adams <drew.adams <at> oracle.com> writes:

> The numeric argument to most `forward-*' commands is optional,
> defaulting to 1.  This should be the case in general.  These three
> commands require their ARG, but they should not.  It should be
> optional and default to 1.
>
>  `forward-button'
>  `forward-symbol'
>  `forward-whitespace'

It's true that this is somewhat inconsistent -- but I also think it's a
mistake that the other `forward-*' functions have an optional argument.
So I don't think making these follow that pattern is a move in the right
direction, and I'm closing this bug report.

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

Message #17 received at 40460 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: "25439 <at> debbugs.gnu.org" <25439 <at> debbugs.gnu.org>,
 "40460 <at> debbugs.gnu.org" <40460 <at> debbugs.gnu.org>
Subject: RE: [External] : Re: bug#40460: 26.3; Make arg of
 `forward-whitespace' and `forward-symbol' optional
Date: Mon, 1 Mar 2021 16:12:06 +0000

> > The numeric argument to most `forward-*' commands is optional,
> > defaulting to 1.  This should be the case in general.  These three
> > commands require their ARG, but they should not.  It should be
> > optional and default to 1.
> >
> >  `forward-button'
> >  `forward-symbol'
> >  `forward-whitespace'
> 
> It's true that this is somewhat inconsistent -- but I also think it's a
> mistake that the other `forward-*' functions have an optional argument.

Why do you think so?

It's not just vanilla Emacs that defines
`forward-*' commands.  Users are encouraged to
do so as well.

The point of thingatpt.el (as one example) is
to leverage `forward-*' functions to identify
things at point.  If 3rd-party code and users
define `forward-*' functions they get free
support for identifying the `*' things from
`thingatpt.el'.

So it's important that a convention be more or
less followed in the definition of `forward-*'
commands.

And yes, defaulting to 1 is exactly what Emacs
does, for all kinds of motion (and other!)
commands.  Why have `interactive' default but
not also let Elisp calls default?

For Lisp, defaulting means the arg is optional.
This is exactly what Emacs does for this kind
of thing.  It always has, since Day One.

There's an inconsistency here, and instead of
fixing it - the right way (to fit the rest of
Emacs) or even the wrong way (to fit what you
apparently think is better - no defaulting),
you prefer to keep the inconsistency.

The question is why?

> So I don't think making these follow that pattern is a move in the
> right direction, and I'm closing this bug report.

The question is why you don't think following
the Emacs pattern is right.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.