bug#44664: 28.0.50; troubles with some chars in term

[Jean Louis <bugs@gnu.support>]

[-- Attachment #1: Type: text/plain, Size: 3856 bytes --]

* Eli Zaretskii <eliz@gnu.org> [2020-11-18 21:14]:
> > Date: Wed, 18 Nov 2020 18:37:13 +0300
> > From: Jean Louis <bugs@gnu.support>
> > Cc: Lars Ingebrigtsen <larsi@gnus.org>, schwab@linux-m68k.org,
> >   44664@debbugs.gnu.org
> > 
> > > So yes, in that original screenshot some characters are wider than 1
> > > column.  But shouldn't the Lisp program which produces this display
> > > take the character widths into account?
> > > 
> > > Failing that, I don't see how this could be fixed, because  no single
> > > font could support too many scripts, and if the user reads email in
> > > many different languages, they will eventually bump into some script
> > > which needs a different font.
> > 
> > I was thinking you would know how terminals are solving that problem
> 
> I don't even know everything about Emacs solutions to various problems
> we have to solve, how do you expect me to know what terminal emulators
> do, when that's not the code I'm familiar with?

Sorry I meant several people, not only one, English has "you" both for
singular and plural. 

> If someone wants to investigate how the terminal emulators solve this
> and describe that here, that would be welcome, and might give us some
> new ideas.

I have been searching to find references:

https://github.com/jquast/wcwidth

https://github.com/streamlink/streamlink/pull/2032

But I can also see many problems without any wide characters. 

I am also observing various switches of fonts. I have tried setting
Terminus font and then I see that when I run mutt that the font
changes to something else. After $ reset, it seem to have half
Terminus and prompts to be DejaVu Sans, then after several killing of
terminal buffer and restarts it started appearing everything to be
using Terminus font.

Hide Term face: [sample]
    State : SET for current session only.
   Default face to use in Term mode.
   [X] Font Family: Terminus
   [X] Height: Value Menu Scale: 1.5
   [X] Foreground: white smoke  Choose   (sample)
   [X] Background: black       Choose   (sample)
   Show All Attributes

Then I removed .bashrc and by using $ reset several times it seems to
help or to stabilize itself to use Terminus only.

> > My font in XTerm is same as in Emacs, DejaVu Sans Mono.
> 
> That doesn't seem to be the case, since the character glyphs in Emacs
> and in xterm look different.  But maybe I'm missing something.

It was generally same, maybe sometimes I have changed it.

I can see that changing font does influence stability of M-x term and
it does not make it same as external terminals. Just by feeling it
looks like it is not handling well those wide characters.

There are 2 screenshots attached:

1. One is Emacs M-x term there is line, above the line (53) and one
   can see it being pulled to the left side

2. XTerm version shows it is displayed aligned to the column.

I have also observed that by removing PS1 and special control
sequences inside the M-x term works better. It works best when bash is
invoked with --norc and when I do $ reset few times, each time when I
see something changed.

I have:

alias ls='ls --color=auto'

and each time I invoke ls I can see that font also changed for the
rest of work. If I invoke $ reset and then /bin/ls then I remain in
the same font.

Fonts are changing to me as user uncontrollably. My .bashrc and
aliases and basically anything using those control sequences is
changing the font. In my opinion it is switching back to DejaVu Sans
Mono even though I set other font.

Those are various observations. It looks like control sequences are
not terminated correctly.

The third screenshot shows what is happening when using ls with
Terminus font as after 2001-10 which appears green the rest of fonts
appear bold.

If somebody has stable M-x term or ansi-term and uses some appropriate
font or has good settings, let me know.

[-- Attachment #2: Screenshot from 2020-11-18 22-53-01.png --]
[-- Type: image/png, Size: 58364 bytes --]

[-- Attachment #3: Screenshot from 2020-11-18 22-57-30.png --]
[-- Type: image/png, Size: 71384 bytes --]

[-- Attachment #4: Screenshot from 2020-11-18 23-03-58.png --]
[-- Type: image/png, Size: 78252 bytes --]