Subject: bug#51041: [External] : Re: bug#51041: 28.0.60; toggle-truncate-lines should not print message

From: Drew Adams <[email-masked]>
Date: Tue, 5 Oct 2021 23:41:31 +0000

> > Yes.
> >
> > But the right fix is to add "&optional msg",
> > use (interactive "P\np"), and test for non-nil
> > MSG as the condition for showing the message.
> >
> > Lisp code for a command can use that toggle
> > function, and when _that_ command is invoked
> > interactively it too might make sense to show
> > the message (that can depend on the command
> > and when the toggling occurs as part of it).
> >
> > The same kind of fix is no doubt appropriate
> > for some other existing commands that instead
> > just test `called-interactively-p'.  Surely
> > we shouldn't perpetuate such design by adding
> > more such.
> 
> I don't think it's worth making the call signature of
> `toggle-truncate-lines' more complicated just for the purpose of
> showing a message.
> 
> Why should a different command want to show this message?

Why shouldn't it?

> Why can't that calling Lisp code just show an appropriate message itself?
> Do we have a concrete use-case for it, or is it just a "maybe nice to
> have"?

Do as you like.  IMHO, using optional MSG corresponds
to our advertised suggestion and convention.  It makes
the code more flexible and more usable by other code.

(elisp) Distinguish Interactive:

  The recommended way to test whether the function
  was called using ‘call-interactively’ is to give
  it an optional argument ‘print-message’ and use
  the ‘interactive’ spec to make it non-‘nil’ in
  interactive calls.  Here’s an example:

     (defun foo (&optional print-message)
       (interactive "p")
       (when print-message
         (message "foo")))

`foo' is a command.  This is about calling `foo'
from Lisp, in particular by some other command.
That command can choose whether it makes sense,
for its own interaction, for a user to see the
message from `foo'.  `foo's signature lets the
calling command do TRT directly.

Typical use of such an approach is for a command
someone writes that does more than one thing, and
that can benefit from such reporting echoes -
multiple steps, for example.  The code making use
of such a command as a function might have no way
of knowing what/which message(s) the called command
might report.

This corresponds to what we recommend.  We do NOT
recommend testing with `called-interactively', for
example.  There's no reason to hard-code whether a
command called from Lisp can emit a message.  Using
an optional arg MSG or NOMSG is TRT.

There's lots of old code that does hard-code things
here.  `count-words' and `count-words-region' are
good examples of such bad examples.

But again, you will do what you will.