Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use more C0 constants in Keyboard #2425

Merged
merged 1 commit into from
Sep 26, 2019
Merged

Conversation

Tyriar
Copy link
Member

@Tyriar Tyriar commented Sep 12, 2019

No description provided.

@Tyriar Tyriar requested a review from jerch September 12, 2019 18:14
@Tyriar Tyriar self-assigned this Sep 12, 2019
} else if (ev.keyCode === 221) {
// ^] - Operating System Command (OSC)
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jerch this comment seemed to be lying?

Copy link
Member

@jerch jerch Sep 12, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I cannot tell where this comes from. Time to look into old VT docs / xterm sources. Again GS looks fairly wrong here.

Edit: Correction - input of GS as control char. The comment is wrong. (OSC is ^[] in this notation.)

} else if (ev.keyCode === 220) {
// ^\ - String Terminator (ST)
result.key = String.fromCharCode(28);
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jerch this comment seemed to be lying?

Copy link
Member

@jerch jerch Sep 12, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure if does the right thing at all, FS has no special meaning in VT land (treated as LF). I have to look up the DEC docs for this...

Edit: Correction - thats the input of FS as control char itself, so its correct. The comment is wrong. (ST is actually ^[\).

} else if (ev.keyCode === 219) {
// ^[ - Control Sequence Introducer (CSI)
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jerch while ^[ was right here, that's not CSI?

Copy link
Member

@jerch jerch Sep 12, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well ^[ is a typical way to express ESC [ in some editors (and bash), thus it means CSI. But the code does something else?

Edit: Woops I mixed this with the control codes - so ^[ means ESC itself.

Copy link
Member

@jerch jerch left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can only comment on this atm. There are several things we should clarify before proceeding:

  • we should have a clear understanding of key to sequence mapping (prolly take it from xterm source / DEC docs)
  • we should make sure to respect terminal modes correctly (like application mode which changes some key reports)

This code looks very awkward to me, full of magic numbers and unclear range tests. Guess this has grown by trial and error? Also those longish condition checks look error prone to me.

@@ -316,23 +316,18 @@ export function evaluateKeyboardEvent(
if (ev.keyCode >= 65 && ev.keyCode <= 90) {
result.key = String.fromCharCode(ev.keyCode - 64);
} else if (ev.keyCode === 32) {
// NUL
result.key = String.fromCharCode(0);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

WTH (who wrote this in the first place?)

} else if (ev.keyCode === 219) {
// ^[ - Control Sequence Introducer (CSI)
Copy link
Member

@jerch jerch Sep 12, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well ^[ is a typical way to express ESC [ in some editors (and bash), thus it means CSI. But the code does something else?

Edit: Woops I mixed this with the control codes - so ^[ means ESC itself.

} else if (ev.keyCode === 220) {
// ^\ - String Terminator (ST)
result.key = String.fromCharCode(28);
Copy link
Member

@jerch jerch Sep 12, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure if does the right thing at all, FS has no special meaning in VT land (treated as LF). I have to look up the DEC docs for this...

Edit: Correction - thats the input of FS as control char itself, so its correct. The comment is wrong. (ST is actually ^[\).

} else if (ev.keyCode === 221) {
// ^] - Operating System Command (OSC)
Copy link
Member

@jerch jerch Sep 12, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I cannot tell where this comes from. Time to look into old VT docs / xterm sources. Again GS looks fairly wrong here.

Edit: Correction - input of GS as control char. The comment is wrong. (OSC is ^[] in this notation.)

@jerch
Copy link
Member

jerch commented Sep 12, 2019

@Tyriar Yeah most certainly those FS, GS mappings are wrong. They are mentioned in xterm docs for Tektronix mode, but we dont support this at all. Tested it in xterm - the comments were right there and we should actually return what was commented there. But we have the next problem here - this will not work with different keyboard layouts, they are likely to report different numbers (quickly tested with German vs English keyboard). This might be the source of some of the keyboard issues we have seen so far. Guess this needs a very fundamental refactoring...

Edit: See corrections above.

@jerch
Copy link
Member

jerch commented Sep 12, 2019

@Tyriar Because you wondered where Ctrl+Space == '\x00' comes from: https://archive.org/details/bitsavers_decstandar0VideoSystemsReferenceManualDec91_74264381/page/n561

@Tyriar
Copy link
Member Author

Tyriar commented Sep 12, 2019

Not sure who made those comments, maybe it was me? 🤷‍♂

But anyway, term.js seems to have correct comments so I think these changes are good: https://github.com/chjj/term.js/blob/548af6e0a15c5978a2b62a882f7db03ec2ae2850/src/term.js#L2789-L2804

@Tyriar
Copy link
Member Author

Tyriar commented Sep 12, 2019

This code looks very awkward to me, full of magic numbers and unclear range tests. Guess this has grown by trial and error? Also those longish condition checks look error prone to me.

It's barely changed since xterm.js was forked, mainly just moving from the main file and converting to TS.

Copy link
Member Author

@Tyriar Tyriar left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Moving forward on this as the code seemed to be right and the comments wrong.

@Tyriar Tyriar added this to the 4.1.0 milestone Sep 26, 2019
@Tyriar Tyriar merged commit 22b06ca into xtermjs:master Sep 26, 2019
@Tyriar Tyriar deleted the constant_key_board branch September 26, 2019 00:06
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants