[Dan Nicolaescu] S-arrow_keys not working in cua-selection-mode anymore

[Dan Nicolaescu] S-arrow_keys not working in cua-selection-mode anymore

[Kim F. Storm]

Dan Nicolaescu has reported the following bug.

> In emacs CVS now S-{arrow key} does not work anymore in
> cua-selection-mode when using emacs -Q -nw in an xterm. 
> Not sure when this stopped working, I have a 2 months old version that
> still works.
>  
> The same thing works in pc-selection-mode, so the keys do send the
> right escape sequences.

  
Since I have not touched CUA mode in CVS for a long time, something
must have changed which breaks CUA mode in -nw mode.

CUA normally works by looking for a shift modifier on the event,
but it has special code to handle a non-windowing system:

   ((if window-system
	(memq 'shift (event-modifiers
		      (aref (this-single-command-raw-keys) 0)))
      (or
       (memq 'shift (event-modifiers
		     (aref (this-single-command-keys) 0)))
       ;; See if raw escape sequence maps to a shifted event, e.g. S-up or C-S-home.
       (and (boundp 'local-function-key-map)
	    local-function-key-map
	    (let ((ev (lookup-key local-function-key-map
				  (this-single-command-raw-keys))))
	      (and (vector ev)
		   (symbolp (setq ev (aref ev 0)))
		   (string-match "S-" (symbol-name ev)))))))


I can see that the multi-tty merge changed my original code to use
local-function-key-map instead of function-key-map.

IIRC, Stefan has since added input-decode-map to handle escape
sequence decoding - so I guess the code need to look into that
instead of OR in addition to local-function-key-map.

Since I haven't followed recent developments, I would appreciate
if someone could DTRT here.

Thanks!

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: [Dan Nicolaescu] S-arrow_keys not working in cua-selection-mode anymore

[Stefan Monnier]

> Since I have not touched CUA mode in CVS for a long time, something
> must have changed which breaks CUA mode in -nw mode.

> CUA normally works by looking for a shift modifier on the event,
> but it has special code to handle a non-windowing system:

>    ((if window-system
> 	(memq 'shift (event-modifiers
> 		      (aref (this-single-command-raw-keys) 0)))
>       (or
>        (memq 'shift (event-modifiers
> 		     (aref (this-single-command-keys) 0)))
>        ;; See if raw escape sequence maps to a shifted event, e.g. S-up or C-S-home.
>        (and (boundp 'local-function-key-map)
> 	    local-function-key-map
> 	    (let ((ev (lookup-key local-function-key-map
> 				  (this-single-command-raw-keys))))
> 	      (and (vector ev)
> 		   (symbolp (setq ev (aref ev 0)))
> 		   (string-match "S-" (symbol-name ev)))))))


> I can see that the multi-tty merge changed my original code to use
> local-function-key-map instead of function-key-map.

> IIRC, Stefan has since added input-decode-map to handle escape
> sequence decoding - so I guess the code need to look into that
> instead of OR in addition to local-function-key-map.

Oh, indeed, sorry for not catching this.  It should use input-decode-map
rather than local-function-key-map.  It may be even better to *also*
check local-function-key-map (after input-decode-map), but it shouldn't
be necessary.

This said, I'm not quite sure I understand enough of the above code:
why does it need to behave differently depending on window-system?


        Stefan

Re: [Dan Nicolaescu] S-arrow_keys not working in cua-selection-mode anymore

[Kim F. Storm]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> CUA normally works by looking for a shift modifier on the event,
>> but it has special code to handle a non-windowing system:
>
>>    ((if window-system
>> 	(memq 'shift (event-modifiers
>> 		      (aref (this-single-command-raw-keys) 0)))
>>       (or
>>        (memq 'shift (event-modifiers
>> 		     (aref (this-single-command-keys) 0)))
>>        ;; See if raw escape sequence maps to a shifted event, e.g. S-up or C-S-home.
>>        (and (boundp 'local-function-key-map)
>> 	    local-function-key-map
>> 	    (let ((ev (lookup-key local-function-key-map
>> 				  (this-single-command-raw-keys))))
>> 	      (and (vector ev)
>> 		   (symbolp (setq ev (aref ev 0)))
>> 		   (string-match "S-" (symbol-name ev)))))))
>
>
> Oh, indeed, sorry for not catching this.  It should use input-decode-map
> rather than local-function-key-map.  

Ok.  Could someone please make the change (trunk only!!).  Thanks!

>                                      It may be even better to *also*
> check local-function-key-map (after input-decode-map), but it shouldn't
> be necessary.

Huh?  It may be better ... but not necessary ??

> This said, I'm not quite sure I understand enough of the above code:
> why does it need to behave differently depending on window-system?

The problem is to get around the implicit translation of "Shift-XXX" to
"XXX" if "Shift-XXX" has no specific binding.

On a window-system, this-single-command-raw-keys returns the untranslated
keys, so I can use it to check directly if user pressed a shifted key.

The problem is (or was??) how to test for a shifted function key
on a non-window system.

Suppose S-up sends "ESC A B" in xterm.

Then this-single-command-raw-keys returns [27 65 66].
This is not useful.

And this-single-command-keys returns [up].
This is not useful either.

So the only way is to go back to the raw key sequence and look it up
in the function key translation map to see if the result is a shifted key.

If you have a better way of checking this, I'm listening :-)


-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: [Dan Nicolaescu] S-arrow_keys not working in cua-selection-mode anymore

[Stefan Monnier]

>>> CUA normally works by looking for a shift modifier on the event,
>>> but it has special code to handle a non-windowing system:
>> 
>>> ((if window-system
>>> (memq 'shift (event-modifiers
>>> (aref (this-single-command-raw-keys) 0)))
>>> (or
>>> (memq 'shift (event-modifiers
>>> (aref (this-single-command-keys) 0)))
>>> ;; See if raw escape sequence maps to a shifted event, e.g. S-up or C-S-home.
>>> (and (boundp 'local-function-key-map)
>>> local-function-key-map
>>> (let ((ev (lookup-key local-function-key-map
>>> (this-single-command-raw-keys))))
>>> (and (vector ev)
>>> (symbolp (setq ev (aref ev 0)))
>>> (string-match "S-" (symbol-name ev)))))))
>> 
>> 
>> Oh, indeed, sorry for not catching this.  It should use input-decode-map
>> rather than local-function-key-map.  
> Ok.  Could someone please make the change (trunk only!!).  Thanks!

I'll do it.

>> It may be even better to *also*
>> check local-function-key-map (after input-decode-map), but it shouldn't
>> be necessary.

> Huh?  It may be better ... but not necessary ??

Since until Emacs-23, function-key-map was used for such things, some
users may have added decoding entries to their function-key-map.
For this reason it may be better to check that map as well.  But it's
probably not very important.  Also it may be undesirable (before
function-key-map, the keys are kind of like X11's
this-single-command-raw-keys, whereas after function-key-map, they may
be somewhat different: removal of shift could be implemented in
function-key-map for example).

>> This said, I'm not quite sure I understand enough of the above code:
>> why does it need to behave differently depending on window-system?

> The problem is to get around the implicit translation of "Shift-XXX" to
> "XXX" if "Shift-XXX" has no specific binding.

> On a window-system, this-single-command-raw-keys returns the untranslated
> keys, so I can use it to check directly if user pressed a shifted key.

> The problem is (or was??) how to test for a shifted function key
> on a non-window system.

> Suppose S-up sends "ESC A B" in xterm.

> Then this-single-command-raw-keys returns [27 65 66].
> This is not useful.

> And this-single-command-keys returns [up].
> This is not useful either.

> So the only way is to go back to the raw key sequence and look it up
> in the function key translation map to see if the result is a shifted key.

> If you have a better way of checking this, I'm listening :-)

I understand the need for the tty version of the code, but I'm wondering
why that branch can't be used equally well for the window-system case.
I.e. I suggest the code below instead:

    ((or
      (memq 'shift (event-modifiers
                   (aref (this-single-command-keys) 0)))
      ;; See if raw escape sequence maps to a shifted event, e.g. S-up or C-S-home.
      (let ((ev (lookup-key input-decode-map
                            (this-single-command-raw-keys))))
        (if (vector ev)
            (and (symbolp (setq ev (aref ev 0)))
                 (string-match "S-" (symbol-name ev)))
          (memq 'shift (event-modifiers
                        (aref (this-single-command-raw-keys) 0))))))



        Stefan

Re: [Dan Nicolaescu] S-arrow_keys not working in cua-selection-mode anymore

[Kim F. Storm]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> I'll do it.
>
Thanks.

>
> I understand the need for the tty version of the code, but I'm wondering
> why that branch can't be used equally well for the window-system case.
> I.e. I suggest the code below instead:
>
>     ((or
>       (memq 'shift (event-modifiers
>                    (aref (this-single-command-keys) 0)))
>       ;; See if raw escape sequence maps to a shifted event, e.g. S-up or C-S-home.
>       (let ((ev (lookup-key input-decode-map
>                             (this-single-command-raw-keys))))
>         (if (vector ev)
>             (and (symbolp (setq ev (aref ev 0)))
>                  (string-match "S-" (symbol-name ev)))
>           (memq 'shift (event-modifiers
>                         (aref (this-single-command-raw-keys) 0))))))
>

It might work, yes, but the window system code is faster, simpler, and
has worked fine (at least in my experience).

So I don't see a reason to go through the "tricky -nw path" also on
window systems ... just to end up doing the same thing as before.

But perhaps there us some benefit of going through input-decode-map
also on window systems?

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: [Dan Nicolaescu] S-arrow_keys not working in cua-selection-mode anymore

[Stefan Monnier]

>> I'll do it.
> Thanks.

Done.


        Stefan