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

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

[Jean Louis]

This trouble also takes place under emacs -Q:

Recipe:

Obtain the archive file:
https://lists.gnu.org/archive/mbox/gnu-emacs-sources/2002-01

invoke M-x term

run mutt to see the file:

mutt -f 2002-01

go up and down to see distortions. While this is mutt it does not
matter as term is making problems due to those weird chars on screen.

Screenshot:
https://gnu.support/images/2020/11/2020-11-15/Screenshot-from-2020-11-15%2022-30-03.png

Screenshot cannot help in understanding, it needs video. When user
moves up and down the lines the lines get distorted or duplicated or
highlighting lines remain where they should not or get duplicated or
user sees one line which is not that line in reality.



In GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, X toolkit, cairo version 1.14.8, Xaw3d scroll bars)
 of 2020-11-14 built on protected.rcdrun.com
Repository revision: 31f94e4b1c3dc201646ec436d3e2c477f784ed21
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.11907000
System Description: Hyperbola GNU/Linux-libre

Configured using:
 'configure --prefix=/package/text/emacs-2020-11-14 --with-modules
 --with-x-toolkit=lucid'

Configured features:
XAW3D XPM JPEG TIFF GIF PNG RSVG CAIRO SOUND GPM DBUS GSETTINGS GLIB
NOTIFY INOTIFY ACL GNUTLS LIBXML2 FREETYPE HARFBUZZ M17N_FLT LIBOTF
ZLIB TOOLKIT_SCROLL_BARS LUCID X11 XDBE XIM MODULES THREADS JSON
PDUMPER LCMS2

Important settings:
  value of $LC_ALL: en_US.UTF-8
  value of $LANG: de_DE.UTF-8
  value of $XMODIFIERS: @im=exwm-xim
  locale-coding-system: utf-8-unix

Major mode: Term

Minor modes in effect:
  recentf-mode: t
  timeclock-mode-line-display: t
  show-paren-mode: t
  save-place-mode: t
  immortal-scratch-mode: t
  electric-pair-mode: t
  display-time-mode: t
  display-battery-mode: t
  helm-ff-cache-mode: t
  shell-dirtrack-mode: t
  async-bytecomp-package-mode: t
  ivy-mode: t
  persistent-scratch-autosave-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  buffer-read-only: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
~/Programming/git/emacs-libpq/test hides /home/data1/protected/Programming/emacs-lisp/test
/home/data1/protected/Programming/emacs-lisp/rcd-cf hides /home/data1/protected/.emacs.d/elpa/rcd-cf-1.13/rcd-cf
/home/data1/protected/Programming/emacs-lisp/rcd-db hides /home/data1/protected/.emacs.d/elpa/rcd-db-1.13/rcd-db
/home/data1/protected/Programming/emacs-lisp/rcd-db-init hides /home/data1/protected/.emacs.d/elpa/rcd-db-init-1.7/rcd-db-init
/home/data1/protected/Programming/emacs-lisp/rcd-password hides /home/data1/protected/.emacs.d/elpa/rcd-password-1.1/rcd-password
/home/data1/protected/Programming/emacs-lisp/rcd-utilities hides /home/data1/protected/.emacs.d/elpa/rcd-utilities-1.24/rcd-utilities
~/Programming/git/emacs-libvterm/vterm hides /home/data1/protected/.emacs.d/elpa/vterm-0.0.1/vterm
/home/data1/protected/.emacs.d/packages/printing hides /package/text/emacs-2020-11-14/share/emacs/28.0.50/lisp/printing
/home/data1/protected/.emacs.d/elpa/org-20201019/ob-css hides /package/text/emacs-2020-11-14/share/emacs/28.0.50/lisp/org/ob-css
/home/data1/protected/.emacs.d/elpa/org-20201019/ob-dot hides /package/text/emacs-2020-11-14/share/emacs/28.0.50/lisp/org/ob-dot
/home/data1/protected/.emacs.d/elpa/org-20201019/ob-sed hides /package/text/emacs-2020-11-14/share/emacs/28.0.50/lisp/org/ob-sed
/home/data1/protected/.emacs.d/elpa/org-20201019/ob-stan hides /package/text/emacs-2020-11-14/share/emacs/28.0.50/lisp/org/ob-stan
/home/data1/protected/.emacs.d/elpa/org-20201019/ob-sqlite hides /package/text/emacs-2020-11-14/share/emacs/28.0.50/lisp/org/ob-sqlite
/home/data1/protected/.emacs.d/elpa/org-20201019/ol-bbdb hides /package/text/emacs-2020-11-14/share/emacs/28.0.50/lisp/org/ol-bbdb
/home/data1/protected/.emacs.d/elpa/org-20201019/ol-gnus hides /package/text/emacs-2020-11-14/share/emacs/28.0.50/lisp/org/ol-gnus
/home/data1/protected/.emacs.d/elpa/org-20201019/org-src hides /package/text/emacs-2020-11-14/share/emacs/28.0.50/lisp/org/org-src
/home/data1/protected/.emacs.d/elpa/org-20201019/ob-lob hides /package/text/emacs-2020-11-14/share/emacs/28.0.50/lisp/org/ob-lob
/home/data1/protected/.emacs.d/elpa/org-20201019/ob-calc hides /package/text/emacs-2020-11-14/share/emacs/28.0.50/lisp/org/ob-calc
/home/data1/protected/.emacs.d/elpa/org-20201019/ob-mscgen hides /package/text/emacs-2020-11-14/share/emacs/28.0.50/lisp/org/ob-mscgen
/home/data1/protected/.emacs.d/elpa/org-20201019/ob-core hides /package/text/emacs-2020-11-14/share/emacs/28.0.50/lisp/org/ob-core
/home/data1/protected/.emacs.d/elpa/org-20201019/ox-beamer hides /package/text/emacs-2020-11-14/share/emacs/28.0.50/lisp/org/ox-beamer
/home/data1/protected/.emacs.d/elpa/org-20201019/ob-sass hides /package/text/emacs-2020-11-14/share/emacs/28.0.50/lisp/org/ob-sass
/home/data1/protected/.emacs.d/elpa/org-20201019/ob-plantuml hides /package/text/emacs-2020-11-14/share/emacs/28.0.50/lisp/org/ob-plantuml
/home/data1/protected/.emacs.d/elpa/org-20201019/org-keys hides /package/text/emacs-2020-11-14/share/emacs/28.0.50/lisp/org/org-keys
/home/data1/protected/.emacs.d/elpa/org-20201019/ob-coq hides /package/text/emacs-2020-11-14/share/emacs/28.0.50/lisp/org/ob-coq
/home/data1/protected/.emacs.d/elpa/org-20201019/ob-js hides /package/text/emacs-2020-11-14/share/emacs/28.0.50/lisp/org/ob-js
/home/data1/protected/.emacs.d/elpa/org-20201019/org-plot hides /package/text/emacs-2020-11-14/share/emacs/28.0.50/lisp/org/org-plot
/home/data1/protected/.emacs.d/elpa/org-20201019/org-macro hides /package/text/emacs-2020-11-14/share/emacs/28.0.50/lisp/org/org-macro
/home/data1/protected/.emacs.d/elpa/org-20201019/org-inlinetask hides /package/text/emacs-2020-11-14/share/emacs/28.0.50/lisp/org/org-inlinetask
/home/data1/protected/.emacs.d/elpa/org-20201019/org-timer hides /package/text/emacs-2020-11-14/share/emacs/28.0.50/lisp/org/org-timer
/home/data1/protected/.emacs.d/elpa/org-20201019/ox hides /package/text/emacs-2020-11-14/share/emacs/28.0.50/lisp/org/ox
/home/data1/protected/.emacs.d/elpa/org-20201019/ob-forth hides /package/text/emacs-2020-11-14/share/emacs/28.0.50/lisp/org/ob-forth
/home/data1/protected/.emacs.d/elpa/org-20201019/ob-groovy hides /package/text/emacs-2020-11-14/share/emacs/28.0.50/lisp/org/ob-groovy
/home/data1/protected/.emacs.d/elpa/org-20201019/ob-perl hides /package/text/emacs-2020-11-14/share/emacs/28.0.50/lisp/org/ob-perl
/home/data1/protected/.emacs.d/elpa/org-20201019/ob-gnuplot hides /package/text/emacs-2020-11-14/share/emacs/28.0.50/lisp/org/ob-gnuplot
/home/data1/protected/.emacs.d/elpa/org-20201019/ox-latex hides /package/text/emacs-2020-11-14/share/emacs/28.0.50/lisp/org/ox-latex
/home/data1/protected/.emacs.d/elpa/org-20201019/ob-sql hides /package/text/emacs-2020-11-14/share/emacs/28.0.50/lisp/org/ob-sql
/home/data1/protected/.emacs.d/elpa/org-20201019/ob-screen hides /package/text/emacs-2020-11-14/share/emacs/28.0.50/lisp/org/ob-screen
/home/data1/protected/.emacs.d/elpa/org-20201019/org-archive hides /package/text/emacs-2020-11-14/share/emacs/28.0.50/lisp/org/org-archive
/home/data1/protected/.emacs.d/elpa/org-20201019/ob-haskell hides /package/text/emacs-2020-11-14/share/emacs/28.0.50/lisp/org/ob-haskell
/home/data1/protected/.emacs.d/elpa/org-20201019/org-footnote hides /package/text/emacs-2020-11-14/share/emacs/28.0.50/lisp/org/org-footnote
/home/data1/protected/.emacs.d/elpa/org-20201019/ox-man hides /package/text/emacs-2020-11-14/share/emacs/28.0.50/lisp/org/ox-man
/home/data1/protected/.emacs.d/elpa/org-20201019/ol-w3m hides /package/text/emacs-2020-11-14/share/emacs/28.0.50/lisp/org/ol-w3m
/home/data1/protected/.emacs.d/elpa/org-20201019/org-protocol hides /package/text/emacs-2020-11-14/share/emacs/28.0.50/lisp/org/org-protocol
/home/data1/protected/.emacs.d/elpa/org-20201019/org-num hides /package/text/emacs-2020-11-14/share/emacs/28.0.50/lisp/org/org-num
/home/data1/protected/.emacs.d/elpa/org-20201019/ob-ref hides /package/text/emacs-2020-11-14/share/emacs/28.0.50/lisp/org/ob-ref
/home/data1/protected/.emacs.d/elpa/org-20201019/ob-processing hides /package/text/emacs-2020-11-14/share/emacs/28.0.50/lisp/org/ob-processing
/home/data1/protected/.emacs.d/elpa/org-20201019/org-habit hides /package/text/emacs-2020-11-14/share/emacs/28.0.50/lisp/org/org-habit
/home/data1/protected/.emacs.d/elpa/org-20201019/org-indent hides /package/text/emacs-2020-11-14/share/emacs/28.0.50/lisp/org/org-indent
/home/data1/protected/.emacs.d/elpa/org-20201019/ob-maxima hides /package/text/emacs-2020-11-14/share/emacs/28.0.50/lisp/org/ob-maxima
/home/data1/protected/.emacs.d/elpa/org-20201019/ol-info hides /package/text/emacs-2020-11-14/share/emacs/28.0.50/lisp/org/ol-info
/home/data1/protected/.emacs.d/elpa/org-20201019/org-list hides /package/text/emacs-2020-11-14/share/emacs/28.0.50/lisp/org/org-list
/home/data1/protected/.emacs.d/elpa/org-20201019/org-entities hides /package/text/emacs-2020-11-14/share/emacs/28.0.50/lisp/org/org-entities
/home/data1/protected/.emacs.d/elpa/org-20201019/ob-fortran hides /package/text/emacs-2020-11-14/share/emacs/28.0.50/lisp/org/ob-fortran
/home/data1/protected/.emacs.d/elpa/org-20201019/ob-eshell hides /package/text/emacs-2020-11-14/share/emacs/28.0.50/lisp/org/ob-eshell
/home/data1/protected/.emacs.d/elpa/org-20201019/ob-comint hides /package/text/emacs-2020-11-14/share/emacs/28.0.50/lisp/org/ob-comint
/home/data1/protected/.emacs.d/elpa/org-20201019/ol-eshell hides /package/text/emacs-2020-11-14/share/emacs/28.0.50/lisp/org/ol-eshell
/home/data1/protected/.emacs.d/elpa/org-20201019/ol-docview hides /package/text/emacs-2020-11-14/share/emacs/28.0.50/lisp/org/ol-docview
/home/data1/protected/.emacs.d/elpa/org-20201019/ob-ruby hides /package/text/emacs-2020-11-14/share/emacs/28.0.50/lisp/org/ob-ruby
/home/data1/protected/.emacs.d/elpa/org-20201019/org hides /package/text/emacs-2020-11-14/share/emacs/28.0.50/lisp/org/org
/home/data1/protected/.emacs.d/elpa/org-20201019/ol-eww hides /package/text/emacs-2020-11-14/share/emacs/28.0.50/lisp/org/ol-eww
/home/data1/protected/.emacs.d/elpa/org-20201019/org-macs hides /package/text/emacs-2020-11-14/share/emacs/28.0.50/lisp/org/org-macs
/home/data1/protected/.emacs.d/elpa/org-20201019/org-agenda hides /package/text/emacs-2020-11-14/share/emacs/28.0.50/lisp/org/org-agenda
/home/data1/protected/.emacs.d/elpa/org-20201019/ox-org hides /package/text/emacs-2020-11-14/share/emacs/28.0.50/lisp/org/ox-org
/home/data1/protected/.emacs.d/elpa/org-20201019/ob-C hides /package/text/emacs-2020-11-14/share/emacs/28.0.50/lisp/org/ob-C
/home/data1/protected/.emacs.d/elpa/org-20201019/org-install hides /package/text/emacs-2020-11-14/share/emacs/28.0.50/lisp/org/org-install
/home/data1/protected/.emacs.d/elpa/org-20201019/ob-makefile hides /package/text/emacs-2020-11-14/share/emacs/28.0.50/lisp/org/ob-makefile
/home/data1/protected/.emacs.d/elpa/org-20201019/ob-java hides /package/text/emacs-2020-11-14/share/emacs/28.0.50/lisp/org/ob-java
/home/data1/protected/.emacs.d/elpa/org-20201019/ob-org hides /package/text/emacs-2020-11-14/share/emacs/28.0.50/lisp/org/ob-org
/home/data1/protected/.emacs.d/elpa/org-20201019/org-table hides /package/text/emacs-2020-11-14/share/emacs/28.0.50/lisp/org/org-table
/home/data1/protected/.emacs.d/elpa/org-20201019/ob hides /package/text/emacs-2020-11-14/share/emacs/28.0.50/lisp/org/ob
/home/data1/protected/.emacs.d/elpa/org-20201019/org-id hides /package/text/emacs-2020-11-14/share/emacs/28.0.50/lisp/org/org-id
/home/data1/protected/.emacs.d/elpa/org-20201019/ob-eval hides /package/text/emacs-2020-11-14/share/emacs/28.0.50/lisp/org/ob-eval
/home/data1/protected/.emacs.d/elpa/org-20201019/ob-clojure hides /package/text/emacs-2020-11-14/share/emacs/28.0.50/lisp/org/ob-clojure
/home/data1/protected/.emacs.d/elpa/org-20201019/ob-ledger hides /package/text/emacs-2020-11-14/share/emacs/28.0.50/lisp/org/ob-ledger
/home/data1/protected/.emacs.d/elpa/org-20201019/ob-shen hides /package/text/emacs-2020-11-14/share/emacs/28.0.50/lisp/org/ob-shen
/home/data1/protected/.emacs.d/elpa/org-20201019/ox-ascii hides /package/text/emacs-2020-11-14/share/emacs/28.0.50/lisp/org/ox-ascii
/home/data1/protected/.emacs.d/elpa/org-20201019/ox-publish hides /package/text/emacs-2020-11-14/share/emacs/28.0.50/lisp/org/ox-publish
/home/data1/protected/.emacs.d/elpa/org-20201019/ox-texinfo hides /package/text/emacs-2020-11-14/share/emacs/28.0.50/lisp/org/ox-texinfo
/home/data1/protected/.emacs.d/elpa/org-20201019/org-duration hides /package/text/emacs-2020-11-14/share/emacs/28.0.50/lisp/org/org-duration
/home/data1/protected/.emacs.d/elpa/org-20201019/org-colview hides /package/text/emacs-2020-11-14/share/emacs/28.0.50/lisp/org/org-colview
/home/data1/protected/.emacs.d/elpa/org-20201019/org-datetree hides /package/text/emacs-2020-11-14/share/emacs/28.0.50/lisp/org/org-datetree
/home/data1/protected/.emacs.d/elpa/org-20201019/ob-vala hides /package/text/emacs-2020-11-14/share/emacs/28.0.50/lisp/org/ob-vala
/home/data1/protected/.emacs.d/elpa/org-20201019/ob-table hides /package/text/emacs-2020-11-14/share/emacs/28.0.50/lisp/org/ob-table
/home/data1/protected/.emacs.d/elpa/org-20201019/ob-tangle hides /package/text/emacs-2020-11-14/share/emacs/28.0.50/lisp/org/ob-tangle
/home/data1/protected/.emacs.d/elpa/org-20201019/org-pcomplete hides /package/text/emacs-2020-11-14/share/emacs/28.0.50/lisp/org/org-pcomplete
/home/data1/protected/.emacs.d/elpa/org-20201019/org-version hides /package/text/emacs-2020-11-14/share/emacs/28.0.50/lisp/org/org-version
/home/data1/protected/.emacs.d/elpa/org-20201019/ob-R hides /package/text/emacs-2020-11-14/share/emacs/28.0.50/lisp/org/ob-R
/home/data1/protected/.emacs.d/elpa/org-20201019/ob-picolisp hides /package/text/emacs-2020-11-14/share/emacs/28.0.50/lisp/org/ob-picolisp
/home/data1/protected/.emacs.d/elpa/org-20201019/ob-lua hides /package/text/emacs-2020-11-14/share/emacs/28.0.50/lisp/org/ob-lua
/home/data1/protected/.emacs.d/elpa/org-20201019/ox-odt hides /package/text/emacs-2020-11-14/share/emacs/28.0.50/lisp/org/ox-odt
/home/data1/protected/.emacs.d/elpa/org-20201019/ob-awk hides /package/text/emacs-2020-11-14/share/emacs/28.0.50/lisp/org/ob-awk
/home/data1/protected/.emacs.d/elpa/org-20201019/ob-exp hides /package/text/emacs-2020-11-14/share/emacs/28.0.50/lisp/org/ob-exp
/home/data1/protected/.emacs.d/elpa/org-20201019/ox-md hides /package/text/emacs-2020-11-14/share/emacs/28.0.50/lisp/org/ox-md
/home/data1/protected/.emacs.d/elpa/org-20201019/ob-abc hides /package/text/emacs-2020-11-14/share/emacs/28.0.50/lisp/org/ob-abc
/home/data1/protected/.emacs.d/elpa/org-20201019/ol-mhe hides /package/text/emacs-2020-11-14/share/emacs/28.0.50/lisp/org/ol-mhe
/home/data1/protected/.emacs.d/elpa/org-20201019/ob-ocaml hides /package/text/emacs-2020-11-14/share/emacs/28.0.50/lisp/org/ob-ocaml
/home/data1/protected/.emacs.d/elpa/org-20201019/org-crypt hides /package/text/emacs-2020-11-14/share/emacs/28.0.50/lisp/org/org-crypt
/home/data1/protected/.emacs.d/elpa/org-20201019/ob-python hides /package/text/emacs-2020-11-14/share/emacs/28.0.50/lisp/org/ob-python
/home/data1/protected/.emacs.d/elpa/org-20201019/ox-html hides /package/text/emacs-2020-11-14/share/emacs/28.0.50/lisp/org/ox-html
/home/data1/protected/.emacs.d/elpa/org-20201019/ob-matlab hides /package/text/emacs-2020-11-14/share/emacs/28.0.50/lisp/org/ob-matlab
/home/data1/protected/.emacs.d/elpa/org-20201019/org-attach hides /package/text/emacs-2020-11-14/share/emacs/28.0.50/lisp/org/org-attach
/home/data1/protected/.emacs.d/elpa/org-20201019/ol-irc hides /package/text/emacs-2020-11-14/share/emacs/28.0.50/lisp/org/ol-irc
/home/data1/protected/.emacs.d/elpa/org-20201019/ob-hledger hides /package/text/emacs-2020-11-14/share/emacs/28.0.50/lisp/org/ob-hledger
/home/data1/protected/.emacs.d/elpa/org-20201019/org-loaddefs hides /package/text/emacs-2020-11-14/share/emacs/28.0.50/lisp/org/org-loaddefs
/home/data1/protected/.emacs.d/elpa/org-20201019/ob-octave hides /package/text/emacs-2020-11-14/share/emacs/28.0.50/lisp/org/ob-octave
/home/data1/protected/.emacs.d/elpa/org-20201019/org-ctags hides /package/text/emacs-2020-11-14/share/emacs/28.0.50/lisp/org/org-ctags
/home/data1/protected/.emacs.d/elpa/org-20201019/ob-asymptote hides /package/text/emacs-2020-11-14/share/emacs/28.0.50/lisp/org/ob-asymptote
/home/data1/protected/.emacs.d/elpa/org-20201019/ob-ditaa hides /package/text/emacs-2020-11-14/share/emacs/28.0.50/lisp/org/ob-ditaa
/home/data1/protected/.emacs.d/elpa/org-20201019/ol hides /package/text/emacs-2020-11-14/share/emacs/28.0.50/lisp/org/ol
/home/data1/protected/.emacs.d/elpa/org-20201019/org-compat hides /package/text/emacs-2020-11-14/share/emacs/28.0.50/lisp/org/org-compat
/home/data1/protected/.emacs.d/elpa/org-20201019/org-feed hides /package/text/emacs-2020-11-14/share/emacs/28.0.50/lisp/org/org-feed
/home/data1/protected/.emacs.d/elpa/org-20201019/ob-J hides /package/text/emacs-2020-11-14/share/emacs/28.0.50/lisp/org/ob-J
/home/data1/protected/.emacs.d/elpa/org-20201019/ob-shell hides /package/text/emacs-2020-11-14/share/emacs/28.0.50/lisp/org/ob-shell
/home/data1/protected/.emacs.d/elpa/org-20201019/ob-lilypond hides /package/text/emacs-2020-11-14/share/emacs/28.0.50/lisp/org/ob-lilypond
/home/data1/protected/.emacs.d/elpa/org-20201019/ol-rmail hides /package/text/emacs-2020-11-14/share/emacs/28.0.50/lisp/org/ol-rmail
/home/data1/protected/.emacs.d/elpa/org-20201019/org-element hides /package/text/emacs-2020-11-14/share/emacs/28.0.50/lisp/org/org-element
/home/data1/protected/.emacs.d/elpa/org-20201019/ob-io hides /package/text/emacs-2020-11-14/share/emacs/28.0.50/lisp/org/ob-io
/home/data1/protected/.emacs.d/elpa/org-20201019/org-faces hides /package/text/emacs-2020-11-14/share/emacs/28.0.50/lisp/org/org-faces
/home/data1/protected/.emacs.d/elpa/org-20201019/org-capture hides /package/text/emacs-2020-11-14/share/emacs/28.0.50/lisp/org/org-capture
/home/data1/protected/.emacs.d/elpa/org-20201019/org-goto hides /package/text/emacs-2020-11-14/share/emacs/28.0.50/lisp/org/org-goto
/home/data1/protected/.emacs.d/elpa/org-20201019/org-lint hides /package/text/emacs-2020-11-14/share/emacs/28.0.50/lisp/org/org-lint
/home/data1/protected/.emacs.d/elpa/org-20201019/ol-bibtex hides /package/text/emacs-2020-11-14/share/emacs/28.0.50/lisp/org/ol-bibtex
/home/data1/protected/.emacs.d/elpa/org-20201019/ob-lisp hides /package/text/emacs-2020-11-14/share/emacs/28.0.50/lisp/org/ob-lisp
/home/data1/protected/.emacs.d/elpa/org-20201019/org-tempo hides /package/text/emacs-2020-11-14/share/emacs/28.0.50/lisp/org/org-tempo
/home/data1/protected/.emacs.d/elpa/org-20201019/org-clock hides /package/text/emacs-2020-11-14/share/emacs/28.0.50/lisp/org/org-clock
/home/data1/protected/.emacs.d/elpa/org-20201019/ob-ebnf hides /package/text/emacs-2020-11-14/share/emacs/28.0.50/lisp/org/ob-ebnf
/home/data1/protected/.emacs.d/elpa/org-20201019/org-mobile hides /package/text/emacs-2020-11-14/share/emacs/28.0.50/lisp/org/org-mobile
/home/data1/protected/.emacs.d/elpa/org-20201019/ob-scheme hides /package/text/emacs-2020-11-14/share/emacs/28.0.50/lisp/org/ob-scheme
/home/data1/protected/.emacs.d/elpa/org-20201019/ob-latex hides /package/text/emacs-2020-11-14/share/emacs/28.0.50/lisp/org/ob-latex
/home/data1/protected/.emacs.d/elpa/org-20201019/ob-emacs-lisp hides /package/text/emacs-2020-11-14/share/emacs/28.0.50/lisp/org/ob-emacs-lisp
/home/data1/protected/.emacs.d/elpa/org-20201019/org-attach-git hides /package/text/emacs-2020-11-14/share/emacs/28.0.50/lisp/org/org-attach-git
/home/data1/protected/.emacs.d/elpa/org-20201019/org-mouse hides /package/text/emacs-2020-11-14/share/emacs/28.0.50/lisp/org/org-mouse
/home/data1/protected/.emacs.d/elpa/org-20201019/ox-icalendar hides /package/text/emacs-2020-11-14/share/emacs/28.0.50/lisp/org/ox-icalendar
/home/data1/protected/.emacs.d/elpa/flim-20200908.1428/sasl hides /package/text/emacs-2020-11-14/share/emacs/28.0.50/lisp/net/sasl

Features:
(shadow mailalias emacsbug dired-x shortdoc cps rabbit rect quail
vc-src vc-sccs vc-svn vc-cvs vc vc-dispatcher project debug backtrace
sql whitespace markdown-mode edit-indirect rcd-devel-utilities rx ffap
recentf tree-widget pcmpl-unix em-unix em-term term ehelp em-script
em-prompt em-ls em-hist em-pred em-glob em-dirs esh-var em-cmpl
em-basic em-banner em-alias esh-mode eshell esh-cmd esh-ext esh-opt
esh-proc esh-io esh-arg esh-module esh-groups esh-util ispell server
vc-filewise vc-rcs hyperscope sendmail bookmark pp imenu disp-table
woman man sh-script smie executable cl-print help-fns radix-tree
winner sort helm-system-packages-pacman helm-system-packages tramp-sh
cperl-mode view vc-git diff-mode perl-mode face-remap url-cache
url-auth url-file url-dired dired-aux dired-launch mule-util misearch
multi-isearch org-element avl-tree generator ol-w3m ol-rmail ol-mhe
ol-irc ol-info org-id org-refile ol-gnus nnselect gnus-search
eieio-opt cl-extra help-mode speedbar ezimage dframe ol-eww eww xdg
url-queue thingatpt mm-url ol-docview doc-view jka-compr image-mode
exif ol-bibtex bibtex ol-bbdb ob-dot ob-lisp ob-perl ob-scheme
ob-shell ob-sql ob-ditaa ob-plantuml timeclock paren scroll-all
saveplace immortal-scratch hl-line elec-pair time battery cus-start
cus-load festival rcd-wrs-variables bbdb bbdb-site timezone mutt-tools
maildir qp maildir-index dash s noflet cl-indent dotassoc kv gnus-art
mm-uu mml2015 gnus-sum shr kinsoku svg dom gnus-group gnus-undo
gnus-start gnus-dbus dbus xml gnus-cloud nnimap nnmail mail-source
utf7 netrc nnoo gnus-spec gnus-int gnus-range message rmc puny dired
dired-loaddefs rfc822 mml mailabbrev gmm-utils gnus-win gnus nnheader
wid-edit mm-view mml-smime mml-sec epa derived epg epg-config
gnus-util rmail rmail-loaddefs mail-utils smime dig mm-decode
mm-bodies mm-encode mail-parse rfc2231 rfc2047 rfc2045 mm-util
ietf-drums mail-prsvr mailheader windmove rcd-cf org ob ob-tangle
ob-ref ob-lob ob-table ob-exp org-macro org-footnote org-src ob-comint
org-pcomplete org-list org-faces org-entities noutline outline
org-version ob-emacs-lisp ob-core ob-eval org-table ol org-keys
org-compat org-macs org-loaddefs find-func cal-menu calendar
cal-loaddefs chart rcd-db helm-mode helm-files tramp tramp-loaddefs
trampver tramp-integration files-x tramp-compat shell pcomplete
parse-time iso8601 time-date ls-lisp helm-buffers helm-occur helm-tags
helm-locate helm-grep wgrep-helm wgrep grep compile
text-property-search comint ansi-color helm-regexp format-spec
helm-utils helm-help helm-types helm async-bytecomp advice
helm-global-bindings helm-source eieio-compat helm-multi-match
helm-lib async time-stamp rcd-db-init skeleton pq rcd-sent-folder
rcd-password rcd-utilities ivy delsel ring ivy-faces ivy-overlay colir
color persistent-scratch helm-config gold-price units tex-site edmacro
kmacro helm-easymenu kotl-autoloads finder-inf cl easy-mmode info
package easymenu browse-url url url-proxy url-privacy url-expand
url-methods url-history url-cookie url-domsuf url-util mailcap
url-handlers url-parse auth-source cl-seq eieio eieio-core cl-macs
eieio-loaddefs password-cache json subr-x map url-vars seq byte-opt gv
bytecomp byte-compile cconv cl-loaddefs cl-lib tooltip eldoc electric
uniquify ediff-hook vc-hooks lisp-float-type mwheel term/x-win x-win
term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode elisp-mode lisp-mode
prog-mode register page tab-bar menu-bar rfn-eshadow isearch timer
select scroll-bar mouse jit-lock font-lock syntax facemenu font-core
term/tty-colors frame minibuffer cl-generic cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese
eucjp-ms cp51932 hebrew greek romanian slovak czech european ethiopic
indian cyrillic chinese composite charscript charprop case-table
epa-hook jka-cmpr-hook help simple abbrev obarray cl-preloaded nadvice
button loaddefs faces cus-face macroexp files window text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote threads dbusbind inotify lcms2
dynamic-setting system-font-setting font-render-setting cairo
x-toolkit x multi-tty make-network-process emacs)

Memory information:
((conses 16 780308 76717)
 (symbols 48 39968 1)
 (strings 32 245219 4858)
 (string-bytes 1 8567118)
 (vectors 16 72398)
 (vector-slots 8 1612678 163071)
 (floats 8 559 797)
 (intervals 56 52220 1478)
 (buffers 992 48))


-- 
Thanks,
Jean Louis
⎔ λ 🄯 𝍄 𝌡 𝌚

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

[Lars Ingebrigtsen]

Jean Louis <bugs@gnu.support> writes:

> run mutt to see the file:
>
> mutt -f 2002-01
>
> go up and down to see distortions. While this is mutt it does not
> matter as term is making problems due to those weird chars on screen.

Yup; I can reproduce this on the trunk with "emacs -Q" (but not with my
normal configuration).  I'm guessing it has something to do with how
mutt outputs the non-ASCII characters -- it's pretty much a mess (i.e.,
non-valid UTF-8 sequences, perhaps?)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Jean Louis]

* Lars Ingebrigtsen <larsi@gnus.org> [2020-11-17 01:30]:
> Jean Louis <bugs@gnu.support> writes:
> 
> > run mutt to see the file:
> >
> > mutt -f 2002-01
> >
> > go up and down to see distortions. While this is mutt it does not
> > matter as term is making problems due to those weird chars on screen.
> 
> Yup; I can reproduce this on the trunk with "emacs -Q" (but not with my
> normal configuration).  I'm guessing it has something to do with how
> mutt outputs the non-ASCII characters -- it's pretty much a mess (i.e.,
> non-valid UTF-8 sequences, perhaps?)

Let me add that within emacs-libpq M-x vterm it works without any
problems, including on any terminal emulator outside of Emacs.

https://github.com/akermu/emacs-libvterm

Excerpt:

term: it is a terminal emulator written in elisp. term runs a shell (similarly to other terminal emulators like Gnome Terminal) and programs can directly manipulate the output using escape codes. Hence, many interactive applications (like the one aforementioned) work with term. However, term and ansi-term do not implement all the escapes codes needed, so some programs do not work properly. Moreover, term has inferior performance compared to standalone terminals, especially with large bursts of output.

Maybe that is problem. I do not know.

I wish I would not need to use external dynamic module.

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

[Andreas Schwab]

On Nov 15 2020, Jean Louis wrote:

> This trouble also takes place under emacs -Q:
>
> Recipe:
>
> Obtain the archive file:
> https://lists.gnu.org/archive/mbox/gnu-emacs-sources/2002-01
>
> invoke M-x term
>
> run mutt to see the file:
>
> mutt -f 2002-01
>
> go up and down to see distortions. While this is mutt it does not
> matter as term is making problems due to those weird chars on screen.

You need to make sure all characters are coming from the same monospace
font, or that all fonts that are used here have exactly the same
dimensions.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

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

[Jean Louis]

* Andreas Schwab <schwab@linux-m68k.org> [2020-11-17 12:00]:
> On Nov 15 2020, Jean Louis wrote:
> 
> > This trouble also takes place under emacs -Q:
> >
> > Recipe:
> >
> > Obtain the archive file:
> > https://lists.gnu.org/archive/mbox/gnu-emacs-sources/2002-01
> >
> > invoke M-x term
> >
> > run mutt to see the file:
> >
> > mutt -f 2002-01
> >
> > go up and down to see distortions. While this is mutt it does not
> > matter as term is making problems due to those weird chars on screen.
> 
> You need to make sure all characters are coming from the same monospace
> font, or that all fonts that are used here have exactly the same
> dimensions.

How do I make sure of it?

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

[Andreas Schwab]

On Nov 17 2020, Jean Louis wrote:

> * Andreas Schwab <schwab@linux-m68k.org> [2020-11-17 12:00]:
>> On Nov 15 2020, Jean Louis wrote:
>> 
>> > This trouble also takes place under emacs -Q:
>> >
>> > Recipe:
>> >
>> > Obtain the archive file:
>> > https://lists.gnu.org/archive/mbox/gnu-emacs-sources/2002-01
>> >
>> > invoke M-x term
>> >
>> > run mutt to see the file:
>> >
>> > mutt -f 2002-01
>> >
>> > go up and down to see distortions. While this is mutt it does not
>> > matter as term is making problems due to those weird chars on screen.
>> 
>> You need to make sure all characters are coming from the same monospace
>> font, or that all fonts that are used here have exactly the same
>> dimensions.
>
> How do I make sure of it?

By using the right fonts.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

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

[Jean Louis]

* Andreas Schwab <schwab@linux-m68k.org> [2020-11-17 12:55]:
> On Nov 17 2020, Jean Louis wrote:
> 
> > * Andreas Schwab <schwab@linux-m68k.org> [2020-11-17 12:00]:
> >> On Nov 15 2020, Jean Louis wrote:
> >> 
> >> > This trouble also takes place under emacs -Q:
> >> >
> >> > Recipe:
> >> >
> >> > Obtain the archive file:
> >> > https://lists.gnu.org/archive/mbox/gnu-emacs-sources/2002-01
> >> >
> >> > invoke M-x term
> >> >
> >> > run mutt to see the file:
> >> >
> >> > mutt -f 2002-01
> >> >
> >> > go up and down to see distortions. While this is mutt it does not
> >> > matter as term is making problems due to those weird chars on screen.
> >> 
> >> You need to make sure all characters are coming from the same monospace
> >> font, or that all fonts that are used here have exactly the same
> >> dimensions.
> >
> > How do I make sure of it?
> 
> By using the right fonts.

Do you have example name of right font?

I am now using DejaVu Sans Mono in Emacs. Which font should I
customize for term or ansi-term that it works well?

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

[Eli Zaretskii]

> Date: Tue, 17 Nov 2020 13:00:03 +0300
> From: Jean Louis <bugs@gnu.support>
> Cc: 44664@debbugs.gnu.org
> 
> > > How do I make sure of it?
> > 
> > By using the right fonts.
> 
> Do you have example name of right font?
> 
> I am now using DejaVu Sans Mono in Emacs. Which font should I
> customize for term or ansi-term that it works well?

That depends on the characters you need to display.  Which characters
look bad/corrupted in term?  What are their codepoints?

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

[Jean Louis]

* Eli Zaretskii <eliz@gnu.org> [2020-11-17 18:13]:
> > Date: Tue, 17 Nov 2020 13:00:03 +0300
> > From: Jean Louis <bugs@gnu.support>
> > Cc: 44664@debbugs.gnu.org
> > 
> > > > How do I make sure of it?
> > > 
> > > By using the right fonts.
> > 
> > Do you have example name of right font?
> > 
> > I am now using DejaVu Sans Mono in Emacs. Which font should I
> > customize for term or ansi-term that it works well?
> 
> That depends on the characters you need to display.  Which characters
> look bad/corrupted in term?  What are their codepoints?

�θ��� ���µ� �ƴѵ� 5���� ������??..............................

Some of those probably, I cannot know which one, but I could copy it.

I have tried various fonts, I cannot find one working with it.

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

[Eli Zaretskii]

> Date: Tue, 17 Nov 2020 20:15:01 +0300
> From: Jean Louis <bugs@gnu.support>
> Cc: schwab@linux-m68k.org, 44664@debbugs.gnu.org
> 
> > That depends on the characters you need to display.  Which characters
> > look bad/corrupted in term?  What are their codepoints?
> 
> �θ��� ���µ� �ƴѵ� 5���� ������??..............................

Most of those didn't make it, please show their codepoints instead.

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

[Jean Louis]

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

* Eli Zaretskii <eliz@gnu.org> [2020-11-18 00:05]:
> > Date: Tue, 17 Nov 2020 20:15:01 +0300
> > From: Jean Louis <bugs@gnu.support>
> > Cc: schwab@linux-m68k.org, 44664@debbugs.gnu.org
> > 
> > > That depends on the characters you need to display.  Which characters
> > > look bad/corrupted in term?  What are their codepoints?
> > 
> > �θ��� ���µ� �ƴѵ� 5���� ������??..............................
> 
> Most of those didn't make it, please show their codepoints instead.

Small problem there with M-x describe-char:

cl--assertion-failed: Assertion failed: (not (multibyte-string-p str))

I can also see many errors:

Invalid face reference: mail-double-quoted-text-face [4 times]
Invalid face reference: mail-multiply-quoted-text-face [2 times]
Invalid face reference: mail-double-quoted-text-face [6 times]
Invalid face reference: mail-multiply-quoted-text-face [2 times]
Invalid face reference: mail-double-quoted-text-face [6 times]

Debugger entered--Lisp error: (cl-assertion-failed ((not (multibyte-string-p str)) nil))
  cl--assertion-failed((not (multibyte-string-p str)))
  encoded-string-description(#("�" 0 1 (charset unicode)) nil)
  describe-char(439)
  funcall-interactively(describe-char 439)
  call-interactively(describe-char record nil)
  command-execute(describe-char record)
  execute-extended-command(nil "describe-char" nil)
  funcall-interactively(execute-extended-command nil "describe-char" nil)
  call-interactively(execute-extended-command nil nil)
  command-execute(execute-extended-command)

Picture is attached showing chars.



[-- Attachment #2: Screenshot from 2020-11-18 00-52-34.png --]
[-- Type: image/png, Size: 106566 bytes --]

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

[Andreas Schwab]

On Nov 17 2020, Eli Zaretskii wrote:

>> Date: Tue, 17 Nov 2020 20:15:01 +0300
>> From: Jean Louis <bugs@gnu.support>
>> Cc: schwab@linux-m68k.org, 44664@debbugs.gnu.org
>> 
>> > That depends on the characters you need to display.  Which characters
>> > look bad/corrupted in term?  What are their codepoints?
>> 
>> �θ��� ���µ� �ƴѵ� 5���� ������??..............................
>
> Most of those didn't make it, please show their codepoints instead.

Thats's the result of mutt trying to interpret (undeclared) BIG5 as
UTF-8.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

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

[Eli Zaretskii]

> From: Andreas Schwab <schwab@linux-m68k.org>
> Cc: Jean Louis <bugs@gnu.support>,  44664@debbugs.gnu.org
> Date: Tue, 17 Nov 2020 23:02:28 +0100
> 
> On Nov 17 2020, Eli Zaretskii wrote:
> 
> >> Date: Tue, 17 Nov 2020 20:15:01 +0300
> >> From: Jean Louis <bugs@gnu.support>
> >> Cc: schwab@linux-m68k.org, 44664@debbugs.gnu.org
> >> 
> >> > That depends on the characters you need to display.  Which characters
> >> > look bad/corrupted in term?  What are their codepoints?
> >> 
> >> �θ��� ���µ� �ƴѵ� 5���� ������??..............................
> >
> > Most of those didn't make it, please show their codepoints instead.
> 
> Thats's the result of mutt trying to interpret (undeclared) BIG5 as
> UTF-8.

In which case it is not a font problem, it is a problem with
undeclared encoding of a mail message.  And the characters aren't
corrupted on display, they are just shown as octal escapes.

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

[Jean Louis]

* Eli Zaretskii <eliz@gnu.org> [2020-11-18 06:31]:
> > From: Andreas Schwab <schwab@linux-m68k.org>
> > Cc: Jean Louis <bugs@gnu.support>,  44664@debbugs.gnu.org
> > Date: Tue, 17 Nov 2020 23:02:28 +0100
> > 
> > On Nov 17 2020, Eli Zaretskii wrote:
> > 
> > >> Date: Tue, 17 Nov 2020 20:15:01 +0300
> > >> From: Jean Louis <bugs@gnu.support>
> > >> Cc: schwab@linux-m68k.org, 44664@debbugs.gnu.org
> > >> 
> > >> > That depends on the characters you need to display.  Which characters
> > >> > look bad/corrupted in term?  What are their codepoints?
> > >> 
> > >> �θ��� ���µ� �ƴѵ� 5���� ������??..............................
> > >
> > > Most of those didn't make it, please show their codepoints instead.
> > 
> > Thats's the result of mutt trying to interpret (undeclared) BIG5 as
> > UTF-8.
> 
> In which case it is not a font problem, it is a problem with
> undeclared encoding of a mail message.  And the characters aren't
> corrupted on display, they are just shown as octal escapes.

In any other terminal mutt is handling that well and terminal does not
make me any problems.

To avoid problems I am often using emacs-libvterm dynamic module.

ansi-term and term do not work with such.

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

[Andreas Schwab]

On Nov 18 2020, Eli Zaretskii wrote:

>> From: Andreas Schwab <schwab@linux-m68k.org>
>> Cc: Jean Louis <bugs@gnu.support>,  44664@debbugs.gnu.org
>> Date: Tue, 17 Nov 2020 23:02:28 +0100
>> 
>> On Nov 17 2020, Eli Zaretskii wrote:
>> 
>> >> Date: Tue, 17 Nov 2020 20:15:01 +0300
>> >> From: Jean Louis <bugs@gnu.support>
>> >> Cc: schwab@linux-m68k.org, 44664@debbugs.gnu.org
>> >> 
>> >> > That depends on the characters you need to display.  Which characters
>> >> > look bad/corrupted in term?  What are their codepoints?
>> >> 
>> >> �θ��� ���µ� �ƴѵ� 5���� ������??..............................
>> >
>> > Most of those didn't make it, please show their codepoints instead.
>> 
>> Thats's the result of mutt trying to interpret (undeclared) BIG5 as
>> UTF-8.
>
> In which case it is not a font problem,

Yes, it is.  The characters are not all of the same width.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

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

[Lars Ingebrigtsen]

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Lars Ingebrigtsen]

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

As Andreas says, it's basically a font problem.  Here's how it's
displayed in Emacs:


[-- Attachment #2: Type: image/png, Size: 34603 bytes --]

[-- Attachment #3: Type: text/plain, Size: 32 bytes --]


And here it is in a terminal:


[-- Attachment #4: Type: image/png, Size: 27472 bytes --]

[-- Attachment #5: Type: text/plain, Size: 265 bytes --]


The rounded W-like character is wider than the other characters, making
the line take up two visual lines, which then makes all the line
computations go awry.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Eli Zaretskii <eliz@gnu.org>,  bugs@gnu.support,  44664@debbugs.gnu.org
> Date: Wed, 18 Nov 2020 09:45:00 +0100
> 
> As Andreas says, it's basically a font problem.

Hmm...?

> Here's how it's displayed in Emacs:

Oh, you two were talking about the original screenshot presented in
this bug?  I was talking about the last one, where I cannot see any
wide characters, only octal escapes.

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.

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

[Eli Zaretskii]

> 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?

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.

> 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.

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

[Jean Louis]

[-- 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 --]

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

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> 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?

You mean term.el?  Yes -- since it's emulating a terminal, and terminals
require (I think?) that all glyphs are multiples of each other
width-wise, term.el should do something about glyphs that Emacs doesn't
display in the same width.  I don't know what, though -- display a �
character instead?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: schwab@linux-m68k.org,  bugs@gnu.support,  44664@debbugs.gnu.org
> Date: Wed, 18 Nov 2020 22:04:34 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > 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?
> 
> You mean term.el?

No, I meant mutt.

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

[Andreas Schwab]

On Nov 18 2020, Lars Ingebrigtsen wrote:

> I don't know what, though -- display a � character instead?

But mutt already does that.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

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

[Eli Zaretskii]

> Date: Wed, 18 Nov 2020 23:06:30 +0300
> From: Jean Louis <bugs@gnu.support>
> Cc: larsi@gnus.org, schwab@linux-m68k.org, 44664@debbugs.gnu.org
> 
> I have been searching to find references:
> 
> https://github.com/jquast/wcwidth
> 
> https://github.com/streamlink/streamlink/pull/2032

This is not relevant, Emacs has this data as well.  But since you are
running a GUI session, the width of characters is not what's
important; what's important is the width of the font glyphs that Emacs
uses to display the non-ASCII characters in the term buffer.

> 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.

First, start by trying this in "emacs -Q", to make sure it isn't due
to some customizations of yours.  Then, to see what fonts are used for
the "unusual" characters, use

  M-: (font-at POS) RET

where POS is the buffer position of the offending character.
Alternatively, go to the character and type "C-u C-x =", it will pop
up a buffer with a lot of information including the font.

My guess is that Emacs uses a font other than the default for those
problematic 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.

There's no magic here.  Xterm uses the same -misc-fixed-medium font
that Emacs does, at least by default.  It is possible that you or
someone else (the distribution managers?) provided X resources for
xterm that configure it in some optimal way by specifying fixed-pitch
fonts for some non-ASCII scripts, so I would suggest to look at
.Xdefaults and other sources of X resources and customizations; you
could then use that information in Emacs, because Emacs supports
similar font customization features.

You could also try running term.el in a -nw session inside the same
xterm, to see if there is a difference -- in that case, Emacs doesn't
control the fonts at all.

> 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.

Again, what are the two fonts used in this screenshot?  Use the
above-mentioned techniques to tell, and use "emacs -Q" to eliminate
the possibility that it's due to your customizations.

Also, do you have the LS_COLORS environment variable set, and if so,
what is its value?

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

[Eli Zaretskii]

> Date: Thu, 19 Nov 2020 18:11:19 +0300
> From: Jean Louis <bugs@gnu.support>
> Cc: larsi@gnus.org, schwab@linux-m68k.org, 44664@debbugs.gnu.org
> 
> >   M-: (font-at POS) RET
> > 
> > where POS is the buffer position of the offending character.
> > Alternatively, go to the character and type "C-u C-x =", it will pop
> > up a buffer with a lot of information including the font.
> 
> The default font probably chosen by Emacs at the same point where
> there was that one char I think it is making problems is this one:
> 
> #<font-object "-GNU #-FreeMono-normal-normal-normal-*-15-*-*-*-m-0-iso10646-1"

And this is different from the font used for, say, ASCII characters?

> Otherwise you may see 2 attached screenshots. First screenshot will
> show condition "before" as that is when I yet did not come to
> allegedly offending characters. There is one line for message of
> Thien-Thi
> 
> What one DOES NOT SEE is that there is actually another invisible
> line, now shown there. I can see it in mutt in xterm, you can find it
> under "Web spy" and before "Thien-Thi". That line is not shown in mutt
> under M-x term, until I come with the mutt highlighted line to it.
> 
> The line is from 2002-03-09 - as I said it cannot be seen.

That mbox file has several email messages where the encoding is either
wrongly declared or is not recognized by mutt.  That's a different
problem, unrelated to term.el and its handling of fonts.

> Then that line shows itself and I can see some replaced characters and
> I can see this character not replaced with that circled ?. It is just
> perception that this character and maybe others are not properly
> interpreted by the terminal or fonts.
> 
>              position: 2833 of 7081 (40%), column: 52
>             character:  (displayed as ) (codepoint 60531, #o166163, #xec73)
>               charset: unicode (Unicode (ISO10646))
> code point in charset: 0xEC73
>                syntax: w 	which means: word
>              category: L:Left-to-right (strong)
>              to input: type "C-x 8 RET ec73"
>           buffer code: #xEE #xB1 #xB3
>             file code: #xEE #xB1 #xB3 (encoded by coding system utf-8-unix)
>               display: no font available
> 
> Character code properties: customize what to show
>   general-category: Co (Other, Private Use)
>   decomposition: (60531) ('')

This is a PUA character, another separate issue (Emacs doesn't expect
to see such characters in human-readable text, and cannot display them
without special tinkering with font setup).

Finally, I don't know what byte sequences did mutt send to the
terminal, it is possible that some problems you see are because
term.el is unable to interpret some sequences that mutt assumes to be
supported.  (What termcap/terminfo entry did you use in that shell,
which tells mutt what commands to send?)

Bottom line, I'm no longer sure which problems we are discussing here,
since we have several unrelated issues involved.  Please consider
separating the issues.

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

[Jean Louis]

* Eli Zaretskii <eliz@gnu.org> [2020-11-19 19:16]:
> > #<font-object "-GNU #-FreeMono-normal-normal-normal-*-15-*-*-*-m-0-iso10646-1"
> 
> And this is different from the font used for, say, ASCII characters?

No, same font is appearing everywhere.

> > Otherwise you may see 2 attached screenshots. First screenshot will
> > show condition "before" as that is when I yet did not come to
> > allegedly offending characters. There is one line for message of
> > Thien-Thi
> > 
> > What one DOES NOT SEE is that there is actually another invisible
> > line, now shown there. I can see it in mutt in xterm, you can find it
> > under "Web spy" and before "Thien-Thi". That line is not shown in mutt
> > under M-x term, until I come with the mutt highlighted line to it.
> > 
> > The line is from 2002-03-09 - as I said it cannot be seen.
> 
> That mbox file has several email messages where the encoding is either
> wrongly declared or is not recognized by mutt.  That's a different
> problem, unrelated to term.el and its handling of fonts.

I do understand to a degree. I am pointing to the fact that mutt
handles those characters and in external terminal emulators it looks
just fine. 

> > Then that line shows itself and I can see some replaced characters and
> > I can see this character not replaced with that circled ?. It is just
> > perception that this character and maybe others are not properly
> > interpreted by the terminal or fonts.
> > 
> >              position: 2833 of 7081 (40%), column: 52
> >             character:  (displayed as ) (codepoint 60531, #o166163, #xec73)
> >               charset: unicode (Unicode (ISO10646))
> > code point in charset: 0xEC73
> >                syntax: w 	which means: word
> >              category: L:Left-to-right (strong)
> >              to input: type "C-x 8 RET ec73"
> >           buffer code: #xEE #xB1 #xB3
> >             file code: #xEE #xB1 #xB3 (encoded by coding system utf-8-unix)
> >               display: no font available
> > 
> > Character code properties: customize what to show
> >   general-category: Co (Other, Private Use)
> >   decomposition: (60531) ('')
> 
> This is a PUA character, another separate issue (Emacs doesn't expect
> to see such characters in human-readable text, and cannot display them
> without special tinkering with font setup).

OK, I wish I could help more.

> Finally, I don't know what byte sequences did mutt send to the
> terminal, it is possible that some problems you see are because
> term.el is unable to interpret some sequences that mutt assumes to be
> supported.  (What termcap/terminfo entry did you use in that shell,
> which tells mutt what commands to send?)

I think those are set by M-x terminal

$ echo $TERM
eterm-color
~
$ echo $TERMINFO 
/package/text/emacs/share/emacs/28.0.50/etc/
~
$ echo $TERMCAP 
eterm-color:li#28:co#97:cl=\E[H\E[J:cd=\E[J:bs:am:xn:cm=\E[%i%d;%dH:nd=\E[C:up=\E[A:ce=\E[K:ho=\E[H:pt:al=\E[L:dl=\E[M:DL=\E[%dM:AL=\E[%dL:cs=\E[%i%d;%dr:sf=^J:dc=\E[P:DC=\E[%dP:IC=\E[%d@:im=\E[4h:ei=\E[4l:mi::so=\E[7m:se=\E[m:us=\E[4m:ue=\E[m:md=\E[1m:mr=\E[7m:me=\E[m:UP=\E[%dA:DO=\E[%dB:LE=\E[%dD:RI=\E[%dC:kl=\EOD:kd=\EOB:kr=\EOC:ku=\EOA:kN=\E[6~:kP=\E[5~:@7=\E[4~:kh=\E[1~:mk=\E[8m:cb=\E[1K:op=\E[39;49m:Co#8:pa#64:AB=\E[4%dm:AF=\E[3%dm:cr=^M:bl=^G:do=^J:le=^H:ta=^I:se=\E[27m:ue=\E[24m:kb=^?:kD=^[[3~:sc=\E7:rc=\E8:r1=\Ec:

> Bottom line, I'm no longer sure which problems we are discussing here,
> since we have several unrelated issues involved.  Please consider
> separating the issues.

I wish that lines are correctly displayed on terminal emulator screen,
that is the sole subject.

But now I have idea, let me answer in few minutes.

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

[Jean Louis]

If I do following with X or with -nw:

$ export TERM=eterm

then I can use terminal and the line is not disappearing, it is black
white but it works well. In that case arrows do not work, but I can
use jk instead and other keys.

Does that maybe mean that some color control sequences are not handled
correctly?

Maybe it is not about fonts.

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

[Eli Zaretskii]

> Date: Thu, 19 Nov 2020 19:38:04 +0300
> From: Jean Louis <bugs@gnu.support>
> Cc: larsi@gnus.org, schwab@linux-m68k.org, 44664@debbugs.gnu.org
> 
> * Eli Zaretskii <eliz@gnu.org> [2020-11-19 19:16]:
> > > #<font-object "-GNU #-FreeMono-normal-normal-normal-*-15-*-*-*-m-0-iso10646-1"
> > 
> > And this is different from the font used for, say, ASCII characters?
> 
> No, same font is appearing everywhere.

And it is the same font as the one used by xterm?

> > > The line is from 2002-03-09 - as I said it cannot be seen.
> > 
> > That mbox file has several email messages where the encoding is either
> > wrongly declared or is not recognized by mutt.  That's a different
> > problem, unrelated to term.el and its handling of fonts.
> 
> I do understand to a degree. I am pointing to the fact that mutt
> handles those characters and in external terminal emulators it looks
> just fine. 

AFAICT, mutt sent some of the characters to Emacs as U+FFFD
REPLACEMENT CHARACTER, so "just fine" is not what I'd call that.

Again, this is unrelated to the issue of alignment of columnar display
in term.el.

> > Bottom line, I'm no longer sure which problems we are discussing here,
> > since we have several unrelated issues involved.  Please consider
> > separating the issues.
> 
> I wish that lines are correctly displayed on terminal emulator screen,
> that is the sole subject.

My point is that "incorrect display" can be caused by several
unrelated problems.

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

[Eli Zaretskii]

> Date: Thu, 19 Nov 2020 19:53:02 +0300
> From: Jean Louis <bugs@gnu.support>
> Cc: larsi@gnus.org, schwab@linux-m68k.org, 44664@debbugs.gnu.org
> 
> If I do following with X or with -nw:
> 
> $ export TERM=eterm
> 
> then I can use terminal and the line is not disappearing, it is black
> white but it works well. In that case arrows do not work, but I can
> use jk instead and other keys.
> 
> Does that maybe mean that some color control sequences are not handled
> correctly?

Could be.  Are colors the only difference between eterm and
eterm-color?

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

[Jean Louis]

* Eli Zaretskii <eliz@gnu.org> [2020-11-19 20:29]:
> > Date: Thu, 19 Nov 2020 19:53:02 +0300
> > From: Jean Louis <bugs@gnu.support>
> > Cc: larsi@gnus.org, schwab@linux-m68k.org, 44664@debbugs.gnu.org
> > 
> > If I do following with X or with -nw:
> > 
> > $ export TERM=eterm
> > 
> > then I can use terminal and the line is not disappearing, it is black
> > white but it works well. In that case arrows do not work, but I can
> > use jk instead and other keys.
> > 
> > Does that maybe mean that some color control sequences are not handled
> > correctly?
> 
> Could be.  Are colors the only difference between eterm and
> eterm-color?

For now I see that arrows do not work as expected. They work in
prompt, not in mutt as arrows. Function keys are anyway not bound in
M-x term or ansi-term to terminal, but to Emacs.

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

[Eli Zaretskii]

> Date: Thu, 19 Nov 2020 20:41:32 +0300
> From: Jean Louis <bugs@gnu.support>
> Cc: larsi@gnus.org, schwab@linux-m68k.org, 44664@debbugs.gnu.org
> 
> For now I see that arrows do not work as expected. They work in
> prompt, not in mutt as arrows.

I think this is covered in the commentary section of term.el.

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

[Lars Ingebrigtsen]

Andreas Schwab <schwab@linux-m68k.org> writes:

>> I don't know what, though -- display a � character instead?
>
> But mutt already does that.

It only does that for the invalid utf-8, not for the Ѿ character, which
is the problem here.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> > 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?
>> 
>> You mean term.el?
>
> No, I meant mutt.

mutt is not a Lisp program, so I don't know what you mean here.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: schwab@linux-m68k.org,  bugs@gnu.support,  44664@debbugs.gnu.org
> Date: Thu, 19 Nov 2020 22:07:42 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> > 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?
> >> 
> >> You mean term.el?
> >
> > No, I meant mutt.
> 
> mutt is not a Lisp program, so I don't know what you mean here.

I thought it was, sorry.

So if this is the case, then I think the only way we can reasonably
improve the situation in this area is to have a more elaborate font
setup.  It would be good to know what font is used by terminal
emulators, like xterm or rxvt, in these cases, so we could see if we
could use the same font setup.

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

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> So if this is the case, then I think the only way we can reasonably
> improve the situation in this area is to have a more elaborate font
> setup.  It would be good to know what font is used by terminal
> emulators, like xterm or rxvt, in these cases, so we could see if we
> could use the same font setup.

Yup.  I'm using Terminal under Debian, and it's finding a font to use
here where "Ѿ" is the same width as "x", which ideally Emacs should also
do in term-mode windows.  But I've never even looked at the font
machinery, so I have no useful input here...

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: schwab@linux-m68k.org,  bugs@gnu.support,  44664@debbugs.gnu.org
> Date: Tue, 24 Nov 2020 06:58:58 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > So if this is the case, then I think the only way we can reasonably
> > improve the situation in this area is to have a more elaborate font
> > setup.  It would be good to know what font is used by terminal
> > emulators, like xterm or rxvt, in these cases, so we could see if we
> > could use the same font setup.
> 
> Yup.  I'm using Terminal under Debian, and it's finding a font to use
> here where "Ѿ" is the same width as "x", which ideally Emacs should also
> do in term-mode windows.

Can you tell which font(s) does Terminal use for non-Latin characters,
such as the one above?  Maybe we could learn something from that.

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

[Lars Ingebrigtsen]

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

Eli Zaretskii <eliz@gnu.org> writes:

> Can you tell which font(s) does Terminal use for non-Latin characters,
> such as the one above?  Maybe we could learn something from that.

The gnome-terminal interface claims to be using "Monospace", which is a
font that fc-list says doesn't exist on my system, so I don't really
know what's up with that.

But I was just experimenting a bit, and I wondered how you can force
Emacs into using a specific font for some text.  The following does not
work:

(insert (propertize "fooѾx" 'face '(:family "Futura")))

Now, that font doesn't have the Ѿ glyph, so I'd expect Emacs to tofu
that character, but instead it renders it using DejaVu Sans?

Anyway, I found a mono font on my system with full coverage:

(insert (propertize "fooѾx" 'face '(:family "Noto Sans Mono")))

This renders all these characters with equal width, but using it in the
test case also fails, because amusingly enough, the tofu character it
uses isn't monospaced:


[-- Attachment #2: Type: image/png, Size: 8819 bytes --]

[-- Attachment #3: Type: text/plain, Size: 119 bytes --]


So that's a font that advertises itself as monospaced, but isn't really.

Let's see..  Oh, there's also "Noto Mono":


[-- Attachment #4: Type: image/png, Size: 22258 bytes --]

[-- Attachment #5: Type: text/plain, Size: 666 bytes --]


Success!  With this font, the test case in this bug report works fine:
There are no display glitches when running mutt under term.

But as you can see, this isn't really monospaced, either -- the tofu
glyphs here are narrower than the other glyphs.  And...  hang on --
there's still some glitches, but they are much smaller than before.

I've tried a couple more monospaced fonts, but none seem to have full
coverage.

I'm starting to wonder whether gnome-terminal is just faking the
monospaceness?  That is -- if the glyph is too wide, it's just narrowing
it?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Andreas Schwab]

On Nov 25 2020, Lars Ingebrigtsen wrote:

> The gnome-terminal interface claims to be using "Monospace", which is a
> font that fc-list says doesn't exist on my system, so I don't really
> know what's up with that.

It's an alias, see /etc/fonts/fonts.conf.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

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

[Lars Ingebrigtsen]

Andreas Schwab <schwab@linux-m68k.org> writes:

> On Nov 25 2020, Lars Ingebrigtsen wrote:
>
>> The gnome-terminal interface claims to be using "Monospace", which is a
>> font that fc-list says doesn't exist on my system, so I don't really
>> know what's up with that.
>
> It's an alias, see /etc/fonts/fonts.conf.

Hm...  the only mention of "monospace" I can find there is a mapping
from "mono" to "monospace"?

 Accept deprecated 'mono' alias, replacing it with 'monospace'
-->
        <match target="pattern">
                <test qual="any" name="family">
                        <string>mono</string>
                </test>
                <edit name="family" mode="assign" binding="same">
                        <string>monospace</string>
                </edit>
        </match>


-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Basil L. Contovounesios]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Andreas Schwab <schwab@linux-m68k.org> writes:
>
>> On Nov 25 2020, Lars Ingebrigtsen wrote:
>>
>>> The gnome-terminal interface claims to be using "Monospace", which is a
>>> font that fc-list says doesn't exist on my system, so I don't really
>>> know what's up with that.
>>
>> It's an alias, see /etc/fonts/fonts.conf.
>
> Hm...  the only mention of "monospace" I can find there is a mapping
> from "mono" to "monospace"?

What does 'fc-match mono' give you?

IIUC it should tell you what "monospace", i.e. Fontconfig's default
monospaced font, is aliased to.

-- 
Basil

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

[Andreas Schwab]

On Nov 25 2020, Lars Ingebrigtsen wrote:

> Andreas Schwab <schwab@linux-m68k.org> writes:
>
>> On Nov 25 2020, Lars Ingebrigtsen wrote:
>>
>>> The gnome-terminal interface claims to be using "Monospace", which is a
>>> font that fc-list says doesn't exist on my system, so I don't really
>>> know what's up with that.
>>
>> It's an alias, see /etc/fonts/fonts.conf.
>
> Hm...  the only mention of "monospace" I can find there is a mapping
> from "mono" to "monospace"?

You need to search all included files.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

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

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: schwab@linux-m68k.org,  bugs@gnu.support,  44664@debbugs.gnu.org
> Date: Wed, 25 Nov 2020 07:55:13 +0100
> 
> But I was just experimenting a bit, and I wondered how you can force
> Emacs into using a specific font for some text.  The following does not
> work:
> 
> (insert (propertize "fooѾx" 'face '(:family "Futura")))
> 
> Now, that font doesn't have the Ѿ glyph, so I'd expect Emacs to tofu
> that character, but instead it renders it using DejaVu Sans?

This is a subtlety of the Emacs handling of faces: the font part of
the face spec only specifies the font for ASCII characters.  When
Emacs needs to display non-ASCII characters, it internally creates a
new face, which is based on the ASCII face, but uses a different font
if necessary.  Those internally-created faces aren't visible from
Lisp, but you can see them in the frame's face cache and in the glyph
matrices.

> But as you can see, this isn't really monospaced, either -- the tofu
> glyphs here are narrower than the other glyphs.  And...  hang on --
> there's still some glitches, but they are much smaller than before.
> 
> I've tried a couple more monospaced fonts, but none seem to have full
> coverage.
> 
> I'm starting to wonder whether gnome-terminal is just faking the
> monospaceness?  That is -- if the glyph is too wide, it's just narrowing
> it?

Maybe.  We can do that as well, btw.  We already do something like
that with fonts that declare too large height for its character
glyphs: we override that with a reasonable value.  We could do
something similar for the width, conditioned on some buffer-local
variable.  The relative complexity of this wrt what terminal emulators
do is that terminal emulators can do that always, whereas Emacs cannot
do that by default, it must be an opt-in feature requested by the
likes of term.el.

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

[Lars Ingebrigtsen]

"Basil L. Contovounesios" <contovob@tcd.ie> writes:

> What does 'fc-match mono' give you?

larsi@xo:~/src/emacs/trunk$ fc-match mono
DejaVuSansMono.ttf: "DejaVu Sans Mono" "Book"

> IIUC it should tell you what "monospace", i.e. Fontconfig's default
> monospaced font, is aliased to.

Right.  Emacs still chooses to display Ѿ in DejaVu Sans (without the
Mono), presumably because DejaVu Sans Mono doesn't have that character?
Is there a way to query the font to see what characters it has coverage
for?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Maybe.  We can do that as well, btw.  We already do something like
> that with fonts that declare too large height for its character
> glyphs: we override that with a reasonable value.  We could do
> something similar for the width, conditioned on some buffer-local
> variable.  The relative complexity of this wrt what terminal emulators
> do is that terminal emulators can do that always, whereas Emacs cannot
> do that by default, it must be an opt-in feature requested by the
> likes of term.el.

Yes.

Hm...  actually, that sounds like a pretty good feature in general for
all modes that expect columnar output, doesn't it?  That is, being able
to snap all glyphs to an integer multiple of the standard character
width?  That is, add padding if the width is more than 0.5 wider than
the standard width and narrow the glyph if it's less?  (Whether to only
narrow could also be an option.)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Andreas Schwab]

On Nov 26 2020, Lars Ingebrigtsen wrote:

> Is there a way to query the font to see what characters it has coverage
> for?

Try xfd.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

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

[Lars Ingebrigtsen]

Andreas Schwab <schwab@linux-m68k.org> writes:

> On Nov 26 2020, Lars Ingebrigtsen wrote:
>
>> Is there a way to query the font to see what characters it has coverage
>> for?
>
> Try xfd.

Thanks.  That's rather hard to use if you're looking for a specific
character, though -- is there something that will just dump all the
Unicode names (or code points)?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Robert Pluim]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Andreas Schwab <schwab@linux-m68k.org> writes:
>
>> On Nov 26 2020, Lars Ingebrigtsen wrote:
>>
>>> Is there a way to query the font to see what characters it has coverage
>>> for?
>>
>> Try xfd.
>
> Thanks.  That's rather hard to use if you're looking for a specific
> character, though -- is there something that will just dump all the
> Unicode names (or code points)?

Something like this:

ttfdump -t cmap /usr/share/fonts/truetype/dejavu/DejaVuSansMono.ttf|grep -w Char

ttfdump -s part of texlive

Robert

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

[Lars Ingebrigtsen]

Robert Pluim <rpluim@gmail.com> writes:

> Something like this:
>
> ttfdump -t cmap /usr/share/fonts/truetype/dejavu/DejaVuSansMono.ttf|grep -w Char
>
> ttfdump -s part of texlive

Thanks!  The char is 0x047e, and Sans Mono indeed doesn't have it:

                Char 0x045f -> Index 926
                Char 0x0462 -> Index 927
                Char 0x0463 -> Index 928
                Char 0x0472 -> Index 929
                Char 0x0473 -> Index 930
                Char 0x0490 -> Index 931

So presumably gnome-terminal is fetching the glyph from somewhere else
and then massaging it into the appropriate size.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: schwab@linux-m68k.org,  bugs@gnu.support,  44664@debbugs.gnu.org
> Date: Thu, 26 Nov 2020 10:50:57 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Maybe.  We can do that as well, btw.  We already do something like
> > that with fonts that declare too large height for its character
> > glyphs: we override that with a reasonable value.  We could do
> > something similar for the width, conditioned on some buffer-local
> > variable.  The relative complexity of this wrt what terminal emulators
> > do is that terminal emulators can do that always, whereas Emacs cannot
> > do that by default, it must be an opt-in feature requested by the
> > likes of term.el.
> 
> Yes.
> 
> Hm...  actually, that sounds like a pretty good feature in general for
> all modes that expect columnar output, doesn't it?

Any feature that displays text in a tabular form, or otherwise needs
arbitrary text to align, yes.

> That is, being able to snap all glyphs to an integer multiple of the
> standard character width?  That is, add padding if the width is more
> than 0.5 wider than the standard width and narrow the glyph if it's
> less?  (Whether to only narrow could also be an option.)

I think ideally we should make each character as wide as char-width
says it should be, because a well-behaved text-mode application is
supposed to arrange text according to that.  It should be easy to do
that, but I'm afraid we will bump into characters whose char-width is
1, but which are much wider on display.  I don't know what to do in
that case.

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

[Basil L. Contovounesios]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Right.  Emacs still chooses to display Ѿ in DejaVu Sans (without the
> Mono), presumably because DejaVu Sans Mono doesn't have that character?
> Is there a way to query the font to see what characters it has coverage
> for?

FWIW, you could also ask the opposite question:

$ fc-list :charset=47e | grep -ci 'deja.*sans'
8
$ ^sans^mono^
fc-list :charset=47e | grep -ci 'deja.*mono'
0

-- 
Basil

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

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> I think ideally we should make each character as wide as char-width
> says it should be, because a well-behaved text-mode application is
> supposed to arrange text according to that.

Ah, right, yes -- looking at the mutt example, the Korean characters are
(exactly) double width, so that seems like the way to go.

> It should be easy to do that, but I'm afraid we will bump into
> characters whose char-width is 1, but which are much wider on display.
> I don't know what to do in that case.

You mean they are so wide that compressing them will make them illegible?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Lars Ingebrigtsen]

"Basil L. Contovounesios" <contovob@tcd.ie> writes:

> FWIW, you could also ask the opposite question:
>
> $ fc-list :charset=47e | grep -ci 'deja.*sans'
> 8
> $ ^sans^mono^
> fc-list :charset=47e | grep -ci 'deja.*mono'
> 0

Ah, thanks; that's very useful.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: schwab@linux-m68k.org,  bugs@gnu.support,  44664@debbugs.gnu.org
> Date: Fri, 27 Nov 2020 08:51:31 +0100
> 
> > It should be easy to do that, but I'm afraid we will bump into
> > characters whose char-width is 1, but which are much wider on display.
> > I don't know what to do in that case.
> 
> You mean they are so wide that compressing them will make them illegible?

I don't know how to "compress" glyphs, actually.  I hoped that we can
get away with just "padding", which boils down to enlarging their
width metrics.  But if we need to make the width significantly smaller
than the font glyph font says, I don't know what would be the effect
of that, and I have no idea how to "shrink" a glyph on display.

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

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> You mean they are so wide that compressing them will make them illegible?
>
> I don't know how to "compress" glyphs, actually.  I hoped that we can
> get away with just "padding", which boils down to enlarging their
> width metrics.  But if we need to make the width significantly smaller
> than the font glyph font says, I don't know what would be the effect
> of that, and I have no idea how to "shrink" a glyph on display.

Oh, I thought you said that we shrink some glyphs vertically already?

I imagined shrinking the width of a glyph would mean just throwing away
some vertical lines, or specify a transformation matrix, or something.
(I have not looked at the code, as you can tell.)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: schwab@linux-m68k.org,  bugs@gnu.support,  44664@debbugs.gnu.org
> Date: Sun, 29 Nov 2020 10:58:16 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> You mean they are so wide that compressing them will make them illegible?
> >
> > I don't know how to "compress" glyphs, actually.  I hoped that we can
> > get away with just "padding", which boils down to enlarging their
> > width metrics.  But if we need to make the width significantly smaller
> > than the font glyph font says, I don't know what would be the effect
> > of that, and I have no idea how to "shrink" a glyph on display.
> 
> Oh, I thought you said that we shrink some glyphs vertically already?

No, we just override the metrics, which claims unreasonably large
height.  The glyphs themselves are not as tall as the metrics says.

> I imagined shrinking the width of a glyph would mean just throwing away
> some vertical lines, or specify a transformation matrix, or something.
> (I have not looked at the code, as you can tell.)

We can easily clip the glyph, yes.  I don't know how legible will the
result be.  Transformation matrices is not something I'd love to use
here.

Eventually, we need to see how many characters, if any, exhibit this
problem.  Maybe the issue is minor.

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

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> I imagined shrinking the width of a glyph would mean just throwing away
>> some vertical lines, or specify a transformation matrix, or something.
>> (I have not looked at the code, as you can tell.)
>
> We can easily clip the glyph, yes.  I don't know how legible will the
> result be.  Transformation matrices is not something I'd love to use
> here.
>
> Eventually, we need to see how many characters, if any, exhibit this
> problem.  Maybe the issue is minor.

I think in this test case, with the Ѿ character coming from DejaVu Sans
(while the other characters come from DejaVu Sans Mono), the results of
just clipping will be kinda ugly.  But it's worth a shot and see how it
looks in practice -- perhaps it'll be good enough.

I really wonder what gnome-terminal is really doing here.  I downloaded
the sources, but it looks like all the magic happens down in the Pango
libraries.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: schwab@linux-m68k.org,  bugs@gnu.support,  44664@debbugs.gnu.org
> Date: Mon, 30 Nov 2020 11:05:10 +0100
> 
> I really wonder what gnome-terminal is really doing here.  I downloaded
> the sources, but it looks like all the magic happens down in the Pango
> libraries.

Does xterm also solve this problem?  If so, you may wish looking into
its sources, they are more or less stand-alone, AFAIR.

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

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Does xterm also solve this problem?  If so, you may wish looking into
> its sources, they are more or less stand-alone, AFAIR.

Yup.  However, 

xterm -fn fixed
emacs -fn fixed

displays two very different-looking fonts, so I don't know what's up
with that...

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: schwab@linux-m68k.org,  bugs@gnu.support,  44664@debbugs.gnu.org
> Date: Wed, 02 Dec 2020 10:39:08 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Does xterm also solve this problem?  If so, you may wish looking into
> > its sources, they are more or less stand-alone, AFAIR.
> 
> Yup.  However, 
> 
> xterm -fn fixed
> emacs -fn fixed
> 
> displays two very different-looking fonts, so I don't know what's up
> with that...

Is there no way of finding out which font xterm uses in this case?
Perhaps by running it under strace and looking for font files it
opens?

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

[Jean Louis]

* Eli Zaretskii <eliz@gnu.org> [2020-12-02 18:03]:
> > From: Lars Ingebrigtsen <larsi@gnus.org>
> > Cc: schwab@linux-m68k.org,  bugs@gnu.support,  44664@debbugs.gnu.org
> > Date: Wed, 02 Dec 2020 10:39:08 +0100
> > 
> > Eli Zaretskii <eliz@gnu.org> writes:
> > 
> > > Does xterm also solve this problem?  If so, you may wish looking into
> > > its sources, they are more or less stand-alone, AFAIR.
> > 
> > Yup.  However, 
> > 
> > xterm -fn fixed
> > emacs -fn fixed
> > 
> > displays two very different-looking fonts, so I don't know what's up
> > with that...

appres XTerm | grep -i font

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

[Lars Ingebrigtsen]

Jean Louis <bugs@gnu.support> writes:

> appres XTerm | grep -i font

It outputs a lot of stuff:

$ appres XTerm | grep -i font  | wc -l
48

I'm not sure how to pick out from that data what font xterm is actually
using.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Jean Louis]

* Lars Ingebrigtsen <larsi@gnus.org> [2020-12-03 11:44]:
> Jean Louis <bugs@gnu.support> writes:
> 
> > appres XTerm | grep -i font
> 
> It outputs a lot of stuff:
> 
> $ appres XTerm | grep -i font  | wc -l
> 48
> 
> I'm not sure how to pick out from that data what font xterm is actually
> using.

If you are using default font:

appres XTerm | grep -i font | grep -i default

and then you can see which one is default by:

xterm -report-fonts | more

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

[Lars Ingebrigtsen]

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

Jean Louis <bugs@gnu.support> writes:

> and then you can see which one is default by:
>
> xterm -report-fonts | more

Thanks.

xterm --misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso10646-16-1
./src/emacs -fn -misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso10646-1

I now get the same font, I think:


[-- Attachment #2: Type: image/png, Size: 34460 bytes --]

[-- Attachment #3: Type: text/plain, Size: 243 bytes --]


But obviously xterm is doing something more here, since Emacs just
displays a lot of "?" instead of the tofu and the Ѿ character.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Eli Zaretskii <eliz@gnu.org>,  schwab@linux-m68k.org,
>   44664@debbugs.gnu.org
> Date: Thu, 03 Dec 2020 09:44:13 +0100
> 
> Jean Louis <bugs@gnu.support> writes:
> 
> > appres XTerm | grep -i font
> 
> It outputs a lot of stuff:
> 
> $ appres XTerm | grep -i font  | wc -l
> 48

48 lines is not too much; how about showing all of them?

> I'm not sure how to pick out from that data what font xterm is actually
> using.

We could ask Thomas Dickey to help us out here.

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

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Eli Zaretskii <eliz@gnu.org>,  schwab@linux-m68k.org,
>   44664@debbugs.gnu.org
> Date: Thu, 03 Dec 2020 10:02:13 +0100
> 
> > xterm -report-fonts | more
> 
> Thanks.
> 
> xterm --misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso10646-16-1
> ./src/emacs -fn -misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso10646-1
> 
> I now get the same font, I think:
> 
> But obviously xterm is doing something more here, since Emacs just
> displays a lot of "?" instead of the tofu and the Ѿ character.

Which, together with the fact that we display ??? instead of the
Chinese text probably means that xterm uses a font that is not the
default one there.

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

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> 48 lines is not too much; how about showing all of them?

Here they are:

*fontMenu*font-loadable*Label:	VT220 Soft Fonts
*fontMenu*font5*Label:	Large
*fontMenu*allow-mouse-ops*Label:	Allow Mouse Ops
*fontMenu*font-packed*Label:	Packed Font
*fontMenu*fontdefault*Label:	Default
*fontMenu*font6*Label:	Huge
*fontMenu*allow-tcap-ops*Label:	Allow Termcap Ops
*fontMenu*render-font*Label:	TrueType Fonts
*fontMenu*font1*Label:	Unreadable
*fontMenu*font7*Label:	Enormous
*fontMenu*allow-title-ops*Label:	Allow Title Ops
*fontMenu*utf8-mode*Label:	UTF-8 Encoding
*fontMenu*fontescape*Label:	Escape Sequence
*fontMenu*allow-window-ops*Label:	Allow Window Ops
*fontMenu*fontsel*Label:	Selection
*fontMenu*utf8-fonts*Label:	UTF-8 Fonts
*fontMenu*allow-bold-fonts*Label:	Bold Fonts
*fontMenu*font2*Label:	Tiny
*fontMenu*utf8-title*Label:	UTF-8 Titles
*fontMenu*font-linedrawing*Label:	Line-Drawing Characters
*fontMenu*font3*Label:	Small
*fontMenu*allow-color-ops*Label:	Allow Color Ops
*fontMenu*font-doublesize*Label:	Doublesized Characters
*fontMenu*font4*Label:	Medium
*fontMenu*allow-font-ops*Label:	Allow Font Ops
*fontMenu.Label:	VT Fonts
*fontMenu*background:	AntiqueWhite
*fontMenu*foreground:	gray15
*tek4014*fontLarge:	9x15
*tek4014*font2:	8x13
*tek4014*font3:	6x13
*tek4014*fontSmall:	6x10
*VT100.utf8Fonts.font5:	-misc-fixed-medium-r-normal--18-120-100-100-c-90-iso10646-1
*VT100.utf8Fonts.font3:	-misc-fixed-medium-r-normal--14-130-75-75-c-70-iso10646-1
*VT100.utf8Fonts.font:	-misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso10646-1
*VT100.utf8Fonts.font7:	-adobe-courier-medium-r-normal--24-240-75-75-m-150-iso10646-1
*VT100.utf8Fonts.font4:	-misc-fixed-medium-r-normal--13-120-75-75-c-80-iso10646-1
*VT100.utf8Fonts.font2:	-misc-fixed-medium-r-normal--8-80-75-75-c-50-iso10646-1
*VT100.utf8Fonts.font6:	-misc-fixed-medium-r-normal--20-200-75-75-c-100-iso10646-1
*VT100.font5:	9x15
*VT100.font6:	10x20
*VT100.font1:	nil2
*VT100.font7:	-adobe-courier-medium-r-normal--24-240-75-75-m-150-iso10646-1
*VT100.font2:	5x7
*VT100.font3:	6x10
*VT100.font4:	7x13
*SimpleMenu*menuLabel.font:	-adobe-helvetica-bold-r-normal--*-120-*-*-*-*-iso8859-*
*IconFont:	nil2


-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: bugs@gnu.support,  schwab@linux-m68k.org,  44664@debbugs.gnu.org
> Date: Thu, 03 Dec 2020 17:59:48 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > 48 lines is not too much; how about showing all of them?
> 
> Here they are:

Thanks.  I don't think what we are looking for is in that list.