rendering issues

[trusktr]

The rendering seems is flickery and leaving various colors behind in some cells, especially while inside of NeoVim (alternate buffer). Is there some things to configure to make it render better? Or is it a known issue that needs work?

[trusktr]

example:

Notice the cursor itself is hard to tell where it is most of the time too.

[trusktr]

Another thing is that the cursor seems misaligned when stuff is rendered at the right side of the command prompt.

For example, here's what my terminal looks like in iTerm:

On the right side, the blue dots represent the status of git.

In DomTerm, the cursor seems to be misaligned and chops the command prompt, and the dot on the right side is not all the way flush to the right:

As you can see the cursor is on top of the ❯ mark.

If I'm not in a git repo, nothing is rendered on the right side, and DomTerm cursor is not misaligned in that case (compare both):

---

Another thing that happens is syntax highlight doesn't always update (same issue as with colors staying behind in NeoVim I suppose).

For example, in iTerm:

and in DomTerm:

[trusktr]

I love DomTerm though. It will be awesome when these issues are solved!

[trusktr]

Interestingly, just about every other terminal I've tried in Atom has the same issue of the cursor being in the wrong place, on top of the command line text.

[PerBothner]

Some of these could be font issues: I.e. not all of the characters have the same width.

It might be useful if you could try standalone domterm (i.e not atom-domterm): either using a browser (domterm --browser), or under electron (domterm --electron if electron is in PATH). That could help tell if the issue is specific to atom.

Also, if you send me the bash command(s) you use to show the prompt and git status, I can test those out on my system.

[albertz]

I have the same issue (or very similar) with any shell which uses colors in the prompt (e.g. my Fish or my ZSH). It displays it correctly, but in a fresh prompt, I can press the delete key and delete parts of the prompt. E.g. in the Fish, I can delete 2 chars, which I think is exactly the amount of escape codes which are used (one to turn green color on for the path, and a second to turn it off again).

[albertz]

Btw, I also tried GraphTerm (very similar project to DomTerm), and these render issues do not appear there (because of that, it's currently somewhat more usable for me now). But maybe it helps to look a bit at their code and compare what they do different.

[PerBothner]

It displays it correctly, but in a fresh prompt, I can press the delete key and delete parts of the prompt. E.g. in the Fish, I can delete 2 chars

I'm not seeing this. I do see a problem with the cursor (caret) sometimes disappearing when the input is empty. There is also a known problem with the predictive echo not dealing properly with fish's colorizing. (I'm working on a more flexible way to handle predictive echo, but it's not quite there yet.)

[lypanov]

I'm also seeing these issues with "lagging colors" with alot an email client. This makes knowing which email is currently selected impossible alas.

[lypanov]

I'm also seeing many different issues with powershell. Everything from missing colors during command entry, to seeming race conditions in execution itself (typing, pressing enter, result -> nothing, command not even in history).

[PerBothner]

I have little-to-no powershell experience. If you could tell me precise steps to reproduce the problems (included expected behaviour vs observed behavior) I can try to reproduce (and hopefully debug) it.

[lypanov]

Example reproducable rendering issue for Powershell / WSL / Electron: Start "pwsh". Hold paste down for the text blahblahblahblahblahblahblahblahblahblahblahblahblahblahblahblah. After a short while the text will begin to show with a different background color, press return straight away.

Expected behavior: the predictive echo text should remain, instead, it seemingly is gone. History is correct - the part after the background color change is actually executed, but, it's gone from the screen.

Ah, a clue: resizing the window seems to fix the rendering. The missing text reappears.

Frequently after performing this exercise a few times DomTerm gets in a really weird state, pressing return results in DomTerm scrolling up to the top of the scroll buffer. With the exception of scrolling nothing I do results in any visible reaction in the terminal. It's as if DomTerm lost connection.

My JS console has the following error in this situation:

Uncaught TypeError: Cannot read property 'offsetTop' of null
    at Terminal._adjustPauseLimit (terminal.js:7893)
    at Terminal.keyPressHandler (terminal.js:8072)
    at HTMLDivElement.<anonymous> (terminal.js:3215)

Another such stacktrace

Uncaught TypeError: Cannot read property '_widthColumns' of undefined
    at Terminal.deleteCharactersRight (terminal.js:4733)
    at Terminal.insertSimpleOutput (terminal.js:6935)
    at DTParser.insertString (domterm-parser.js:404)
    at Terminal.insertString (terminal.js:6062)
    at Terminal.insertBytes (terminal.js:6008)
    at Object.DomTerm._handleOutputData (terminal.js:8304)
    at WebSocket.wsocket.onmessage (terminal.js:8413)

In yet another case I get the above widthColumns message followed by

terminal.js:8410 WebSocket is already in CLOSING or CLOSED state.

This happens when pasting in a large block while Powershell starts, before it has had time to display it's prompt.

I've verified that none of this takes case when running powershell in another terminal.

In some extreme cases powershell stops rendering any colors when entering text on the next line. In this specific case when pressing return nothing is executed and nothing is in history. This is not easily reproducible yet alas.

[PerBothner]

I think you must be running an old version of domterm - those line numbers don't make sense.

(Also, pwsh isn't in the PATH - but powershell.exe works.)

[lypanov]

Ah your parenthesis explains why you might not be able to reproduce. I'm running the linux version of powershell - https://docs.microsoft.com/en-US/powershell/scripting/install/installing-powershell-core-on-linux?view=powershell-7 (I've been running it for so long honestly that I'd entirely forgotten it wasn't there by default sorry!)

Why the line numbers don't make sense I can't really explain. I didn't see much in your commit history that could fix such issues and by merging with master I've confirmed it, the bugs are present there also. Update: line numbers are a few off, due to your latest commits in terminal.js.

[PerBothner]

Just as a sanity check: echo $DOMTERM yields a string starting with version=2.1.0?

Also, the domterm status command prints out lots of useful information, I would expect it to start with:

DomTerm version 2.1.0 (git describe: 2.1-0-gbcf1408)
Copyright 2020 Per Bothner and others

[lypanov]

Yeah this all looks fine - just sent you a screenshot via private email. Could it be the Electron version? I'm running Electron 7.1.7 installed via the Windows installer.

[PerBothner]

I wondered if at least some of the problems (and the reason I wasn't seeing them) were timing-related, and was able to reproduce some of the symptoms by forcing a delay (by setting DomTerm._extraDelayForTesting to 600).

I found one bug (in Terminal.prototype._removeInputLine) and a tentative fix but there is at least one more bug that I'll look at in the morning.

[PerBothner]

Could you pull the latest version and see if things are improved?

[lypanov]

Still happening alas. In fact the latest changes have regressed the terminal in other ways alas (I'm no longer able to reliably use my email client).

The current stacktrace:

terminal.js:7034 Uncaught TypeError: Cannot read property 'insertBefore' of null
    at Terminal.insertNode (terminal.js:7034)
    at Terminal.insertRawOutput (terminal.js:6998)
    at Terminal.editorInsertString (terminal.js:9149)
    at Terminal.pasteText (terminal.js:7237)
    at HTMLDivElement.<anonymous> (terminal.js:3250)
    at Object.DomTerm.doPaste (terminal.js:7288)
    at commands.js:126
    at Object.DomTerm.handleKey (terminal.js:7847)
    at Terminal.keyDownHandler (terminal.js:7933)
    at HTMLDivElement.<anonymous> (terminal.js:3212)

The email client stacktrace (seen after page down then up on a multi page email):

terminal.js:4580 Uncaught TypeError: Cannot read property 'insertBefore' of null
    at Terminal._moveNodes (terminal.js:4580)
    at Terminal._forceWrap (terminal.js:4516)
    at Terminal.insertSimpleOutput (terminal.js:6944)
    at DTParser.insertString (domterm-parser.js:404)
    at Terminal.insertString (terminal.js:6018)
    at Terminal.insertBytes (terminal.js:5964)
    at Object.DomTerm._handleOutputData (terminal.js:8291)
    at WebSocket.wsocket.onmessage (terminal.js:8400)

To be 100% certain the patch was the cause I locally reverted a2057efadd62c3a6c8d89359079911c61795dee2 and retested, alot works fine without it. But breaks with it.

[PerBothner]

I tweaked the change in Terminal.prototype._removeInputLine. That should fix the worst problems.

Not quite sure I understand what is going on; will ponder more tomorrow.

[PerBothner]

Let me know how things work now.

[lypanov]

This has fixed the regression of alot in DomTerm. The issues with powershell also remain resolved.

Alas still seeing issues with background colors in alot (the selection leaves trails). Still seeing random alignment issues with text in the window frame (first half of the top line of alot is outside the frame).

[PerBothner]

Can you give me detailed instructions on how to reproduce the remaining rendering issues? Which platform (OS/desktop) are you using? I'm mostly using Fedora 31, but I can also boot into Windows/WSL for testing.

[lypanov]

Using Electron/WSL. To reproduce the selection trails in alot I open my message list and move down in the list past the 4th item. The first few items work, but after that the background color drags behind leaving me unsure which item is currently selected.

The alignment issue alas is more difficult to reproduce. I see this on opening messages for example in alot, but, not every time. And in powershell I can't recall having seen it. Once having "broken" the alignment it doesn't repair itself, it looks like the top few pixels are missing (so the very top pixel of a t for example), but honestly I don't really get how it could have ever fit, the line heights seem equal for all lines and the bottom lines cursor is touching the bottom of the frame!

I should add that I'm using a weird font: TT2020 Style E: https://ctrlcctrlv.github.io/TT2020/

[PerBothner]

I'm tempted to blame Electron (or the underlying Chromium) and/or the font. Especially if things work fine on Firefox (or a regular Chrone browser) and/or using a standard font.

Which version of Electron are you using? Maybe try a newer (or possibly an older) version of Electron, in case it a bug that has been fixed (or newly introduced).

I can't think of anything DomTerm does that would chop off the top few pixels of a character. Possibly relevant: If you set up shell integration, it adds a border and a compensating negative-width margin at the top of a command group. Also wide characters (such as Emoji) have their width and height adjusted. Otherwise, layout and rendering is handled by the browser (controlled by CSS of course).

You might find it instructive to Toggle Developer Tools (in View menu or type Ctr-Shift-I) and select Elements. Each line (or group of lines) is a <div class="domterm-pre">. You can play with the Styles, enabling or disabling style elements (including fonts) to see if it makes a difference.

Unlike some other browser-based terminals, DomTerm does not render the selection itself, using the browser's standard selection. It may use the JS Selection API to change which characters are selected. So if you see rendering errors in the selection (such as fractional characters selected) that is a browser/Electron/font bug. If the wrong characters are selected, that could well be a DomTerm bug.

An experiment to consider is adding this to your settings.ini:

 style.caret = blinking-bar

This uses a different mechanism to display the caret (text cursor) - which may work better or worse than the default blinking-block, depending on the browser. (Both work fine for me.)