[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] input: allow distinguishing shifted from unshifted Meta keys

From: Brand Huntsman
Subject: Re: [PATCH] input: allow distinguishing shifted from unshifted Meta keystrokes
Date: Thu, 12 Dec 2019 15:33:28 -0700

On Wed, 11 Dec 2019 16:24:25 +0100
Benno Schulenberg <address@hidden> wrote:

> > I don't agree with adding an option that requires changing all
> > existing meta binds to lowercase before adding shifted binds.  
> In a subsequent patch, all default Meta binds will be lowercased when
> the user sets 'splitmeta'.  Any Meta binds that the user herself has
> made in her nanorc, she will have to lowercase first before starting
> to use 'set splitmeta'.  I don't think that is too much to ask.

I wasn't referring to the default binds, but the fact that existing 
user-defined binds must be manually changed to lowercase. The S modifier just 
works and doesn't require the user to set an option or change any existing 

> > The patch I've been using for a while adds an S modifier to bind
> > shifted keys, M-S-A is shifted M-A.  
> Hmm.  I don't like that much, five characters to describe one
> keystroke.

Vim uses the S modifier.

But vim uses lowercase a-z which makes it easier to read (S-s vs S-S). It would 
be nice to use/require lowercase letters but changing the default behavior 
creates friction for users. Maybe there could be an option.

> > I forgot to mention that shifted, meta and meta-shifted Fn key
> > combos are possible, and the S modifier would allow them to be
> > added in the future.

Did you see this additional email from me? Do you not want to leave the 
possibility of adding those keys in the future?

> That can't be helped, that is how CapsLock works.  What we could do
> is ask upstream (Xorg?) to ignore CapsLock when Alt is held.
> (Firefox and Thunderbird already ignore both CapsLock and Shift when
> Alt is held.  Xfce ignores CapsLock but does not ignore Shift -- for
> example, in Xfce Terminal, Alt+h will open the Help menu, but
> Shift+Alt+h will just beep.  Weird.)

The problem isn't xorg, it is the terminal emulators and how they map the 
keyboard state to sequences of characters. All graphical programs, including 
terminal emulators, can see modifiers and capslock state.

> > This doesn't happen when binding the "end" function to M-$.  
> For me, it also happens when binding 'end'.  For example:
>   bind M-$ "^[[F" main
>   bind M-% end main
> (where ^[ is a literal escape character).  Then typing either
> Shift+Alt+$ or Shift+Alt+% in the middle of a line on a console will
> highlight/select the rest of the line.  Maybe you already have a
> patch applied to prevent the second case?

Ah, your patch highlights for both, my meta-shift patch fixes it for M-%. So 
something in my patch might make it possible to fix it for M-$ too.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]