Bug 476116 - [TERMINALS] in a fixed width font, not all fonts are 1 "extend" wide
Summary: [TERMINALS] in a fixed width font, not all fonts are 1 "extend" wide
Status: NEW
Alias: None
Product: CDT
Classification: Tools
Component: terminal (show other bugs)
Version: Next   Edit
Hardware: Macintosh Mac OS X
: P4 normal (vote)
Target Milestone: ---   Edit
Assignee: Project Inbox CLA
QA Contact: Jonah Graham CLA
URL:
Whiteboard:
Keywords: helpwanted
Depends on:
Blocks:
 
Reported: 2015-08-28 07:52 EDT by Davy Landman CLA
Modified: 2020-09-04 15:12 EDT (History)
2 users (show)

See Also:


Attachments
top: OSX Terminal, bottom: TM Terminal. (65.61 KB, image/png)
2015-08-28 07:52 EDT, Davy Landman CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Davy Landman CLA 2015-08-28 07:52:49 EDT
Created attachment 256213 [details]
top: OSX Terminal, bottom: TM Terminal.

I've been trying TM Terminal with some unicode characters and I have a range of observations. One of them is that around wider than expected characters the terminal misbehaves.

Monospaced fonts appear to have to make a choice when it comes to glyphs to wide to fit in the space chosen for the ASCII range. The few I've tried seem to take 2x the space. So it still aligns with the other chars around it.

if you type this in a normal terminal:

echo -e "指事hello\n1234hello"

you can see that the two CJK Unified Ideographs take up the same space as the 1234 string.

in TM Terminal the terminal tries to draw them on top of each other. (see attachment)
also, trying to go trough it with a cursor breaks and using backspace/delete gives quite unpredictable behavior.

It appears the character eats a part of the next character.

In the attachment, the top is the standard osx terminal, the bottom is a local shell in TM Terminal.

Things I've tried:
- switching to a normal font improves the rendering a bit, but around the CJK chars the cursor position still fails, as well as delete/backspacing
- other kinds of characters also fail: echo "←→↑↓" for example, or echo "α β γ δ ε ζ η θ ιω" 

Some tools helpful for debugging:
- "interesting" unicode characters: http://xahlee.info/comp/unicode_index.html
- get unicode information per character: https://r12a.github.io/uniview/#title

I've been reading the source a bit, and the first 128 chars are used to decide if a font is proportional or not. Perhaps if a char outside this range is observed, check the extend to perhaps give it 2 instead of 1 slot?
Comment 1 Martin Oberhuber CLA 2015-08-31 15:21:26 EDT
While the TM Terminal looks not quite correct here, I'm not sure if it's much better when there are 2 slots given to some characters.

Investing here is not a priority at the moment, though we would accept code contributions.
Comment 2 Jonah Graham CLA 2020-05-01 10:09:30 EDT
The Terminal component of the Eclipse Ecosystem has a new home. The Terminal is now part of the Eclipse CDT project[1].

This change means a new Git repo[2], P2 site[3] and Bugzilla component. The terminal will continue to be delivered as part of the quarterly Simultaneous Release of Eclipse as well.

The marketplace entry[4] had not been updated in a few years. It will once again install the latest release of the terminal on the latest release of the whole IDE (currently 2020-03).

If this bug is no longer relevant, please feel free to comment or close the bug. If you can confirm if this issues still occurs in the latest release please do let me know in a comment.

[1] https://wiki.eclipse.org/CDT/User/NewIn911
[2] https://git.eclipse.org/c/cdt/org.eclipse.cdt.git (in the terminal directory)
[3] current release is 9.11 - P2 site https://download.eclipse.org/tools/cdt/releases/9.11/
[4] https://marketplace.eclipse.org/content/tm-terminal

(This comment was added to all open terminal bugs along with changing the Product/component pair to CDT/terminal.)