unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* [Dan Nicolaescu] S-arrow_keys not working in cua-selection-mode anymore
@ 2007-11-13 14:32 Kim F. Storm
  2007-11-13 15:20 ` Stefan Monnier
  0 siblings, 1 reply; 6+ messages in thread
From: Kim F. Storm @ 2007-11-13 14:32 UTC (permalink / raw)
  To: emacs-devel; +Cc: Dan Nicolaescu


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

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [Dan Nicolaescu] S-arrow_keys not working in cua-selection-mode anymore
  2007-11-13 14:32 [Dan Nicolaescu] S-arrow_keys not working in cua-selection-mode anymore Kim F. Storm
@ 2007-11-13 15:20 ` Stefan Monnier
  2007-11-14 11:45   ` Kim F. Storm
  0 siblings, 1 reply; 6+ messages in thread
From: Stefan Monnier @ 2007-11-13 15:20 UTC (permalink / raw)
  To: Kim F. Storm; +Cc: Dan Nicolaescu, emacs-devel

> 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

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [Dan Nicolaescu] S-arrow_keys not working in cua-selection-mode anymore
  2007-11-13 15:20 ` Stefan Monnier
@ 2007-11-14 11:45   ` Kim F. Storm
  2007-11-14 15:14     ` Stefan Monnier
  0 siblings, 1 reply; 6+ messages in thread
From: Kim F. Storm @ 2007-11-14 11:45 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: Dan Nicolaescu, emacs-devel

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

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [Dan Nicolaescu] S-arrow_keys not working in cua-selection-mode anymore
  2007-11-14 11:45   ` Kim F. Storm
@ 2007-11-14 15:14     ` Stefan Monnier
  2007-11-15 12:52       ` Kim F. Storm
  0 siblings, 1 reply; 6+ messages in thread
From: Stefan Monnier @ 2007-11-14 15:14 UTC (permalink / raw)
  To: Kim F. Storm; +Cc: Dan Nicolaescu, emacs-devel

>>> 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

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [Dan Nicolaescu] S-arrow_keys not working in cua-selection-mode anymore
  2007-11-14 15:14     ` Stefan Monnier
@ 2007-11-15 12:52       ` Kim F. Storm
  2007-11-15 16:36         ` Stefan Monnier
  0 siblings, 1 reply; 6+ messages in thread
From: Kim F. Storm @ 2007-11-15 12:52 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: Dan Nicolaescu, emacs-devel

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

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [Dan Nicolaescu] S-arrow_keys not working in cua-selection-mode anymore
  2007-11-15 12:52       ` Kim F. Storm
@ 2007-11-15 16:36         ` Stefan Monnier
  0 siblings, 0 replies; 6+ messages in thread
From: Stefan Monnier @ 2007-11-15 16:36 UTC (permalink / raw)
  To: Kim F. Storm; +Cc: Dan Nicolaescu, emacs-devel

>> I'll do it.
> Thanks.

Done.


        Stefan

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2007-11-15 16:36 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-11-13 14:32 [Dan Nicolaescu] S-arrow_keys not working in cua-selection-mode anymore Kim F. Storm
2007-11-13 15:20 ` Stefan Monnier
2007-11-14 11:45   ` Kim F. Storm
2007-11-14 15:14     ` Stefan Monnier
2007-11-15 12:52       ` Kim F. Storm
2007-11-15 16:36         ` Stefan Monnier

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).