We need cursor position fix to customize padding, line-height

[Alex Soroka]

As Google promotes chromebooks for app development, I think it's time to fix terminal cursor position. 

We can't add padding to the "body" nor x-row without breaking the cursor position(we can add padding and background color to the #terminal div but only manually in dev console and it's not persistent of course). Same for line-height(the only workaround is to use a font with increased height). It was a popular issue on the hyper terminal bug tracker when they used hterm. 

It even somehow fails to calculate the correct character size of a mono spaced font. See attachment, I'm using https://fonts.google.com/specimen/IBM+Plex+Mono?selection.family=IBM+Plex+Mono:400,500&selection.subset=cyrillic,cyrillic-ext BTW, in preview window of terminal settings, it calculates character size correctly(cursor in the correct position even at the end of row).

Is there any plans to fix that?

[Mike Frysinger]

Secure Shell doesn't support padding around the window.  if you inject with css, you're breaking hterm's algorithms.  any reports of bad cursor position at that point are not a bug in hterm.  we have crbug.com/267654 to add a proper setting for a border around hterm if you want to start it.

the first half cursor you circled in the screenshot that's in the upper left corner is a graphical glitch bug in Chrome.  it shows up on other sites too.  there's no known workaround.  Chrome/blink/whatever needs to be fixed instead.  there is an open bug in crbug.com somewhere for it, but i can't find it atm.

i'm sure the hyper guys had a number of hterm bugs/feature requests, but they never contacted us, so we had no idea what issues they were running into (or that they were even using hterm).  they effectively forked the project and never contributed back.

otherwise i don't really understand what you're reporting or requesting with line-height.  we lock the height down specifically so fonts with bad glyphs don't push text above or below the line, so there shouldn't be any problems with cursor tracking wrt vertical position (and i haven't heard of any such reports for a long time now).

i haven't looked at that specific font, but just because someone claims it's monospace doesn't mean it actually is.  we've received a number of reports where "monospace" fonts have glyphs that are wider or narrower than the space it's supposed to be restricted to.  we have a request to dynamically workaround such broken fonts, but in the meantime, it's easier to select a non-broken font.

-mike

--
You received this message because you are subscribed to the Google Groups "chromium-hterm" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-hterm/cf00b02b-a30b-4e07-9da1-6b369bdad6a0%40chromium.org.

[Alex Soroka]

I've solved the problem with character size by setting additional letter-space, like 

* {
letter-spacing: 0.0052em;
}

And I don't see any difference in cursor position depending on the character. So the font is really monospaced(each character has the same size), but hterm consider a character wider than it really is.

I and all that guys that reported the issue in hyper bug tracker have readability issue. Space between lines is too small. What I'm requesting is ability to set line-height in settings. We cannot just change css variable --hterm-charsize-height, because hterm determines how many lines are rendered in the terminal window based on some value in javascript code, which is I believe calculated based on font size. If we set custom bigger --hterm-charsize-height then lines at bottoms will not be visible, they don't fit into terminal window, because hterm determined earlier that current window fit for example 10 lines with certain line-height. I want manually correct that value in js code that determine --hterm-charsize-height and is used for determine how many lines fit into current window.