bug#22107: 25.1; Wrong docstring for this-single-command-keys

bug#22107: 25.1; Wrong docstring for this-single-command-keys

[Artur Malabarba]

[-- Attachment #1: Type: text/plain, Size: 437 bytes --]

The docstring says:

Unlike ‘this-command-keys’, this function’s value
does not include prefix arguments.

However, the function ‘this-command-keys’ also does not seem to return
prefix arguments. I tested this by evaluating the following code and then
typing C-u C-F3. (the output is just [C-f3])


(defun bababa ()
  (interactive)
  (message "%s" (this-command-keys)))

(global-set-key (kbd "C-<f3>") #'bababa)

[-- Attachment #2: Type: text/html, Size: 659 bytes --]

bug#22107: 25.1; Wrong docstring for this-single-command-keys

[Glenn Morris]

Artur Malabarba wrote:

> The docstring says:
>
> Unlike 'this-command-keys', this function's value
> does not include prefix arguments.
>
> However, the function 'this-command-keys' also does not seem to return
> prefix arguments.

When you find something like that, sadly your first thought should be
"someone's broken something" rather than "the doc is wrong".
It works as documented in 24.5 and earlier.

IMO the example from the Elisp manual is more informative:

    (this-command-keys)
    ;; Now use `C-u C-x C-e' to evaluate that.
      => "^U^X^E"

bug#22107: 25.1; Wrong docstring for this-single-command-keys

[Artur Malabarba]

Good point. I've filed a new bug and I'm closing this one.

bug#22107: 25.1; Wrong docstring for this-single-command-keys

[Glenn Morris]

Artur Malabarba wrote:

> Good point. I've filed a new bug and I'm closing this one.

I don't see what the point of that was.
I'd already retitled this one and marked it as a release blocker.

bug#22107: 25.1; Wrong docstring for this-single-command-keys

[Artur Malabarba]

Glenn Morris <rgm@gnu.org> writes:

>> Good point. I've filed a new bug and I'm closing this one.
>
> I don't see what the point of that was.
> I'd already retitled this one and marked it as a release blocker.

Sorry, Glenn. I use the bug tracker from my mail client. From here I
couldn't see you had retitled it or marked it as a release blocker.
My bad.

bug#22107: 25.1; Wrong docstring for this-single-command-keys

[Glenn Morris]

Without any testing, going to guess this was caused by 5dc644a6b01e.

bug#22107: 25.1; Wrong docstring for this-single-command-keys

[Artur Malabarba]

2015-12-08 1:20 GMT+00:00 Glenn Morris <rgm@gnu.org>:
>
> Without any testing, going to guess this was caused by 5dc644a6b01e.

Yes, I've just compiled and verified the commit "Generalize the
prefix-command machinery of C-u" is the cause.
Stefan, do you know what the problem might be?

bug#22107: 25.1; Wrong docstring for this-single-command-keys

[Eli Zaretskii]

> Date: Tue, 8 Dec 2015 12:01:29 +0000
> From: Artur Malabarba <bruce.connor.am@gmail.com>
> Cc: 22107@debbugs.gnu.org
> 
> 2015-12-08 1:20 GMT+00:00 Glenn Morris <rgm@gnu.org>:
> >
> > Without any testing, going to guess this was caused by 5dc644a6b01e.
> 
> Yes, I've just compiled and verified the commit "Generalize the
> prefix-command machinery of C-u" is the cause.
> Stefan, do you know what the problem might be?

I'm not Stefan, so I cannot say that I understand what I'm doing, but
the simple patch below seems to restore the old behavior.  Stefan, any
objections or gotchas?


diff --git a/src/keyboard.c b/src/keyboard.c
index 02bc7d2..e378b89 100644
--- a/src/keyboard.c
+++ b/src/keyboard.c
@@ -1486,8 +1486,11 @@ command_loop_1 (void)
       if (!CONSP (last_command_event))
 	kset_last_repeatable_command (current_kboard, Vreal_this_command);
 
-      this_command_key_count = 0;
-      this_single_command_key_start = 0;
+      if (NILP (KVAR (current_kboard, Vprefix_arg)))
+	{
+	  this_command_key_count = 0;
+	  this_single_command_key_start = 0;
+	}
 
       if (current_kboard->immediate_echo
 	  && !NILP (call0 (Qinternal_echo_keystrokes_prefix)))

bug#22107: 25.1; Wrong docstring for this-single-command-keys

[Stefan Monnier]

> I'm not Stefan, so I cannot say that I understand what I'm doing,

I am Stefan, but I cannot say that I understand what I'm doing, sorry.

> diff --git a/src/keyboard.c b/src/keyboard.c
> index 02bc7d2..e378b89 100644
> --- a/src/keyboard.c
> +++ b/src/keyboard.c
> @@ -1486,8 +1486,11 @@ command_loop_1 (void)
>        if (!CONSP (last_command_event))
>  	kset_last_repeatable_command (current_kboard, Vreal_this_command);
>
> -      this_command_key_count = 0;
> -      this_single_command_key_start = 0;
> +      if (NILP (KVAR (current_kboard, Vprefix_arg)))
> +	{
> +	  this_command_key_count = 0;
> +	  this_single_command_key_start = 0;
> +	}
>
>        if (current_kboard->immediate_echo
>  	  && !NILP (call0 (Qinternal_echo_keystrokes_prefix)))

My gut feeling is that this isn't quite right, because the new approach
basically never does anything special for Vprefix_arg (the overarching
design goal is to make prefix-arg completely non-special, to the point
where it should be possible to move it to Elisp, save for its use in
`interactive', IIRC).


        Stefan

bug#22107: 25.1; Wrong docstring for this-single-command-keys

[Stefan Monnier]

>> > diff --git a/src/keyboard.c b/src/keyboard.c
>> > index 02bc7d2..e378b89 100644
>> > --- a/src/keyboard.c
>> > +++ b/src/keyboard.c
>> > @@ -1486,8 +1486,11 @@ command_loop_1 (void)
>> >        if (!CONSP (last_command_event))
>> >  	kset_last_repeatable_command (current_kboard, Vreal_this_command);
>> >
>> > -      this_command_key_count = 0;
>> > -      this_single_command_key_start = 0;
>> > +      if (NILP (KVAR (current_kboard, Vprefix_arg)))
>> > +	{
>> > +	  this_command_key_count = 0;
>> > +	  this_single_command_key_start = 0;
>> > +	}
>> >
>> >        if (current_kboard->immediate_echo
>> >  	  && !NILP (call0 (Qinternal_echo_keystrokes_prefix)))
>> 
>> My gut feeling is that this isn't quite right, because the new approach
>> basically never does anything special for Vprefix_arg (the overarching
>> design goal is to make prefix-arg completely non-special, to the point
>> where it should be possible to move it to Elisp, save for its use in
>> `interactive', IIRC).
> Bu the futzing with these indices cannot be done from Lisp, so what's
> the alternative?

Maybe your patch is OK but just needs to be changed so that instead of
checking prefix-arg we check "NILP (call0
(Qinternal_echo_keystrokes_prefix))".


        Stefan

bug#22107: 25.1; Wrong docstring for this-single-command-keys

[Stefan Monnier]

> So how about saying a few words about the meaning of the return value
> of internal-echo-keystrokes-prefix?  I think it's important enough to
> have that at least documented in comments.

It's used as a proxy for "we're in the middle of a command-with-prefix,
which may be using the `prefix-arg' variable or any other variable".


        Stefan

bug#22107: 25.1; Wrong docstring for this-single-command-keys

[Stefan Monnier]

>> So how about saying a few words about the meaning of the return value
>> of internal-echo-keystrokes-prefix?  I think it's important enough to
>> have that at least documented in comments.
> It's used as a proxy for "we're in the middle of a command-with-prefix,
> which may be using the `prefix-arg' variable or any other variable".

This said, the distinction between "this-single-command-keys" and
"this-command-keys" is something which should disappear, IMNSHO.


        Stefan

bug#22107: 25.1; Wrong docstring for this-single-command-keys

[Eli Zaretskii]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Cc: bruce.connor.am@gmail.com, rgm@gnu.org, 22107@debbugs.gnu.org
> Date: Thu, 10 Dec 2015 13:37:33 -0500
> 
> This said, the distinction between "this-single-command-keys" and
> "this-command-keys" is something which should disappear, IMNSHO.

Are we sure no one out there depends on that?  This is a very old
feature.

bug#22107: 25.1; Wrong docstring for this-single-command-keys

[Stefan Monnier]

>> This said, the distinction between "this-single-command-keys" and
>> "this-command-keys" is something which should disappear, IMNSHO.
> Are we sure no one out there depends on that?  This is a very old
> feature.

I'm not, but we should go in that direction, i.e. we should check where
this distinction might be used and how to fix/change it.

FWIW, I've already made such changes to the keyboard-macro machinery
which depended on it, and the result was simpler code (since C-u is now
a plain normal command, the special casing of C-u was simply dropped).

This probably also means that fixing bug#22107 may introduce other
regressions because of code I changed to rely on the new behavior.




        Stefan

bug#22107: 25.1; Wrong docstring for this-single-command-keys

[Stefan Monnier]

> In what direction should the distinction disappear?  Should it always
> include C-u, or should it never include it?

Since C-u is now a completely normal command, the C-u that precedes is
treated the same as any other command that might have been run before.
IOW, the C-u should never be included.

> I guess we could make such a change on master, and see if it breaks
> something.

I'm not sure which change you're referring to.  AFAIK (and according to
this bug report) the change has already been done (tho not to the
docstring).


        Stefan

bug#22107: 25.1; Wrong docstring for this-single-command-keys

[Stefan Monnier]

>> AFAIK (and according to this bug report) the change has already been
>> done (tho not to the docstring).
> If you refer to the commit I made on emacs-25, then it just restored
> old behavior; this-command-keys and this-single-command-keys still
> differ wrt including/excluding C-u after that change.

IOW this commit you just made undid the change.


        Stefan

bug#22107: 25.1; Wrong docstring for this-single-command-keys

[Stefan Monnier]

>>> AFAIK (and according to this bug report) the change has already been
>>> done (tho not to the docstring).
>> If you refer to the commit I made on emacs-25, then it just restored
>> old behavior; this-command-keys and this-single-command-keys still
>> differ wrt including/excluding C-u after that change.
> IOW this commit you just made undid the change.

BTW, your commit seems to have introduced a new problem:

    src/emacs -Q
    C-u ...wait...
    [ here I see "C-u C-u-" in the echo area instead of "C-u-". ]
    4 ...wait...
    [ here I see "C-u 4 C-u 4-" in the echo area instead of "C-u 4-". ]


-- Stefan

bug#22107: 25.1; Wrong docstring for this-single-command-keys

[Eli Zaretskii]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Cc: bruce.connor.am@gmail.com, rgm@gnu.org, 22107@debbugs.gnu.org
> Date: Fri, 11 Dec 2015 23:28:35 -0500
> 
> >>> AFAIK (and according to this bug report) the change has already been
> >>> done (tho not to the docstring).
> >> If you refer to the commit I made on emacs-25, then it just restored
> >> old behavior; this-command-keys and this-single-command-keys still
> >> differ wrt including/excluding C-u after that change.
> > IOW this commit you just made undid the change.
> 
> BTW, your commit seems to have introduced a new problem:
> 
>     src/emacs -Q
>     C-u ...wait...
>     [ here I see "C-u C-u-" in the echo area instead of "C-u-". ]
>     4 ...wait...
>     [ here I see "C-u 4 C-u 4-" in the echo area instead of "C-u 4-". ]

So I guess your idea that it would be the right fix was not entirely
correct, was it?

Any further suggestions?

bug#22107: 25.1; Wrong docstring for this-single-command-keys

[Stefan Monnier]

>> >>> AFAIK (and according to this bug report) the change has already been
>> >>> done (tho not to the docstring).
>> >> If you refer to the commit I made on emacs-25, then it just restored
>> >> old behavior; this-command-keys and this-single-command-keys still
>> >> differ wrt including/excluding C-u after that change.
>> > IOW this commit you just made undid the change.
>> BTW, your commit seems to have introduced a new problem:
>> src/emacs -Q
>> C-u ...wait...
>> [ here I see "C-u C-u-" in the echo area instead of "C-u-". ]
>> 4 ...wait...
>> [ here I see "C-u 4 C-u 4-" in the echo area instead of "C-u 4-". ]
> So I guess your idea that it would be the right fix was not entirely
> correct, was it?

No, indeed.

> Any further suggestions?

My suggestion is not to fix it (i.e. to change the docstring).


        Stefan

bug#22107: 25.1; Wrong docstring for this-single-command-keys

[Eli Zaretskii]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Cc: bruce.connor.am@gmail.com, rgm@gnu.org, 22107@debbugs.gnu.org
> Date: Sat, 12 Dec 2015 09:25:09 -0500
> 
> >> >>> AFAIK (and according to this bug report) the change has already been
> >> >>> done (tho not to the docstring).
> >> >> If you refer to the commit I made on emacs-25, then it just restored
> >> >> old behavior; this-command-keys and this-single-command-keys still
> >> >> differ wrt including/excluding C-u after that change.
> >> > IOW this commit you just made undid the change.
> >> BTW, your commit seems to have introduced a new problem:
> >> src/emacs -Q
> >> C-u ...wait...
> >> [ here I see "C-u C-u-" in the echo area instead of "C-u-". ]
> >> 4 ...wait...
> >> [ here I see "C-u 4 C-u 4-" in the echo area instead of "C-u 4-". ]
> > So I guess your idea that it would be the right fix was not entirely
> > correct, was it?
> 
> No, indeed.
> 
> > Any further suggestions?
> 
> My suggestion is not to fix it (i.e. to change the docstring).

I'm uneasy with such a change in v25.1.  We didn't intend that to
happen at this time.  But maybe I'm the only one who's worried.  John?

bug#22107: 25.1; Wrong docstring for this-single-command-keys

[John Wiegley]

[-- Attachment #1: Type: text/plain, Size: 629 bytes --]

>>>>> Eli Zaretskii <eliz@gnu.org> writes:

> I'm uneasy with such a change in v25.1. We didn't intend that to happen at
> this time. But maybe I'm the only one who's worried. John?

If it makes you uneasy, Eli, then I am as well. In general I'm very much
against changing existing behavior without good reason. If there's no good
reason here, we should revert to how it behaved previously.

Stefan, can you summarize an argument for why it should change in 25.1?

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 629 bytes --]

bug#22107: 25.1; Wrong docstring for this-single-command-keys

[Stefan Monnier]

> Stefan, can you summarize an argument for why it should change in 25.1?

Because it's better to get rid of all the C-u special case handling and
make C-u be a normal command so that GNU ELPA packages can implement
their own form of prefix command.

The immediate need for the new behavior is to be able to implement C-x
4 and C-x 5 as prefix argument (rather than keymaps) so as to be able to
get rid of all the foo-other-window and foo-other-frame and the
concomitant need to find key bindings for them.


        Stefan

bug#22107: 25.1; Wrong docstring for this-single-command-keys

[Artur Malabarba]

2015-12-13 4:16 GMT+00:00 Stefan Monnier <monnier@iro.umontreal.ca>:
>> Stefan, can you summarize an argument for why it should change in 25.1?
>
> Because it's better to get rid of all the C-u special case handling and
> make C-u be a normal command so that GNU ELPA packages can implement
> their own form of prefix command.

I think we should do this. If we are worried about changing the
behavior of this-command-keys during feature-freeze, we can modify
this function to keep the old behaviour under the new framework (at
least for the next release).

bug#22107: 25.1; Wrong docstring for this-single-command-keys

[Eli Zaretskii]

> Date: Sun, 13 Dec 2015 10:12:13 +0000
> From: Artur Malabarba <bruce.connor.am@gmail.com>
> Cc: John Wiegley <jwiegley@gmail.com>, Eli Zaretskii <eliz@gnu.org>, Glenn Morris <rgm@gnu.org>, 
> 	22107@debbugs.gnu.org
> 
> 2015-12-13 4:16 GMT+00:00 Stefan Monnier <monnier@iro.umontreal.ca>:
> >> Stefan, can you summarize an argument for why it should change in 25.1?
> >
> > Because it's better to get rid of all the C-u special case handling and
> > make C-u be a normal command so that GNU ELPA packages can implement
> > their own form of prefix command.
> 
> I think we should do this. If we are worried about changing the
> behavior of this-command-keys during feature-freeze, we can modify
> this function to keep the old behaviour under the new framework (at
> least for the next release).

Do you have a suggestion for how to fix this-command-keys?  AFAIU, the
last part of this discussion was trying to find a way of doing that.

bug#22107: 25.1; Wrong docstring for this-single-command-keys

[Artur Malabarba]

[-- Attachment #1: Type: text/plain, Size: 492 bytes --]

On 13 Dec 2015 3:37 pm, "Eli Zaretskii" <eliz@gnu.org> wrote:
>
> Do you have a suggestion for how to fix this-command-keys?  AFAIU, the
> last part of this discussion was trying to find a way of doing that.

Define a variable (current-prefix-arg-keys, maybe) that gets set and
cleared in the same way as current-prefix-arg. This variable holds the keys
that were used to invoke the prefix args.

Then this-command-keys simply needs to check that variable and prepend it
to the return value.

[-- Attachment #2: Type: text/html, Size: 621 bytes --]

bug#22107: 25.1; Wrong docstring for this-single-command-keys

[Eli Zaretskii]

> Date: Sun, 13 Dec 2015 20:53:39 +0000
> From: Artur Malabarba <bruce.connor.am@gmail.com>
> Cc: John Wiegley <jwiegley@gmail.com>, 22107@debbugs.gnu.org, Glenn Morris <rgm@gnu.org>, 
> 	Stefan Monnier <monnier@iro.umontreal.ca>
> 
> On 13 Dec 2015 3:37 pm, "Eli Zaretskii" <eliz@gnu.org> wrote:
> >
> > Do you have a suggestion for how to fix this-command-keys? AFAIU, the
> > last part of this discussion was trying to find a way of doing that.
> 
> Define a variable (current-prefix-arg-keys, maybe) that gets set and cleared in
> the same way as current-prefix-arg. This variable holds the keys that were used
> to invoke the prefix args. 
> 
> Then this-command-keys simply needs to check that variable and prepend it to
> the return value. 

I'm not sure I follow.  Can you show a patch to this effect?

Thanks.

bug#22107: 25.1; Wrong docstring for this-single-command-keys

[Artur Malabarba]

[-- Attachment #1: Type: text/plain, Size: 335 bytes --]

On 14 Dec 2015 3:27 am, "Eli Zaretskii" <eliz@gnu.org> wrote:
> I'm not sure I follow.  Can you show a patch to this effect?
>
> Thanks.

Sorry, it's possible I'm talking nonsense.
I'm not familiar enough with this stuff to provide a patch. And it's not
high enough in my priorities for me to invest time getting acquainted right
now.

[-- Attachment #2: Type: text/html, Size: 471 bytes --]

bug#22107: 25.1; Wrong docstring for this-single-command-keys

[Stefan Monnier]

> I think we should do this. If we are worried about changing the
> behavior of this-command-keys during feature-freeze,

FWIW, we're not talking about changing the behavior during feature
freeze: the behavior was changed earlier.
We're only wondering whether to revert this change during feature
freeze, or whether to document the new feature.


        Stefan

bug#22107: 25.1; Wrong docstring for this-single-command-keys

[Drew Adams]

> >> Stefan, can you summarize an argument for why it should change in 25.1?
> >
> > Because it's better to get rid of all the C-u special case handling and
> > make C-u be a normal command so that GNU ELPA packages can implement
> > their own form of prefix command.

That's a bit vague, even as a summary.

> I think we should do this.

Why do you think so?

> > The immediate need for the new behavior is to be able to implement
> > C-x 4 and C-x 5 as prefix argument (rather than keymaps) so as to
> > be able to get rid of all the foo-other-window and foo-other-frame
> > and the concomitant need to find key bindings for them.

Caveat: I have not been following this thread much, so it's not
very clear to me what is being proposed, or why.  So yes, I am
relatively uninformed about this.

I can say that it sounds like what is being considered will likely
break some of my code, including key completion (in Icicles).

Why the change?  I don't see anything broken that needs "fixing"
here.  I know that Stefan has long touted getting rid of separate
`*-other-[window|frame]' commands as a great idea.  I disagree
with that.  To me that sounds like both a YAGNI and painting
yourself into a corner.

AFAICT, what Stefan has proposed, previously at least, increases
one-size-fits-all rigidity, with no benefit other than dispensing
with the need to define and bind separate `*-other-*' commands.

To me, being able to define, or not define, such commands
individually, and to make their behaviors be anything one likes,
is a plus, not a minus.  I don't see the "bother" of defining
and binding them to be a giant hurdle which should be eliminated
by redesigning the longstanding `C-u' and `C-x [45]' behavior.

Straitjacketing `C-x [45]...' bindings to automatically be only
a predefined "other" version of the command that is bound to
`C-x ...' (without [45]), would be a step backward, IMO.

(A macro to define & bind such a command could perhaps suffice
to accomplish only that, when desired, possibly with the
addition of a hook that the macro can use.  That would not
impose such command definitions and bindings everywhere.  But
even without such a macro, the typical definition and binding
of an `*-other-*' command amounts to only a few lines of code.

Changing how `C-u' is implemented will also likely break my
code that echoes the prefix arg when the minibuffer is active
(e.g., for individual minibuffer keys that perform actions).

(In Icicles it is common to use minibuffer keys that act on
one or more completion candidates.  Such keys can make use of
the prefix arg, so it is important to echo it in this context.)

Another consideration, but minor: If the `*-other-*' commands
are eliminated then you will presumably no longer be able to
invoke them using `M-x'.  The hard-coded `C-x [45]' keys will,
in effect, replace the commands that have (sometimes) been
bound to them.  I like having not only a key but a command
that is associated with it - which I can invoke in various
ways.  (That's the basic Emacs design.)

AFAICT, special-casing `C-x [45]' - making it exceptional,
is oddly enough being made as an argument in favor of more
consistency.  Yes, one person's consistency can be another
person's bother.  I, for one, am not bothered by the need
(and possibility) to define separate `*-other-*' commands.

bug#22107: 25.1; Wrong docstring for this-single-command-keys

[Stefan Monnier]

> To me, being able to define, or not define, such commands
> individually, and to make their behaviors be anything one likes,
> is a plus, not a minus.

Making it it impossible (or even just difficult) to define such commands
individually (and provide any behavior you want for them) would be nigh
on impossible.

And no idiot would ever want to do that.

So please, think or investigate before complaining about things that
come straight out of your wild imagination.


        Stefan

bug#22107: 25.1; Wrong docstring for this-single-command-keys

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> This said, the distinction between "this-single-command-keys" and
>> "this-command-keys" is something which should disappear, IMNSHO.
>
> Are we sure no one out there depends on that?  This is a very old
> feature.

This was four years ago, and it still hasn't been fixed.  `C-u C-x C-e'
is still:

(this-command-keys)
=> "^X^E"

There was disagreement between Stefan (who thinks that the current
behaviour is correct, and the doc should be fixed), and Eli (who was
concerned that this would be a breaking change).

Since it doesn't seem like there's been any big uproar over this change
over the years, I think that perhaps updating the documentation to
reflect the current behaviour is the way to go now.

Any further opinions?

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

bug#22107: 25.1; Wrong docstring for this-single-command-keys

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Since it doesn't seem like there's been any big uproar over this change
> over the years, I think that perhaps updating the documentation to
> reflect the current behaviour is the way to go now.
>
> Any further opinions?

There weren't any, so I've now updated the documentation.

Since the difference between this-command-keys and
this-single-command-keys is pretty...  er...  obscure (except for the
form of the return value), perhaps the latter should be obsoleted?

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

bug#22107: 25.1; Wrong docstring for this-single-command-keys

[Eli Zaretskii]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Cc: bruce.connor.am@gmail.com, rgm@gnu.org, 22107@debbugs.gnu.org
> Date: Thu, 10 Dec 2015 13:34:48 -0500
> 
> > So how about saying a few words about the meaning of the return value
> > of internal-echo-keystrokes-prefix?  I think it's important enough to
> > have that at least documented in comments.
> 
> It's used as a proxy for "we're in the middle of a command-with-prefix,

When it returns non-nil, I presume?

> which may be using the `prefix-arg' variable or any other variable".

But this means we can never be sure a non-nil value actually mean the
user typed a prefix-arg command, is that true?  Do we want to treat
the "other" prefixes (which ones, btw?) as prefix-arg in this case?

bug#22107: 25.1; Wrong docstring for this-single-command-keys

[Stefan Monnier]

>> > So how about saying a few words about the meaning of the return value
>> > of internal-echo-keystrokes-prefix?  I think it's important enough to
>> > have that at least documented in comments.
>> It's used as a proxy for "we're in the middle of a command-with-prefix,
> When it returns non-nil, I presume?

Right.

>> which may be using the `prefix-arg' variable or any other variable".
> But this means we can never be sure a non-nil value actually mean the
> user typed a prefix-arg command, is that true?

Yes and no.  It depends on how you define "prefix arg command".

> Do we want to treat the "other" prefixes as prefix-arg in this case?

I think so, yes.  Or rather I think I know that we want to get rid of
the special casing of prefix commands.

> (which ones, btw?)

There's C-x 4 and C-x 5 (or is C-x 8 and C-x 9) in GNU ELPA's
other-frame-window.

PCL-CVS had some other prefix commands, tho they weren't recognizable by
Emacs as such.  I think Gnus's M-& is another example.


        Stefan

bug#22107: 25.1; Wrong docstring for this-single-command-keys

[Stefan Monnier]

>> >> > So how about saying a few words about the meaning of the return value
>> >> > of internal-echo-keystrokes-prefix?  I think it's important enough to
>> >> > have that at least documented in comments.
>> >> It's used as a proxy for "we're in the middle of a command-with-prefix,
>> > When it returns non-nil, I presume?
>> Right.
> Hmm... I see it also has some side effects, so is it really safe to
> call it whenever we want to know "if we are in the middle of
> command-with-prefix"?  What could those side effects be?

As currently implemented, it should be "pure with memoization" (IOW the
"effect" is in the memoization only).  And that's the intention of how
it should behave.  Of course it's Elisp so it could do anything.
IOW it's OK to call it iff calling Elisp doesn't risk crashing Emacs.


        Stefan

bug#22107: 25.1; Wrong docstring for this-single-command-keys

[Stefan Monnier]

> However, the function ‘this-command-keys’ also does not seem to return
> prefix arguments. I tested this by evaluating the following code and then
> typing C-u C-F3. (the output is just [C-f3])

Indeed, C-u is now a completely normal command so there's no special
handling of "prefix commands" for this-command-keys.
Could you tel us where that caused a problem for you?


        Stefan

bug#22107: 25.1; Wrong docstring for this-single-command-keys

[Artur Malabarba]

On 11 Dec 2015 4:17 am, "Stefan Monnier" <monnier@iro.umontreal.ca> wrote:
> Indeed, C-u is now a completely normal command so there's no special
> handling of "prefix commands" for this-command-keys.
> Could you tel us where that caused a problem for you?

I wrote a package for use in screencasts, which displays the key for
some commands when you invoke them. And I wanted it to show prefix
args too.

That said, this doesn't actually affect me right now. Since I didn't
know this was a bug, I manually implemented this "prefix-arg
detection" into my code.

bug#22107: 25.1; Wrong docstring for this-single-command-keys

[Stefan Monnier]

>> Indeed, C-u is now a completely normal command so there's no special
>> handling of "prefix commands" for this-command-keys.
>> Could you tel us where that caused a problem for you?
> I wrote a package for use in screencasts, which displays the key for
> some commands when you invoke them.  And I wanted it to show prefix
> args too.

Could you give some details?  More specifically, doesn't the screen-cast
already give you the C-u when the prefix command itself is run?

> That said, this doesn't actually affect me right now.  Since I didn't
> know this was a bug,

I consider it a feature at least as much as a bug ;-)


        Stefan

bug#22107: 25.1; Wrong docstring for this-single-command-keys

[Artur Malabarba]

2015-12-11 14:44 GMT+00:00 Stefan Monnier <monnier@iro.umontreal.ca>:
>>> Indeed, C-u is now a completely normal command so there's no special
>>> handling of "prefix commands" for this-command-keys.
>>> Could you tel us where that caused a problem for you?
>> I wrote a package for use in screencasts, which displays the key for
>> some commands when you invoke them.  And I wanted it to show prefix
>> args too.
>
> Could you give some details?  More specifically, doesn't the screen-cast
> already give you the C-u when the prefix command itself is run?

It can be made to, yes. But I wanted the C-u it to be displayed as
part of the following command.
The point of this little package is that it doesn't display every
single key combo you use. It only displays the keybind of a few
commands that you specify in advance (so it only shows the commands
you're trying to teach).

So you run something like (display-keys-for-commands '(eval-last-sexp
eval-buffer eval-defun)). From there on, wherever you type C-x C-e, a
small frame will popup saying:
   eval-last-sexp
   C-x C-e
(where C-x C-e is in a big bright font).

Now I also want to teach viewers that hitting C-u C-x C-e will insert
the results of evaluation.
I could add `universal-argument' to that list of commands for which it
will show the key, but then it will report that C-u was pressed even
when it is pressed before some command that I don't care about (like
C-n or C-p). This is a sensible behavior given that C-u is a command
like any other, but it would be confusing for viewers who don't
understand this technicality.

Right now, I've just patched my own code to display something like
this in that situation (and I'm happy with it):
   eval-last-sexp (with prefix)
   C-u C-x C-e

bug#22107: 25.1; Wrong docstring for this-single-command-keys

[Stefan Monnier]

> It can be made to, yes. But I wanted the C-u it to be displayed as
> part of the following command.
> The point of this little package is that it doesn't display every
> single key combo you use. It only displays the keybind of a few
> commands that you specify in advance (so it only shows the commands
> you're trying to teach).

That makes sense, thank you.

> Right now, I've just patched my own code to display something like
> this in that situation (and I'm happy with it):
>    eval-last-sexp (with prefix)
>    C-u C-x C-e

And indeed for your example, this behavior is meaningful for C-u but not
nearly as much for a prefix like C-x 4 (whose effect should be the
same for all commands, contrary to C-u whose effect can vary
from one command to the next).


        Stefan

bug#22107: this-command-keys no longer returns prefix argument

[Kaushal Modi]

[-- Attachment #1: Type: text/plain, Size: 2568 bytes --]

Hi all,

I stumbled upon this bug recently, when something in my config (
https://github.com/kaushalmodi/.emacs.d/commit/912c4fc8bf4ed0c84e28dc837b0500b9a2e172ca
)
wasn't working the same way in emacs 24.5 as it does in emacs 25.x.

Here is a dummy example to demonstrate this (which is almost the same as
posted by Artur in the first email of this thread):

=====
(defun foo ()
  (interactive)
  (message (format "this-command-keys: %S, this-single-command-keys: %s"
  (this-command-keys)
  (this-single-command-keys))))
(global-set-key (kbd "C-c ;") #'foo)
=====

After evaluating the above, doing C-u C-c ; gives the following results on
different versions of emacs:

24.5: this-command-keys: "^U^C;", this-single-command-keys: [3 59]
25.0.93: this-command-keys: "^C;", this-single-command-keys: [3 59]

(of course I have stringified the ^U and ^C portions above to make them
visible in the email)

I looked at the related commit based on this bug:
http://git.savannah.gnu.org/cgit/emacs.git/commit/src/keyboard.c?h=emacs-25&id=9d2b8e768f2015a89f7609dedf7b28ea5e8123b5

It's commit log says "Restore the feature whereby C-u was part of
this-command-keys, but not of this-single-command-keys.". But it looks like
no restore happened. "^U" is still not part of this-command-keys.

Currently this-command-keys and this-single-command-keys look essentially
the same, except the this-command-keys is a string and
this-single-command-keys is a vector of asciis.

Also as Artur stated in the original bug report, the function documentation
is not in sync with what actually is happening:

C-h f this-command-keys on emacs 25.0.93 gives:

=====
this-command-keys is a built-in function in ‘C source code’.

(this-command-keys)

Return the key sequence that invoked this command.
However, if the command has called ‘read-key-sequence’, it returns
the last key sequence that has been read.
The value is a string or a vector.
=====

C-h f this-single-command-keys on emacs 25.0.93 gives:

=====
this-single-command-keys is a built-in function in ‘C source code’.

(this-single-command-keys)

Return the key sequence that invoked this command.
More generally, it returns the last key sequence read, either by
the command loop or by ‘read-key-sequence’.
Unlike ‘this-command-keys’, this function’s value
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
does not include prefix arguments.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The value is always a vector.
=====
-- 

-- 
Kaushal Modi

[-- Attachment #2: Type: text/html, Size: 4032 bytes --]

bug#22107: this-command-keys no longer returns prefix argument

[Eli Zaretskii]

> From: Kaushal Modi <kaushal.modi@gmail.com>
> Date: Wed, 11 May 2016 13:33:18 +0000
> 
> I looked at the related commit based on this bug:
> http://git.savannah.gnu.org/cgit/emacs.git/commit/src/keyboard.c?h=emacs-25&id=9d2b8e768f2015a89f7609dedf7b28ea5e8123b5
> 
> 
> It's commit log says "Restore the feature whereby C-u was part of this-command-keys, but not of
> this-single-command-keys.". But it looks like no restore happened. "^U" is still not part of this-command-keys.

Because that commit was reverted, see commit 0b7d6b0.

AFAIR, Stefan thought that the current behavior is the correct one.

bug#22107: this-command-keys no longer returns prefix argument

[Kaushal Modi]

[-- Attachment #1: Type: text/plain, Size: 846 bytes --]

On Wed, May 11, 2016 at 10:02 AM Eli Zaretskii <eliz@gnu.org> wrote:

> Because that commit was reverted, see commit 0b7d6b0.
>
> AFAIR, Stefan thought that the current behavior is the correct one.
>

Found it (
http://git.savannah.gnu.org/cgit/emacs.git/commit/src/keyboard.c?h=emacs-25&id=0b7d6b026eb2cd69a90a9af41a4fca24389c5e47
),
thanks.

I don't have a strong opinion for/against this change. But the
documentation is out of sync and that needs to be fixed, right? C-h f
documentation for this-single-command-keys.

As it stands right now, is it safe to say that this-command-keys and
this-single-command-keys give the same output except that the former's
output is in string format and the latter's output is in vector format? If
so, it would be useful to reflect that info in the docstrings for those two
functions.
-- 

-- 
Kaushal Modi

[-- Attachment #2: Type: text/html, Size: 1361 bytes --]

bug#22107: this-command-keys no longer returns prefix argument

[Stefan Monnier]

> As it stands right now, is it safe to say that this-command-keys and
> this-single-command-keys give the same output except that the former's
> output is in string format and the latter's output is in vector format?

You mean, are this-command-keys-vector and this-single-command-keys
100% equivalent all the time?  I wish I was able to give you an answer.
They appear to be


        Stefan

bug#22107: this-command-keys no longer returns prefix argument

[Kaushal Modi]

[-- Attachment #1: Type: text/plain, Size: 1025 bytes --]

On Wed, May 11, 2016, 10:22 AM Stefan MonnierOnonnier@iro.umontreal.ca>
wrote:

> You mean, are this-command-keys-vector and this-single-command-keys
> 100% equivalent all the time?  I wish I was able to give you an answer.
> They appear to be
>

At this point it is a documentation bug. this-command-keys and
this-single-command-keys are equivalent. But the documentaion still says
that this-single-command-keys does not return prefix argument unlike
this-command-keys. In fact, none of them return the prefix arg.

So

(1) The docstring of this-single-command-keys needs to be fixed.
(2) NEWS also needs to mention that this-command-keys no longer returns
prefix arg.

Going forward (not for this bug or emacs-25): If someone can review
that this-command-keys-vector and this-single-command-keys are ACTUALLY the
same, can then this-single-command-keys be marked obsolete and an alias to
the other for the next release? If that seems like the next action, I can
file a separate bug report for that.

> --

-- 
Kaushal Modi

[-- Attachment #2: Type: text/html, Size: 1567 bytes --]

bug#22107: this-command-keys no longer returns prefix argument

[Eli Zaretskii]

> From: Kaushal Modi <kaushal.modi@gmail.com>
> Date: Fri, 13 May 2016 11:52:41 +0000
> Cc: 22107@debbugs.gnu.org, Eli Zaretskii <eliz@gnu.org>
> 
> On Wed, May 11, 2016, 10:22 AM Stefan MonnierOnonnier@iro.umontreal.ca> wrote:
> 
>  You mean, are this-command-keys-vector and this-single-command-keys
>  100% equivalent all the time? I wish I was able to give you an answer.
>  They appear to be
> 
> At this point it is a documentation bug. this-command-keys and this-single-command-keys are equivalent. But
> the documentaion still says that this-single-command-keys does not return prefix argument unlike
> this-command-keys. In fact, none of them return the prefix arg.
> 
> So 
> 
> (1) The docstring of this-single-command-keys needs to be fixed. 
> (2) NEWS also needs to mention that this-command-keys no longer returns prefix arg. 
> 
> Going forward (not for this bug or emacs-25): If someone can review that this-command-keys-vector and
> this-single-command-keys are ACTUALLY the same, can then this-single-command-keys be marked
> obsolete and an alias to the other for the next release? If that seems like the next action, I can file a separate
> bug report for that.

If this is a documentation bug, then it's not a documentation bug,
because it means one of the two variables should be obsoleted.

And I don't think the view that the current behavior is correct is
shared by everyone.

So I don't see how you can be so sure about this.

bug#22107: this-command-keys no longer returns prefix argument

[Kaushal Modi]

[-- Attachment #1: Type: text/plain, Size: 1321 bytes --]

On Fri, May 13, 2016 at 10:11 AM Eli Zaretskii <eliz@gnu.org> wrote:

> If this is a documentation bug, then it's not a documentation bug,
> because it means one of the two variables should be obsoleted.
>

I do not have enough experience with those functions enough to make a call
either way. I am simple trying to reach a closure for this issue. I just
recently stumbled upon this this-command-keys change between 24.5 and 25.x
versions. And I would like to have it fixed the correct way that the
consensus decides and at least have the documentation reflect the current
state of things.


> And I don't think the view that the current behavior is correct is
> shared by everyone.
>
> So I don't see how you can be so sure about this.
>

Looks like there's an unspoken consensus about how this-command-keys
behaves right now, and so this bug thread had been dead since Dec, until I
discovered this issue recently.

If this-single-command-keys has to be obsoleted, or if this-command-keys
has to be reverted, IMO this bug is a strong candidate to be able to delay
the 25.1 release (unlike what Dmitry thought of as a non important enough
blocking bug). So I had to speak up for this one in that emacs-devel thread.

I will willing to help in whatever way to help reach a good closure for
this bug.
-- 

-- 
Kaushal Modi

[-- Attachment #2: Type: text/html, Size: 1850 bytes --]

bug#22107: this-command-keys no longer returns prefix argument

[Stefan Monnier]

> AFAIR, Stefan thought that the current behavior is the correct one.

And indeed, looking at
https://github.com/kaushalmodi/.emacs.d/commit/912c4fc8bf4ed0c84e28dc837b0500b9a2e172ca,
it seems that it's the better behavior in that case as well.


        Stefan


PS: It's not just that "it's the correct behavior", but that the patch
introduced other problems.  I don't know how to fix those problems while
at the same time recovering the previous behavior of this-command-keys
(I'm not saying it's impossible, but I don't understand the code well
enough to figure it out).  And since I find this previous behavior
undesirable in general, I'm not highly motivated to try and "fix" the
problem ;-)