bug#24577: 25.1; Proposal to improve C-u C-h c behavior

bug#24577: 25.1; Proposal to improve C-u C-h c behavior

[Dmitri Paduchikh]

Hello,

C-u C-h c does not work in read-only buffers. And even if the buffer is
writable it's rarely an appropriate place to insert info about key
bindings. I think it would be better if C-u C-h c placed its output into
kill ring and printed it in the echo area instead of the current
behavior.

Regards,
Dmitri Paduchikh

bug#24577: 25.1; Proposal to improve C-u C-h c behavior

[Ivan Shmakov]

>>>>> Dmitri Paduchikh <dpaduchikh@gmail.com> writes:

 > C-u C-h c does not work in read-only buffers.  And even if the buffer
 > is writable it's rarely an appropriate place to insert info about key
 > bindings.  I think it would be better if C-u C-h c placed its output
 > into kill ring and printed it in the echo area instead of the current
 > behavior.

	I believe that this behavior is a common idiom in Emacs.
	For example, M-! date RET shows the current date and time in
	echo area, while C-u M-! date RET inserts it at point – with
	both actions making sense depending on the situation.

	I guess C-u C-h c behavior is mainly useful when writing about
	Emacs itself (including writing bug reports, or conversing on
	IRC, etc.), but I can easily see it being handy nevertheless.

	Also, for read-only buffers, one can use C-h c without C-u, and
	then copy the result from the *Messages* buffer.

	On the other hand, I’m not aware of any of Emacs commands adding
	the result of some operation directly to the kill ring.

-- 
FSF associate member #7257  http://am-1.org/~ivan/      … 3013 B6A0 230E 334A

bug#24577: 25.1; Proposal to improve C-u C-h c behavior

[Eli Zaretskii]

> From: Ivan Shmakov <ivan@siamics.net>
> Date: Sat, 01 Oct 2016 05:40:40 +0000
> Cc: Dmitri Paduchikh <dpaduchikh@gmail.com>
> 
> >>>>> Dmitri Paduchikh <dpaduchikh@gmail.com> writes:
> 
>  > C-u C-h c does not work in read-only buffers.  And even if the buffer
>  > is writable it's rarely an appropriate place to insert info about key
>  > bindings.  I think it would be better if C-u C-h c placed its output
>  > into kill ring and printed it in the echo area instead of the current
>  > behavior.
> 
> 	I believe that this behavior is a common idiom in Emacs.
> 	For example, M-! date RET shows the current date and time in
> 	echo area, while C-u M-! date RET inserts it at point – with
> 	both actions making sense depending on the situation.
> 
> 	I guess C-u C-h c behavior is mainly useful when writing about
> 	Emacs itself (including writing bug reports, or conversing on
> 	IRC, etc.), but I can easily see it being handy nevertheless.
> 
> 	Also, for read-only buffers, one can use C-h c without C-u, and
> 	then copy the result from the *Messages* buffer.
> 
> 	On the other hand, I’m not aware of any of Emacs commands adding
> 	the result of some operation directly to the kill ring.

100% agreement.

bug#24577: 25.1; Proposal to improve C-u C-h c behavior

[Dmitri Paduchikh]

Eli Zaretskii <eliz@gnu.org> wrote:

>> From: Ivan Shmakov <ivan@siamics.net>
>> Date: Sat, 01 Oct 2016 05:40:40 +0000
>> Cc: Dmitri Paduchikh <dpaduchikh@gmail.com>
>> 
>> >>>>> Dmitri Paduchikh <dpaduchikh@gmail.com> writes:
>> 
>>  > C-u C-h c does not work in read-only buffers.  And even if the buffer
>>  > is writable it's rarely an appropriate place to insert info about key
>>  > bindings.  I think it would be better if C-u C-h c placed its output
>>  > into kill ring and printed it in the echo area instead of the current
>>  > behavior.
>> 
>>       I believe that this behavior is a common idiom in Emacs.
>>       For example, M-! date RET shows the current date and time in
>>       echo area, while C-u M-! date RET inserts it at point – with
>>       both actions making sense depending on the situation.

There is a difference here. You are calling C-u M-! at the place where
you want its output, whereas C-u C-h c has to be called at the place
when the key is defined, and that place is rarely the same where you
want to insert the key description.

>>       I guess C-u C-h c behavior is mainly useful when writing about
>>       Emacs itself (including writing bug reports, or conversing on
>>       IRC, etc.), but I can easily see it being handy nevertheless.

I agree that main use of C-u C-h c is when writing about Emacs itself,
but the part about being handy nevertheless I didn't understand. I
didn't propose to remove it, just make it more handy.

>>       Also, for read-only buffers, one can use C-h c without C-u, and
>>       then copy the result from the *Messages* buffer.

In other words, you are suggesting not to use C-u C-h c and simply work
around the issue. But since you prefer not to use it, then you won't
suffer from the behavior change.

>>       On the other hand, I’m not aware of any of Emacs commands adding
>>       the result of some operation directly to the kill ring.

I have seen the proposed behavior in emacs-w3m where w3m-print-this-url
behaves in this manner. It is convenient. Please note that message in
the echo area may contain the indication that the description has been
copied into kill ring. I think this would remove any possible confusion.

EZ> 100% agreement.

Regards,
Dmitri Paduchikh

bug#24577: 25.1; Proposal to improve C-u C-h c behavior

[Eli Zaretskii]

> From: Dmitri Paduchikh <dpaduchikh@gmail.com>
> Cc: Ivan Shmakov <ivan@siamics.net>,  24577@debbugs.gnu.org
> Date: Sat, 01 Oct 2016 13:38:45 +0500
> 
> >>       On the other hand, I’m not aware of any of Emacs commands adding
> >>       the result of some operation directly to the kill ring.
> 
> I have seen the proposed behavior in emacs-w3m where w3m-print-this-url
> behaves in this manner.

Then perhaps we could have both behaviors, one after a single "C-u",
the other after two "C-u"s.

bug#24577: 25.1; Proposal to improve C-u C-h c behavior

[Dmitri Paduchikh]

Eli Zaretskii <eliz@gnu.org> wrote:

EZ> Then perhaps we could have both behaviors, one after a single "C-u",
EZ> the other after two "C-u"s.

This would be fine. Especially if C-u invoked the new behavior, and the
current behavior was moved to C-u C-u as less useful.

Regards,
Dmitri Paduchikh

bug#24577: 25.1; Proposal to improve C-u C-h c behavior

[Dmitri Paduchikh]

I can propose one more variant of behavior: C-u C-h c asks user for
buffer where to insert the description.

Regards,
Dmitri Paduchikh

bug#24577: 25.1; Proposal to improve C-u C-h c behavior

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> >>       On the other hand, I’m not aware of any of Emacs commands adding
>> >>       the result of some operation directly to the kill ring.
>> 
>> I have seen the proposed behavior in emacs-w3m where w3m-print-this-url
>> behaves in this manner.
>
> Then perhaps we could have both behaviors, one after a single "C-u",
> the other after two "C-u"s.

(I'm going through old bug reports that unfortunately weren't resolved
at the time.)

In my opinion, this would complicate this command needlessly because I
don't think this would be used a lot.  The user can always jump to the
*Messages* buffer if they want to yank the message, and that works for
all commands like this, not just `C-h c'.

So I'm therefore closing this bug report.

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

bug#24577: 25.1; Proposal to improve C-u C-h c behavior

[Andreas Schwab]

On Okt 01 2016, Ivan Shmakov <ivan@siamics.net> wrote:

> 	Also, for read-only buffers, one can use C-h c without C-u, and
> 	then copy the result from the *Messages* buffer.

Or temporarily switch to a writable buffer.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

bug#24577: 25.1; Proposal to improve C-u C-h c behavior

[Marcin Borkowski]

On 2016-10-01, at 07:40, Ivan Shmakov <ivan@siamics.net> wrote:

> 	On the other hand, I’m not aware of any of Emacs commands adding
> 	the result of some operation directly to the kill ring.

For the record:

dired-copy-filename-as-kill
quick-calc (note that C-u'ing it inserts the result at point!)

Best,

-- 
Marcin Borkowski