zsh / oh-my-zsh - no scroll

[normalser]

If i start demo with zsh instead of bash and have oh-my-zsh installed then the scroll will not work in xterm.js

I am not sure if this is an issue with xterm.js or oh-my-zsh

The command that causes scroll to stop working is this command: echoti smkx that is located in .oh-my-zsh/lib/key-bindings.zsh

One can also start xterm.js without oh-my-zsh and type that command into terminal and it will stop scrolling.

[parisk]

Thanks for reporting @wallverb. I do not have access to zsh right now, so I am not able to test this out.

Could you please take a look at your console in the developer tools of your browser and provide us with any errors/logs that might appear when attempting to scroll when in zsh with oh-my-zsh?

[normalser]

@parisk - when zsh/oh-my-zsh is executing that echoti smkx command then the following data is being sent to Terminal.prototype.write = function(data):

�[?1l�>
xterm.js:1467 


xterm.js:1467 �]2;echoti smkx�
xterm.js:1467 �]1;echoti��[?1h�=�[1m�[7m%�[m�[1m�[m    

which seems like that = char is causing this:

 // ESC = Application Keypad (DECPAM).
              case '=':
                this.log('Serial port requested application keypad.');
                this.applicationKeypad = true;
                this.state = normal;
                break;

and then this.applicationKeypad = true; is causing return in scroll code:

      on(el, wheelEvent, function(ev) {
        if (self.mouseEvents) return;
        if (self.applicationKeypad) return;

[richarddavenport]

@parisk, any movement on fixing this? Really appreciate the work!

[parisk]

@richarddavenport unfortunately I didn't have time to deal with this and I do not project to be able to do so by the end of the month.

It would be extremely helpful if we could get an external contribution on this and I can definitely help anyone out with figuring out the internals of xterm.js.

[richarddavenport]

@parisk I'd love to help! Is there any documentation anywhere, or could you help me get going with debugging? Is there an editor or IDE that works best? VS Code/Webstorm/Chrome Dev Tools? Thanks!

[Tyriar]

@richarddavenport any editor works well. All the code is in ./src/xterm.js and instructions to run the demo are here.

[parisk]

@richarddavenport I think @Tyriar is right. Any editor supporting JavaScript works, so feel free to choose the one that suits you better.

Personal opinion though would be choosing an editor or IDE that uses xterm.js itself though, in order to dogfood it as well (use xterm.js when developing xterm.js). The two solutions that I am aware of right now are:

• SourceLair that works completely in the browser; just visit https://lair.io/sourcelair/xterm and follow the instructions
• Visual Studio Code, just download it, clone the repo, run npm install and you are all set

Debugging with Chrome/Firefox DevTools is the best way to go IMO.

Considering the documentation, there is no public website at the moment but you should expect it within the week. Till that time just run npm run build:docs in your terminal and then you will be able to browse the API reference in HTML format, inside the docs directory.

Feel free to ask for more help in case the above do not suffice.

[parisk]

@richarddavenport I published a preview version of the docs website, which contains the API reference. Most public methods are documented.

You can take a look at http://docs.xtermjs.org/. Hope it helps 😊 .

[richarddavenport]

Wow! That's pretty awesome! @wallverb is right about the echoti smkx command in oh my zsh. That command is putting the terminal in Application Mode, which (I'm guessing here) is related to the applicationKeypad property. Does that sound right? I have no idea what application mode is, but it sounds important. Line 1144, if commented out, everything works, but I'm unsure of the consequences or what that line is there for. Do you know what that is for?

[Tyriar]

Yes I'm a bit hesitant to touch it as I don't know what it does either.

This reference doc we use mentioned it here:

The application keypad transmits the following escape sequences depend-
ing on the mode specified via the DECKPNM and DECKPAM escape sequences.
Use the NumLock key to override the application mode.

The code also mentions:

              // ESC = Application Keypad (DECPAM).
              case '=':
                this.log('Serial port requested application keypad.');
                this.applicationKeypad = true;
                this.state = normal;
                break;

              // ESC > Normal Keypad (DECPNM).
              case '>':
                this.log('Switching back to normal keypad.');
                this.applicationKeypad = false;
                this.state = normal;
                break;

Looking into what DECPAM and DECPNM will likely lead us to an answer. Also if there's a difference with DECKPAM and DECKPNM.

[richarddavenport]

Xterm.js scrolling with oh my zsh now works, with this branch

[apjanke]

Hi. Found this thread from the related bug on Oh My Zsh.

Looking into what DECPAM and DECPNM will likely lead us to an answer. Also if there's a difference with DECKPAM and DECKPNM.

I think DECPAM and DECPNM are just typos for DECKPAM and DECKPNM. The mnemonics are "DEC KeyPad Application Mode" and "DEC KeyPad Normal Mode".

Application keypad modes change what character sequences the cursor keypad and/or numeric keypad keys send in response to key presses. There are two (or more) distinct keypad modes which can be set to either "application" or "normal": the numeric keypad and the cursor keypad. The applicationKeypad and applicationCursor properties modify the sequences sent by some keys, which seems appropriate.

It seems to me there may be a bug with the Home and End keys, though. Their behavior is modified by the applicationKeypad property. But xterm considers Home and End to be cursor keys, controlled by DECCKM instead of DECKPAM/DECKPNM. (See the "PC-Style Function Keys" section in that xterm reference document.) I think that means they should be controlled by applicationCursor instead of applicationKeypad.

Regardless, it's surprising to me that the keypad mode would affect mouse scroll wheel behavior. (That's the scrolling that OP is talking, about, right?) Maybe the fix is as simple as removing that if (self.applicationKeypad) return; check from the mouse scroll wheel handler.

I do not have access to zsh right now, so I am not able to test this out.

You can test this behavior under bash or other shells by doing tput smkx. That's equivalent to zsh's echoti. But be aware that under most terminfo definitions, smkx sends the sequences for both application cursor keypad and application numeric keypad modes, so you're not testing them independently if you do it that way. To test them independently (e.g. if you wanted to check which mode was controlling the Home/End behavior), you'd need to echo those escape sequences separately. (I don't remember how to do so off the top of my head.)