bugGNU nano - Bugs: bug #64632, handling of the F13 symbol...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #64632: handling of the F13 symbol disappeared in 5.0

Submitter:  Danny Milosavljevic <dannym>
Submitted:  Fri 08 Sep 2023 03:43:39 PM UTC
   
 
Severity:  2 - Minor Status:  Fixed
Assigned to:  bens Open/Closed:  Open

Jump to the original submission

Mon 18 Dec 2023 11:48:01 AM UTC, comment #13: 

Fixed in git, commit 41b52d70, by recognzing the escape sequences for the real F13...F16 symbols again, mapping them to what nano calls F13...F16.

Benno Schulenberg <bens>
Group administrator
Mon 11 Dec 2023 03:54:38 PM UTC, comment #12: 

Correction: setting `key <CAPS> {[ F2, F1 ]}` and then pressing Shift+Caps, ncurses passes the symbol F13 to nano, because ncurses sees Shift+F1.

Benno Schulenberg <bens>
Group administrator
Mon 11 Dec 2023 03:35:15 PM UTC, comment #11: 

Nano was never able to distinguish between Shift+F1 and F13, so not being able to do that now is not a problem.  Also, I do not know of any keyboard that has an actual F13 key, so Shift+F13 should not occur -- and nano would not be able to handle it anyway, because Shift+F13 would translate to F25, and nano handles only up to F24.

Xkb does not allow mapping a key to two "things".  One could define key <CAPS> as {[ F2, F1 ]};, so that pressing Shift+Caps would produce the symbol F1 plus the Shift modifier.  But ncurses does not pass on the Shift modifier, and nano would just get the symbol F1.

Benno Schulenberg <bens>
Group administrator
Mon 11 Dec 2023 01:21:05 PM UTC, comment #10: 


> Before version 5.0, nano mapped these codes to kf13 and higher, corresponding to Shift+F1 and higher.


If you revert this, then as far as I understand you won't be able to distinguish Shift+F1 from F13, and also won't be able to handle Shift+F13.

Instead, I believe the proper solution would be to handle F13 as a first class citizen.

Alternatively, check if xkb allows to map <CAPS> to Shift+F1, i.e. pretend that the Shift key has also been pressed. I don't know. This still wouldn't allow to distinguish them, but Danny can do this then without any hacks from nano.

I would be curious how other terminal-based apps behave here, if there's any other that can be configured to handle this sequence. I've tried a few terminal emulators that set TERM=xterm-256color, some emitted ^[[25~ and some emitted nothing when pressing the given key. I haven't checked other terminal-based apps, but I wouldn't be surprised if many of them didn't allow to configure this key.

I don't know, but I find it pretty likely that OP's hack is limited to a few terminal emulators and few terminal-based applications to begin with, rather than being something generally supported. IMHO rejecting OP's truly special "spacebar heating" feature request, in the name of cleaner simpler codebase, isn't unfair either. Benno, your project, your call.

> By the way, a "simpler", one-line command


IMHO this is not simpler, just more automated than mine :) OP wrote

> I load the following custom keymap using xkbcomp


followed by a four line snippet; I was searching for an xkbcomp command line that merges this tiny file into the existing layout. Anyway, doesn't matter.

Egmont Koblinger <egmont>
Mon 11 Dec 2023 12:29:28 PM UTC, comment #9: 

Owww.  You're right: xterm produces the same codes as VTE for F13 to F35.  It never occurred to me to check that.  :/  I was convinced that kf13 and beyond in the `infocmp` ouput stood for F13 and beyond.  But that was a mistake, as some googling and finding https://invisible-island.net/xterm/terminfo-contents.html made clear.  Search for "Shift-Fx" (without the quotes) and find:

# Function keys with modifiers (Sun/PC):
# -------------------------------------
#       Shift-Fx          - kf{12+x}
#       Control-Fx        - kf{24+x}
#       Shift-Control-Fx  - kf{36+x}

So... kf13 does not mean F13 -- it means Shift+F1!  And so on for the other function keys beyond F12.  Ouch.  :/

So, when in a nanorc I do, say, `bind F13 "something" main`, I don't bind F13, I actually bind Shift+F1.

But the "^[[25~" sequence is the code for the actual F13 key (and the higher codes for the subsequent higher real function keys).  Before version 5.0, nano mapped these codes to kf13 and higher, corresponding to Shift+F1 and higher.  So I guess I will have to restore that fragment from commit 9a6158cd.

Thank you, Egmont, for investigating!

By the way, a "simpler", one-line command to set the CAPS key to something else could be:

xkbcomp :0 - | sed 's/key <CAPS>.*/key <CAPS> {[ F13 ]};/' | xkbcomp -w0 - :0


Benno Schulenberg <bens>
Group administrator
Sun 10 Dec 2023 08:35:44 PM UTC, comment #8: 

Hi guys,

VTE developer here.

I managed to reproduce the issue. I ran `xkbcomp -xkb :0 xkbmap` to dump the current mapping to the file `xkbmap`, edited the line containing `key <CAPS>`, then loaded this layout using `xkbcomp -w 0 xkbmap :0`. Please let me know if there's a more straightforward way.

I can confirm that for F13 .. F35 VTE indeed produces escape sequences ^[[25~ .. ^[[56~ (a few numbers skipped in between), but...

...but so does xterm.

Tried with xterm as shipped by Ubuntu 23.10, and also with a manually compiled xterm-388, purging the distro package (and thereby removing /etc/X11/app-defaults/XTerm and friends) and moving away my ~/XTerm; also nothing relevant in `xrdb -query`.

So it looks like VTE indeed copies xterm's behavior here. What is xterm's behavior for you?

xterm and terminfo are maintained by the same person, maybe you could ask him about this discrepancy.

If xterm modifies its behavior then we'll most likely follow; in that case please open an issue at https://gitlab.gnome.org/GNOME/vte/-/issues.

(Nitpicking: VTE piggybacks TERM=xterm-256color, not TERM=xterm. It seems to be irrelevant for the function keys, though.)

Egmont Koblinger <egmont>
Sun 10 Dec 2023 12:02:10 PM UTC, comment #7: 

To summarize: the escape sequences that VTE-based terminals produce for F13 to F35 are the sequences that belong to a Linux console, not to an Xterm.  This is incorrect, as VTE-based terminals try to imitate an Xterm as closely as possible, not a Linux console.  I will send the attached patch upstream.

(file #55432)

Benno Schulenberg <bens>
Group administrator
Thu 14 Sep 2023 02:20:28 PM UTC, comment #6: 

The "^[[25~" comes from libvte.  I've edited /usr/lib/x86_64-linux-gnu/libvte-2.91.so.0.6800.0 (with nano --ignore --noconvert --nonewlines --nohelp) and replaced the occurrence of "25~" with "44~" and rebooted.  When I then run `setxkbmap nl` (where the nl map contains `replace key <CAPS> {[ F13 ]};`, then typing ^V followed by CapsLock produces a "^[[44~" sequence instead of "^[[25".

Well... I think the sequences for F13 and higher in src/keymap.cc in vte-0.72.2 are not a good choice.  VTE-based terminals are not trying to imitate a Linux console, but an xterm.  So it would be better when the sequences produced for function keys mimicced the ones produced by xterm, no?

[Maybe post this issue upstream?  I won't, as Xfce's Gitlab requires solving captchas, which I refuse to do.]

Benno Schulenberg <bens>
Group administrator
Mon 11 Sep 2023 07:50:27 PM UTC, comment #5: 

(Aha, for what it's worth, Shift-F1 on the (no configuration changed) Linux text console is

   ^[[25~

)

Danny Milosavljevic <dannym>
Mon 11 Sep 2023 07:31:33 PM UTC, comment #4: 


>When on an xterm I press Ctlr+V and the actual F13 key (that is: Shift+F1)


F13 is Shift-F1 ? My intention was to map it to a keysym that's not in use otherwise. (Maybe I should map it to XF86Search or something--makes more sense anyway)

>, the produced sequence is: "^[[1;2P" (without the quotes).  When I run:
>infocmp xterm | grep -o kf13[^,]*

the result is:

>kf13=\E[1;2P


I get the same result.

>So the xterm sequence for F13 is not "^[[25~".  Why xkbcomp seems to think so, I don't know.  Maybe TERM needs to be set to "xterm" when you invoke xkbcomp?


I tried setting TERM to xterm and then invoking xkbcomp, but it didn't change things.

When I press Shift-F1, I get

  ^[[1;2P

but when I press Caps Lock, I get

  ^[[25~

Danny Milosavljevic <dannym>
Mon 11 Sep 2023 05:36:05 PM UTC, comment #3: 

When on an xterm I press Ctlr+V and the actual F13 key (that is: Shift+F1), the produced sequence is: "^[[1;2P" (without the quotes).  When I run:

infocmp xterm | grep -o kf13[^,]*

the result is:

kf13=\E[1;2P

So the xterm sequence for F13 is not "^[[25~".  Why xkbcomp seems to think so, I don't know.  Maybe TERM needs to be set to "xterm" when you invoke xkbcomp?

Benno Schulenberg <bens>
Group administrator
Mon 11 Sep 2023 02:14:39 PM UTC, comment #2: 


> How do you map CapsLock to F13?  Do you mean that you make the CapsLock key emit the escape sequence for F13?


Yes. I load the following custom keymap using xkbcomp (invoked every time I log in) in xorg:

  default partial hidden modifier_keys
  xkb_symbols "basic" {
    replace key <CAPS> {        [       F13             ]       };
  };

When I then enter xterm in bash and press Ctrl-v and then press the physical Caps Lock key on the keyboard, I get:

  ^[[25~

I also set up inputrc to

  "\e[25~": reverse-search-history

and that works great--so if I don't press Ctrl-v and just press the physical Caps Lock key on the keybard, it will search the history for whatever I type. This works fine and always has worked fine.

>  On what terminal are you doing that?


In xterm

>  And what is TERM set to?


"xterm" without the quotes.

>  Because if TERM is set correctly for the terminal, ncurses should recognize the escape sequence for any function key, and in this case should return KEY_F(13) to nano instead of the raw escape sequence.


> Or are you using --rawsequences?


I just tried it. I'm not passing any command line arguments to nano and Caps Lock still doesn't work (without the patch). Not sure whether rawsequences would already be enabled by another way. How do I check that?

Danny Milosavljevic <dannym>
Sat 09 Sep 2023 07:12:00 AM UTC, comment #1: 

How do you map CapsLock to F13?  Do you mean that you make the CapsLock key emit the escape sequence for F13?  On what terminal are you doing that?  And what is TERM set to?  Because if TERM is set correctly for the terminal, ncurses should recognize the escape sequence for any function key, and in this case should return KEY_F(13) to nano instead of the raw escape sequence.  Or are you using --rawsequences?

Benno Schulenberg <bens>
Group administrator
Fri 08 Sep 2023 03:43:39 PM UTC, original submission:  

Hi,

So I've been mapping caps lock to F13 (and that in nano to "whereis") for a long while now...

A nano update eventually broke F13 in general, and any higher function keys.

Trying not to invoke https://xkcd.com/1172/ :) , would it be possible to readd higher function keys?

I wrote a local patch like the following and it works:

diff -ru orig/nano-7.2/src/winio.c nano-7.2/src/winio.c
--- orig/nano-7.2/src/winio.c   2023-01-18 09:19:15.000000000 +0100
+++ nano-7.2/src/winio.c        2023-05-05 22:25:20.038728106 +0200
@@ -698,6 +698,8 @@
                                                return KEY_F(11);
                                        case '4': /* Esc [ 2 4 ~ == F12 on the same. */
                                                return KEY_F(12);
+                                       case '5': /* Esc [ 2 5 ~ == F13 on the same. */
+                                               return KEY_F(13);
                                }
                        } else if (length > 1 && seq[1] == '~')
                                /* Esc [ 2 ~ == Insert on VT220/VT320/

Danny Milosavljevic <dannym>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by egmont (Posted a comment)
  • -email is unavailable- added by bens (Posted a comment)
  • -email is unavailable- added by dannym (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    Follow 7 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2023-12-18 bens StatusNone Fixed
    2023-12-11 bens SummaryF13 key handling disappeared a while back handling of the F13 symbol disappeared in 5.0
    2023-12-11 bens StatusInvalid None
        Assigned toNone bens
    2023-12-10 bens Severity3 - Normal 2 - Minor
        StatusNone Invalid
    2023-12-10 bens Attached File- Added 0001-keymap-use-escape-sequences-from-xterm-instead-of-fr.patch, #55432

    Back to the top

    Powered by Savane 3.12.
    Corresponding source code