all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: Lars Ingebrigtsen <larsi@gnus.org>
Cc: "25439@debbugs.gnu.org" <25439@debbugs.gnu.org>,
	"40460@debbugs.gnu.org" <40460@debbugs.gnu.org>
Subject: bug#25439: [External] : Re: bug#40460: 26.3; Make arg of `forward-whitespace' and `forward-symbol' optional
Date: Mon, 1 Mar 2021 16:12:06 +0000	[thread overview]
Message-ID: <SA2PR10MB44742BFE6543967442E66C6BF39A9@SA2PR10MB4474.namprd10.prod.outlook.com> (raw)
In-Reply-To: <87r1ky51gp.fsf@gnus.org>

> > 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.





      reply	other threads:[~2021-03-01 16:12 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-13 16:49 bug#25439: 24.5; `forward-*' cmds: numeric ARG should always be optional Drew Adams
2017-01-13 17:09 ` Eli Zaretskii
2021-03-01 15:37 ` bug#40460: 26.3; Make arg of `forward-whitespace' and `forward-symbol' optional Lars Ingebrigtsen
2021-03-01 16:12   ` Drew Adams [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=SA2PR10MB44742BFE6543967442E66C6BF39A9@SA2PR10MB4474.namprd10.prod.outlook.com \
    --to=drew.adams@oracle.com \
    --cc=25439@debbugs.gnu.org \
    --cc=40460@debbugs.gnu.org \
    --cc=larsi@gnus.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.