bug#42708: Let users copy "*Char Help*" buffer

bug#42708: Let users copy "*Char Help*" buffer

[積丹尼 Dan Jacobson]

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

There is a buffer "*Char Help*" that emacs makes sure the user is never
able to copy. (What if Stallman found out about this?)

First, if the user tries C-x o, to maneuver from the minibuffer into the
*Char Help* buffer, emacs already knows the user will try this trick,
and thwarts it right away, despite C-x not being explicitly listed in
the prompt,


[-- Attachment #2: *Char Help* prompt --]
[-- Type: image/jpeg, Size: 18757 bytes --]

[-- Attachment #3: Type: text/plain, Size: 851 bytes --]


Second, one might think "Oh, the *Char Help* buffer might be left around
later and then we can copy it." Nope, the emacs police have that one
covered too. It is destroyed right away after use, faster than Jim
Phelps' burning classified audio tape in Mission Impossible.

There is only one place that those "you are not allowed to copy" police
cannot control: when viewed with emacs -nw. (Oops, I leaked it.) Else
one's only option is a screenshot.

So where does one encounter this disappearing "*Char Help*" buffer?
Well when using
  C runs the command dired-do-copy (found in dired-mode-map), which is
  an interactive autoloaded compiled Lisp function in ‘dired-aux.el’.

emacs-version "26.3"

And why would one want to copy the contents of the boring "*Char Help*"
buffer? Well, that's the subject of my next bug report...

bug#42708: Let users copy "*Char Help*" buffer

[Juri Linkov]

> There is a buffer "*Char Help*" that emacs makes sure the user is never
> able to copy. (What if Stallman found out about this?)

Actually you can copy it after signing an NDA.

> There is only one place that those "you are not allowed to copy" police
> cannot control: when viewed with emacs -nw. (Oops, I leaked it.) Else
> one's only option is a screenshot.

This patch should allow copying freely:

diff --git a/lisp/dired-aux.el b/lisp/dired-aux.el
index efb214088d..7bad4a720c 100644
--- a/lisp/dired-aux.el
+++ b/lisp/dired-aux.el
@@ -1266,7 +1266,7 @@ dired-query
 			     (format " [Type yn!q or %s] "
 				     (key-description (vector help-char)))
 			   " [Type y, n, q or !] ")))
-	   (set sym (setq char (read-char-choice prompt char-choices)))
+	   (set sym (setq char (read-char-from-minibuffer prompt char-choices)))
 	   (if (memq char '(?y ?\s ?!)) t)))))
 
 \f

bug#42708: Let users copy "*Char Help*" buffer

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

> This patch should allow copying freely:

[...]

> -	   (set sym (setq char (read-char-choice prompt char-choices)))
> +	   (set sym (setq char (read-char-from-minibuffer prompt char-choices)))
>  	   (if (memq char '(?y ?\s ?!)) t)))))

Makes sense to me...

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

bug#42708: Let users copy "*Char Help*" buffer

[Juri Linkov]

>> -	   (set sym (setq char (read-char-choice prompt char-choices)))
>> +	   (set sym (setq char (read-char-from-minibuffer prompt char-choices)))
>>  	   (if (memq char '(?y ?\s ?!)) t)))))
>
> Makes sense to me...

Oh, I noticed it doesn't support 'C-h' that should pop up the buffer
" *Char Help*" from the dynamic variable 'help-form'.

Then maybe we should rewrite read-char-choice to use read-char-from-minibuffer?

bug#42708: Let users copy "*Char Help*" buffer

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

> Oh, I noticed it doesn't support 'C-h' that should pop up the buffer "
> *Char Help*" from the dynamic variable 'help-form'.
>
> Then maybe we should rewrite read-char-choice to use
> read-char-from-minibuffer?

Yes, that's even better -- then all the callers to read-char-choice
would no longer be as modal as they are now.

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

bug#42708: Let users copy "*Char Help*" buffer

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Juri Linkov <juri@linkov.net> writes:
>
>> Oh, I noticed it doesn't support 'C-h' that should pop up the buffer "
>> *Char Help*" from the dynamic variable 'help-form'.
>>
>> Then maybe we should rewrite read-char-choice to use
>> read-char-from-minibuffer?
>
> Yes, that's even better -- then all the callers to read-char-choice
> would no longer be as modal as they are now.

I've now done this on the trunk.

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

bug#42708: Let users copy "*Char Help*" buffer

[Drew Adams]

> > Juri Linkov <juri@linkov.net> writes:
> >
> >> Oh, I noticed it doesn't support 'C-h' that should pop up the buffer "
> >> *Char Help*" from the dynamic variable 'help-form'.
> >>
> >> Then maybe we should rewrite read-char-choice to use
> >> read-char-from-minibuffer?
> >
> > Yes, that's even better -- then all the callers to read-char-choice
> > would no longer be as modal as they are now.
> 
> I've now done this on the trunk.

This is another step backward.  If you want to
use a read-a-character-using-minibuffer function
here or there you should just it directly.

`read-char-choice' should not have been co-opted
to use the minibuffer.  Big mistake in UI.

There are good use cases for the classic `read-char'
and `read-char-choice', which read an event WITHOUT
involving the minibuffer.  Using the minibuffer for
everything is just wrong, very wrong.

(And I'm saying this as someone who makes extensive
use of the minibuffer.)

Use a read-using-minibuffer function when it makes
sense to do that.  Not every (or even most - maybe
not any?) uses of `read-char-choice' should involve
the minibuffer.  Those that should could of course
be changed to use the minibuffer.  Certainly not all.

This has really become a have-hammer-see-only-nails
phenomenon, IMHO.

bug#42708: Let users copy "*Char Help*" buffer

[Juri Linkov]

>>> Oh, I noticed it doesn't support 'C-h' that should pop up the buffer "
>>> *Char Help*" from the dynamic variable 'help-form'.
>>>
>>> Then maybe we should rewrite read-char-choice to use
>>> read-char-from-minibuffer?
>>
>> Yes, that's even better -- then all the callers to read-char-choice
>> would no longer be as modal as they are now.
>
> I've now done this on the trunk.

I tried to reproduce the original test case. i.e. to type 'C'
(dired-do-copy) and select the "*Char Help*" buffer with C-x o.
The result is weird: the cursor in displayed in the minibuffer,
but the selected window is "*Char Help*".  Here's a patch to fix this:

diff --git a/lisp/subr.el b/lisp/subr.el
index 286851dfc8..606ce004d5 100644
--- a/lisp/subr.el
+++ b/lisp/subr.el
@@ -2610,8 +2610,7 @@ read-char-choice
   (unless (consp chars)
     (error "Called `read-char-choice' without valid char choices"))
   (let (char done show-help (helpbuf " *Char Help*"))
-    (let ((cursor-in-echo-area t)
-          (executing-kbd-macro executing-kbd-macro)
+    (let ((executing-kbd-macro executing-kbd-macro)
 	  (esc-flag nil))
       (save-window-excursion	      ; in case we call help-form-show
 	(while (not done)

After looking more at 'read-char-choice', it seems that special handling
of 'inhibit-keyboard-quit' and 'executing-kbd-macro' is not needed
anymore?  And maybe also adding the 'minibuffer-prompt' face is not
needed too.  Then what remains to do in 'read-char-choice' is to call
'read-char-from-minibuffer' and to show 'help-form-show' for 'help-char' key?

bug#42708: Let users copy "*Char Help*" buffer

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

> I tried to reproduce the original test case. i.e. to type 'C'
> (dired-do-copy) and select the "*Char Help*" buffer with C-x o.
> The result is weird: the cursor in displayed in the minibuffer,
> but the selected window is "*Char Help*".  Here's a patch to fix this:

[...]

> -    (let ((cursor-in-echo-area t)
> -          (executing-kbd-macro executing-kbd-macro)
> +    (let ((executing-kbd-macro executing-kbd-macro)

I haven't tried the patch -- does this have any other effect than fixing
the problem with the cursor in the wrong buffer?  I'm not quite clear on
what the effects of cursor-in-echo-area are...

> After looking more at 'read-char-choice', it seems that special handling
> of 'inhibit-keyboard-quit' and 'executing-kbd-macro' is not needed
> anymore?  And maybe also adding the 'minibuffer-prompt' face is not
> needed too.  Then what remains to do in 'read-char-choice' is to call
> 'read-char-from-minibuffer' and to show 'help-form-show' for 'help-char' key?

Sounds reasonable (without having looked at the code more than
cursorily).

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

bug#42708: Let users copy "*Char Help*" buffer

[Juri Linkov]

>> I tried to reproduce the original test case. i.e. to type 'C'
>> (dired-do-copy) and select the "*Char Help*" buffer with C-x o.
>> The result is weird: the cursor in displayed in the minibuffer,
>> but the selected window is "*Char Help*".  Here's a patch to fix this:
>
> [...]
>
>> -    (let ((cursor-in-echo-area t)
>> -          (executing-kbd-macro executing-kbd-macro)
>> +    (let ((executing-kbd-macro executing-kbd-macro)
>
> I haven't tried the patch -- does this have any other effect than fixing
> the problem with the cursor in the wrong buffer?  I'm not quite clear on
> what the effects of cursor-in-echo-area are...

No other effect, cursor-in-echo-area was necessary when 'read-char-choice'
relied on 'read-key'.

>> After looking more at 'read-char-choice', it seems that special handling
>> of 'inhibit-keyboard-quit' and 'executing-kbd-macro' is not needed
>> anymore?  And maybe also adding the 'minibuffer-prompt' face is not
>> needed too.  Then what remains to do in 'read-char-choice' is to call
>> 'read-char-from-minibuffer' and to show 'help-form-show' for 'help-char' key?
>
> Sounds reasonable (without having looked at the code more than
> cursorily).

Then what remains in 'read-char-choice' after this clean-up,
is just a call to 'read-char-from-minibuffer' and handling 'help-char'
by calling 'help-form-show'.  OTOH, 'help-form-show' can be simply bound
to 'help-char' in 'read-char-from-minibuffer-map'.  So I'm lost what
would be better to do.  I see 2 variants:

1. Declare 'read-char-choice' as an equivalent of 'read-char-from-minibuffer',
   but with additional handling of 'help-char';

2. Add handling of 'help-char' to 'read-char-from-minibuffer',
   and leave 'read-char-choice' unchanged, then replace all calls
   of 'read-char-choice' with 'read-char-from-minibuffer' calls
   in the Emacs source tree.

bug#42708: Let users copy "*Char Help*" buffer

[Drew Adams]

> No other effect, cursor-in-echo-area was necessary when
> 'read-char-choice' relied on 'read-key'.

Seriously?  You've not only introduced a new function,
`read-char-from-minibuffer', AND used it here and there
(everywhere?) in place of `read-char` and `read-key`,
but you've ALSO changed the behavior of `read-char-choice`,
so it too no longer reads a char in the longstanding,
useful way, which we can count to NOT use the minibuffer?

FTR, here's one user who strongly objects.  You knew that,
generally.  Now you know it for `read-char-choice' in
particular.  Hey, why didn't you just redefine `read-char'
while you were at it?

> Then what remains in 'read-char-choice' after this clean-up,
> is just a call to 'read-char-from-minibuffer' and handling 'help-char'
> by calling 'help-form-show'.  OTOH, 'help-form-show' can be simply
> bound
> to 'help-char' in 'read-char-from-minibuffer-map'.  So I'm lost what
> would be better to do.  I see 2 variants:
> 
> 1. Declare 'read-char-choice' as an equivalent of 'read-char-from-
>    minibuffer', but with additional handling of 'help-char';
> 
> 2. Add handling of 'help-char' to 'read-char-from-minibuffer',
>    and leave 'read-char-choice' unchanged, then replace all calls
>    of 'read-char-choice' with 'read-char-from-minibuffer' calls
>    in the Emacs source tree.

Alas.

bug#42708: Let users copy "*Char Help*" buffer

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > FTR, here's one user who strongly objects.  You knew that,
  > generally.  Now you know it for `read-char-choice' in
  > particular.  Hey, why didn't you just redefine `read-char'
  > while you were at it?

I might agree with the substance of your point, but the tone is very
harsh.  THe last sentence is sarcastic.

Please don't talk to people that way here.  People who are treated
harshly tend to respond with more hashness, and that makes
participation painful.  Please express your views without making
anyone feel attacked.



-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

bug#42708: Let users copy "*Char Help*" buffer

[Juri Linkov]

>> No other effect, cursor-in-echo-area was necessary when
>> 'read-char-choice' relied on 'read-key'.
>
> Seriously?  You've not only introduced a new function,
> `read-char-from-minibuffer', AND used it here and there
> (everywhere?) in place of `read-char` and `read-key`,
> but you've ALSO changed the behavior of `read-char-choice`,
> so it too no longer reads a char in the longstanding,
> useful way, which we can count to NOT use the minibuffer?

This is a false accusation.  I have NOT changed the behavior of
`read-char-choice`,

bug#42708: Let users copy "*Char Help*" buffer

[Drew Adams]

> >> No other effect, cursor-in-echo-area was necessary when
> >> 'read-char-choice' relied on 'read-key'.
> >
> > Seriously?  You've not only introduced a new function,
> > `read-char-from-minibuffer', AND used it here and there
> > (everywhere?) in place of `read-char` and `read-key`,
> > but you've ALSO changed the behavior of `read-char-choice`,
> > so it too no longer reads a char in the longstanding,
> > useful way, which we can count to NOT use the minibuffer?
> 
> This is a false accusation.  I have NOT changed the behavior of
> `read-char-choice`,

It was actually a question, not an accusation, but yes, the
word order wasn't interrogative, unfortunately.  Instead of
"You're going to the store?", I should have asked it as
"Are you going to the store?"

Apologies, if you did not, in fact, change `read-char-choice'.
That answers the question in a way that reassures me.

My question was in response to your message where (I thought)
you described some changes ("clean-up") to `read-char-choice',
including (I thought) that it no longer uses `read-key', and
you then said:

  "what remains in 'read-char-choice' after this clean-up,
   is just a call to 'read-char-from-minibuffer'..."

If `read-char-choice' will not, in fact, be changed to use
`read-char-from-minibuffer' then that will be good, IMO.
I hope such a change does not occur; let me put it that way.

Again, apologies if I misunderstood, and for any heard
false accusations.

As you know, I'm not happy about uses of `read-char' etc.
having been replaced by `read-char-from-minibuffer'.  I
also wouldn't be happy about wholesale replacement of uses
of `read-char-choice' by `read-char-from-minibuffer'.
Maybe it makes sense to replace some such occurrences, but
it would be good to see some justification case by case.

But if `read-char-choice' can itself remain in the
`read-char', `read-event', `read-key', etc. camp, then at
least that will be good, IMO.  Thx.

bug#42708: Let users copy "*Char Help*" buffer

[Juri Linkov]

> I also wouldn't be happy about wholesale replacement of uses
> of `read-char-choice' by `read-char-from-minibuffer'.
> Maybe it makes sense to replace some such occurrences, but
> it would be good to see some justification case by case.

Actually, only one occurrence of `read-char-choice'
was replaced by `read-char-from-minibuffer'.

> But if `read-char-choice' can itself remain in the
> `read-char', `read-event', `read-key', etc. camp, then at
> least that will be good, IMO.  Thx.

Yes, `read-char-choice' remains in that camp unchanged.

bug#42708: Let users copy "*Char Help*" buffer

[Drew Adams]

> > I also wouldn't be happy about wholesale replacement of uses
> > of `read-char-choice' by `read-char-from-minibuffer'.
> > Maybe it makes sense to replace some such occurrences, but
> > it would be good to see some justification case by case.
>
> Actually, only one occurrence of `read-char-choice'
> was replaced by `read-char-from-minibuffer'.

Good.

Could we please know which occurrence you changed,
and what the justification is?

> > But if `read-char-choice' can itself remain in the
> > `read-char', `read-event', `read-key', etc. camp, then at
> > least that will be good, IMO.  Thx.
> 
> Yes, `read-char-choice' remains in that camp unchanged.

Good.  Thanks for that.

bug#42708: Let users copy "*Char Help*" buffer

[Juri Linkov]

>> > I also wouldn't be happy about wholesale replacement of uses
>> > of `read-char-choice' by `read-char-from-minibuffer'.
>> > Maybe it makes sense to replace some such occurrences, but
>> > it would be good to see some justification case by case.
>>
>> Actually, only one occurrence of `read-char-choice'
>> was replaced by `read-char-from-minibuffer'.
>
> Good.
>
> Could we please know which occurrence you changed,
> and what the justification is?

The changed occurrence is 'dired-query',
and the justification is to fix the bug report #42708.

Also I checked other 4 occurrences of `read-char-choice' in
auth-source.el, emacs-lisp/package.el, net/tramp-cmds.el
and progmodes/octave.el.  But apparently they use more complex
logic, so replacing them with `read-char-from-minibuffer'
is not a straightforward task.

>> > But if `read-char-choice' can itself remain in the
>> > `read-char', `read-event', `read-key', etc. camp, then at
>> > least that will be good, IMO.  Thx.
>>
>> Yes, `read-char-choice' remains in that camp unchanged.
>
> Good.  Thanks for that.

bug#42708: Let users copy "*Char Help*" buffer

[Drew Adams]

> > Could we please know which occurrence you changed,
> > and what the justification is?
> 
> The changed occurrence is 'dired-query',
> and the justification is to fix the bug report #42708.
> 
> Also I checked other 4 occurrences of `read-char-choice' in
> auth-source.el, emacs-lisp/package.el, net/tramp-cmds.el
> and progmodes/octave.el.  But apparently they use more complex
> logic, so replacing them with `read-char-from-minibuffer'
> is not a straightforward task.

Thanks.
That's probably OK.  I'll have to see, in practice.

FWIW, my (Dired+) version of `dired-query' also allows char
`l', which lists the files to be acted on, showing details
per option `diredp-list-file-attributes':

  diredp-list-file-attributes is a variable defined in `dired+.el'.
  Its value is (5 8)

  Documentation:
  Which file attributes `diredp-list-file' uses, and when.
  A list of file attribute numbers means use only the values of those
  attributes.
  A non-list means use all attribute values.

bug#42708: Let users copy "*Char Help*" buffer

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

> 1. Declare 'read-char-choice' as an equivalent of 'read-char-from-minibuffer',
>    but with additional handling of 'help-char';
>
> 2. Add handling of 'help-char' to 'read-char-from-minibuffer',
>    and leave 'read-char-choice' unchanged, then replace all calls
>    of 'read-char-choice' with 'read-char-from-minibuffer' calls
>    in the Emacs source tree.

I'd go for 2, I think.  These functions are so similar in what they
offer that it doesn't make much sense in having both.

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

bug#42708: Let users copy "*Char Help*" buffer

[Juri Linkov]

>> 2. Add handling of 'help-char' to 'read-char-from-minibuffer',
>>    and leave 'read-char-choice' unchanged, then replace all calls
>>    of 'read-char-choice' with 'read-char-from-minibuffer' calls
>>    in the Emacs source tree.
>
> I'd go for 2, I think.  These functions are so similar in what they
> offer that it doesn't make much sense in having both.

So I pushed 2 to master.  Please check if everything is alright.
Hope this will make Drew happy.