key stoke sends different escape sequences in version 1.7.1 #425

Closed
opened 7 months ago by tyang · 12 comments
tyang commented 7 months ago

I'm not sure if this is really an issue.

I started command line too cat, then stroke Ctrl+Shift+, and Ctrl+Shift+. , differents when running verseion 1.7.1 & 1.6.4 can be observed in the following screenshot:

(upper one is 1.7.1, lower one is 1.6.4).

I'm not sure if this is really an issue. I started command line too `cat`, then stroke `Ctrl+Shift+,` and `Ctrl+Shift+.` , differents when running verseion 1.7.1 & 1.6.4 can be observed in the following screenshot: (upper one is 1.7.1, lower one is 1.6.4).
Collaborator

It's the difference between e.g. Ctrl+Shift+. and Ctrl+>, as mentioned in #376 and #380.

It's the difference between e.g. <kbd>Ctrl</kbd>+<kbd>Shift</kbd>+<kbd>.</kbd> and <kbd>Ctrl</kbd>+<kbd>></kbd>, as mentioned in #376 and #380.
Owner

As hinted by @craigbarnes, this is an intentional change: #378.

As hinted by @craigbarnes, this is an intentional change: https://codeberg.org/dnkl/foot/pulls/378.
Poster

thank you guys.

I use emacs and bind Ctrl+> to go to end-of-buffer, something like:

 (yc/set-keys                                                                                                               
 (list                                                                                                                     
  (cons (kbd "C-,") 'backward-page)                                            
  (cons (kbd "C-.") 'forward-page)  
  (cons (kbd "C->") 'end-of-buffer) 
  (cons (kbd "C-<") 'beginning-of-buffer)                                               )                                 
                                                                                     

This used to work in version 1.6.4, but not work in 1.7.1.

Is there a solution or a workaround?

Thanks.

thank you guys. I use emacs and bind `Ctrl+>` to go to end-of-buffer, something like: ``` (yc/set-keys (list (cons (kbd "C-,") 'backward-page) (cons (kbd "C-.") 'forward-page) (cons (kbd "C->") 'end-of-buffer) (cons (kbd "C-<") 'beginning-of-buffer) ) ``` This used to work in version 1.6.4, but not work in 1.7.1. Is there a solution or a workaround? Thanks.
Owner

Hmm, looks like emacs is using hardcoded "escape sequence" -> key maps, instead of just decoding the sequence.

It should be possible to add the "new" sequences to its decode map. Let me look into how to do that; it's something I want for myself anyway.

But perhaps we should reconsider the decision to exclude consumed modifiers. It is obviously causing compatibility issues. @craigbarnes thoughts?

Hmm, looks like emacs is using hardcoded "escape sequence" -> key maps, instead of just decoding the sequence. It should be possible to add the "new" sequences to its decode map. Let me look into how to do that; it's something I want for myself anyway. But perhaps we should reconsider the decision to exclude consumed modifiers. It is obviously causing compatibility issues. @craigbarnes thoughts?
Poster

I added following lines to my emacs configuration, and the keybings works now:

  (cons (kbd "M-[ 2 7 ; 5 ; 6 0~") 'beginning-of-buffer)    
  (cons (kbd "M-[ 2 7 ; 5 ; 6 2~") 'end-of-buffer)  

But still, it would be best if there's no compatibility issues :)

Thanks again.

I added following lines to my emacs configuration, and the keybings works now: ``` (cons (kbd "M-[ 2 7 ; 5 ; 6 0~") 'beginning-of-buffer) (cons (kbd "M-[ 2 7 ; 5 ; 6 2~") 'end-of-buffer) ``` But still, it would be best if there's no compatibility issues :) Thanks again.
Poster

sigh, just reallized that more strokes were broken in my emacs, for example Ctrl+F 1~12, Alt+F1~12 ...

sigh, just reallized that more strokes were broken in my emacs, for example `Ctrl+F 1~12`, `Alt+F1~12` ...
Owner

Hmm, that's a different issue I think. A regression perhaps, but still a different issue.

Hmm, that's a different issue I think. A regression perhaps, but still a different issue.
Owner

The issue is related, but slightly different. For some reason, XKB is telling us that ctrl is a consumed modifier when F1..F12 is pressed.

This causes foot to remove the ctrl modifier from the sequence.

I have to say that I'm leaning towards reverting this.

The issue is related, but slightly different. For some reason, XKB is telling us that <kbd>ctrl</kbd> is a consumed modifier when <kbd>F1</kbd>..<kbd>F12</kbd> is pressed. This causes foot to remove the `ctrl` modifier from the sequence. I have to say that I'm leaning towards reverting this.
Collaborator

@dnkl This is what I was alluding to in #378, although I couldn't really think of any specific examples at the time. The legacy of xterm's mistakes in this regard seems too ingrained to fix, without inadvertently breaking things.

I think something like #319 is the only long-term solution to these kinds of problems. I'm actually starting to like the fact that the new kitty key encoding scheme is relatively hard to parse. If it sees widespread adoption, hopefully it'll also motivate client apps to stop pattern matching escape sequences and use a proper parser instead.

@dnkl This is what I was [alluding to](https://codeberg.org/dnkl/foot/pulls/378#issuecomment-179916) in #378, although I couldn't really think of any specific examples at the time. The legacy of xterm's mistakes in this regard seems too ingrained to fix, without inadvertently breaking things. I think something like #319 is the only long-term solution to these kinds of problems. I'm actually starting to like the fact that the new kitty key encoding scheme is relatively hard to parse. If it sees widespread adoption, hopefully it'll also motivate client apps to stop pattern matching escape sequences and use a proper parser instead.
Poster

@dnkl This is what I was alluding to in #378, although I couldn't really think of any specific examples at the time. The legacy of xterm's mistakes in this regard seems too ingrained to fix, without inadvertently breaking things.

I think something like #319 is the only long-term solution to these kinds of problems. I'm actually starting to like the fact that the new kitty key encoding scheme is relatively hard to parse. If it sees widespread adoption, hopefully it'll also motivate client apps to stop pattern matching escape sequences and use a proper parser instead.

Thank you @craigbarnes, I aggree there may be some ledacy mistakes, but I it would be great if there is an option to turn this feature on/off.

> @dnkl This is what I was [alluding to](https://codeberg.org/dnkl/foot/pulls/378#issuecomment-179916) in #378, although I couldn't really think of any specific examples at the time. The legacy of xterm's mistakes in this regard seems too ingrained to fix, without inadvertently breaking things. > > I think something like #319 is the only long-term solution to these kinds of problems. I'm actually starting to like the fact that the new kitty key encoding scheme is relatively hard to parse. If it sees widespread adoption, hopefully it'll also motivate client apps to stop pattern matching escape sequences and use a proper parser instead. Thank you @craigbarnes, I aggree there may be some ledacy mistakes, but I it would be great if there is an option to turn this feature on/off.
Collaborator

@tyang It's looking like #378 will probably be reverted (see #426), which should fix the problems you're seeing in emacs.

https://freenode.logbot.info/foot-terminal/20210329

@tyang It's looking like #378 will probably be reverted (see #426), which should fix the problems you're seeing in emacs. https://freenode.logbot.info/foot-terminal/20210329
Poster

yeah, i see.

yeah, i see.
dnkl closed this issue 7 months ago
dnkl added the
bug
label 7 months ago
Sign in to join this conversation.
No Milestone
No Assignees
3 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.