GNU bug report logs -
#44664
28.0.50; troubles with some chars in term
Previous Next
To reply to this bug, email your comments to 44664 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#44664; Package
emacs.
(Sun, 15 Nov 2020 19:46:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Jean Louis <bugs <at> gnu.support>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Sun, 15 Nov 2020 19:46:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
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
⎔ λ 🄯 𝍄 𝌡 𝌚
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#44664; Package
emacs.
(Mon, 16 Nov 2020 22:31:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 44664 <at> debbugs.gnu.org (full text, mbox):
Jean Louis <bugs <at> 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
Added tag(s) confirmed.
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org.
(Mon, 16 Nov 2020 22:31:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#44664; Package
emacs.
(Tue, 17 Nov 2020 06:51:03 GMT)
Full text and
rfc822 format available.
Message #13 received at 44664 <at> debbugs.gnu.org (full text, mbox):
* Lars Ingebrigtsen <larsi <at> gnus.org> [2020-11-17 01:30]:
> Jean Louis <bugs <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#44664; Package
emacs.
(Tue, 17 Nov 2020 09:01:02 GMT)
Full text and
rfc822 format available.
Message #16 received at 44664 <at> debbugs.gnu.org (full text, mbox):
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 <at> linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#44664; Package
emacs.
(Tue, 17 Nov 2020 09:48:02 GMT)
Full text and
rfc822 format available.
Message #19 received at 44664 <at> debbugs.gnu.org (full text, mbox):
* Andreas Schwab <schwab <at> 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?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#44664; Package
emacs.
(Tue, 17 Nov 2020 09:56:01 GMT)
Full text and
rfc822 format available.
Message #22 received at 44664 <at> debbugs.gnu.org (full text, mbox):
On Nov 17 2020, Jean Louis wrote:
> * Andreas Schwab <schwab <at> 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 <at> linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#44664; Package
emacs.
(Tue, 17 Nov 2020 11:39:02 GMT)
Full text and
rfc822 format available.
Message #25 received at 44664 <at> debbugs.gnu.org (full text, mbox):
* Andreas Schwab <schwab <at> linux-m68k.org> [2020-11-17 12:55]:
> On Nov 17 2020, Jean Louis wrote:
>
> > * Andreas Schwab <schwab <at> 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?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#44664; Package
emacs.
(Tue, 17 Nov 2020 15:13:02 GMT)
Full text and
rfc822 format available.
Message #28 received at 44664 <at> debbugs.gnu.org (full text, mbox):
> Date: Tue, 17 Nov 2020 13:00:03 +0300
> From: Jean Louis <bugs <at> gnu.support>
> Cc: 44664 <at> 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?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#44664; Package
emacs.
(Tue, 17 Nov 2020 20:50:02 GMT)
Full text and
rfc822 format available.
Message #31 received at 44664 <at> debbugs.gnu.org (full text, mbox):
* Eli Zaretskii <eliz <at> gnu.org> [2020-11-17 18:13]:
> > Date: Tue, 17 Nov 2020 13:00:03 +0300
> > From: Jean Louis <bugs <at> gnu.support>
> > Cc: 44664 <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#44664; Package
emacs.
(Tue, 17 Nov 2020 21:06:02 GMT)
Full text and
rfc822 format available.
Message #34 received at 44664 <at> debbugs.gnu.org (full text, mbox):
> Date: Tue, 17 Nov 2020 20:15:01 +0300
> From: Jean Louis <bugs <at> gnu.support>
> Cc: schwab <at> linux-m68k.org, 44664 <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#44664; Package
emacs.
(Tue, 17 Nov 2020 21:55:03 GMT)
Full text and
rfc822 format available.
Message #37 received at 44664 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
* Eli Zaretskii <eliz <at> gnu.org> [2020-11-18 00:05]:
> > Date: Tue, 17 Nov 2020 20:15:01 +0300
> > From: Jean Louis <bugs <at> gnu.support>
> > Cc: schwab <at> linux-m68k.org, 44664 <at> 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.
[Screenshot from 2020-11-18 00-52-34.png (image/png, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#44664; Package
emacs.
(Tue, 17 Nov 2020 22:03:02 GMT)
Full text and
rfc822 format available.
Message #40 received at 44664 <at> debbugs.gnu.org (full text, mbox):
On Nov 17 2020, Eli Zaretskii wrote:
>> Date: Tue, 17 Nov 2020 20:15:01 +0300
>> From: Jean Louis <bugs <at> gnu.support>
>> Cc: schwab <at> linux-m68k.org, 44664 <at> 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 <at> linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#44664; Package
emacs.
(Wed, 18 Nov 2020 03:32:01 GMT)
Full text and
rfc822 format available.
Message #43 received at 44664 <at> debbugs.gnu.org (full text, mbox):
> From: Andreas Schwab <schwab <at> linux-m68k.org>
> Cc: Jean Louis <bugs <at> gnu.support>, 44664 <at> 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 <at> gnu.support>
> >> Cc: schwab <at> linux-m68k.org, 44664 <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#44664; Package
emacs.
(Wed, 18 Nov 2020 06:52:02 GMT)
Full text and
rfc822 format available.
Message #46 received at 44664 <at> debbugs.gnu.org (full text, mbox):
* Eli Zaretskii <eliz <at> gnu.org> [2020-11-18 06:31]:
> > From: Andreas Schwab <schwab <at> linux-m68k.org>
> > Cc: Jean Louis <bugs <at> gnu.support>, 44664 <at> 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 <at> gnu.support>
> > >> Cc: schwab <at> linux-m68k.org, 44664 <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#44664; Package
emacs.
(Wed, 18 Nov 2020 08:26:01 GMT)
Full text and
rfc822 format available.
Message #49 received at 44664 <at> debbugs.gnu.org (full text, mbox):
On Nov 18 2020, Eli Zaretskii wrote:
>> From: Andreas Schwab <schwab <at> linux-m68k.org>
>> Cc: Jean Louis <bugs <at> gnu.support>, 44664 <at> 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 <at> gnu.support>
>> >> Cc: schwab <at> linux-m68k.org, 44664 <at> 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 <at> linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#44664; Package
emacs.
(Wed, 18 Nov 2020 08:40:02 GMT)
Full text and
rfc822 format available.
Message #52 received at 44664 <at> debbugs.gnu.org (full text, mbox):
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#44664; Package
emacs.
(Wed, 18 Nov 2020 08:46:01 GMT)
Full text and
rfc822 format available.
Message #55 received at 44664 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
As Andreas says, it's basically a font problem. Here's how it's
displayed in Emacs:
[Message part 2 (image/png, inline)]
[Message part 3 (text/plain, inline)]
And here it is in a terminal:
[Message part 4 (image/png, inline)]
[Message part 5 (text/plain, inline)]
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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#44664; Package
emacs.
(Wed, 18 Nov 2020 15:12:02 GMT)
Full text and
rfc822 format available.
Message #58 received at 44664 <at> debbugs.gnu.org (full text, mbox):
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, bugs <at> gnu.support, 44664 <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#44664; Package
emacs.
(Wed, 18 Nov 2020 17:57:01 GMT)
Full text and
rfc822 format available.
Message #61 received at 44664 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
* Eli Zaretskii <eliz <at> gnu.org> [2020-11-18 18:11]:
> > From: Lars Ingebrigtsen <larsi <at> gnus.org>
> > Cc: Eli Zaretskii <eliz <at> gnu.org>, bugs <at> gnu.support, 44664 <at> 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.
I was thinking you would know how terminals are solving that problem
and that Emacs terminal would be programmed to follow same methods,
only that some functionality is missing.
Those characters are not displayed in any external terminals and I do
not get distorted screen.
My font in XTerm is same as in Emacs, DejaVu Sans Mono.
I am attaching the file to this email that you may try to debug
it. Many people started using the external dynamic module while term
in Emacs is functioning pretty well, it needs just some enhancements.
To open this file, one does:
$ mutt -f 2002-06
[2002-06 (text/plain, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#44664; Package
emacs.
(Wed, 18 Nov 2020 18:15:01 GMT)
Full text and
rfc822 format available.
Message #64 received at 44664 <at> debbugs.gnu.org (full text, mbox):
> Date: Wed, 18 Nov 2020 18:37:13 +0300
> From: Jean Louis <bugs <at> gnu.support>
> Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, schwab <at> linux-m68k.org,
> 44664 <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#44664; Package
emacs.
(Wed, 18 Nov 2020 21:05:02 GMT)
Full text and
rfc822 format available.
Message #67 received at 44664 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#44664; Package
emacs.
(Thu, 19 Nov 2020 03:31:02 GMT)
Full text and
rfc822 format available.
Message #70 received at 44664 <at> debbugs.gnu.org (full text, mbox):
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: schwab <at> linux-m68k.org, bugs <at> gnu.support, 44664 <at> debbugs.gnu.org
> Date: Wed, 18 Nov 2020 22:04:34 +0100
>
> Eli Zaretskii <eliz <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#44664; Package
emacs.
(Thu, 19 Nov 2020 04:56:01 GMT)
Full text and
rfc822 format available.
Message #73 received at 44664 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
* Eli Zaretskii <eliz <at> gnu.org> [2020-11-18 21:14]:
> > Date: Wed, 18 Nov 2020 18:37:13 +0300
> > From: Jean Louis <bugs <at> gnu.support>
> > Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, schwab <at> linux-m68k.org,
> > 44664 <at> 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.
[Screenshot from 2020-11-18 22-53-01.png (image/png, attachment)]
[Screenshot from 2020-11-18 22-57-30.png (image/png, attachment)]
[Screenshot from 2020-11-18 23-03-58.png (image/png, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#44664; Package
emacs.
(Thu, 19 Nov 2020 08:22:02 GMT)
Full text and
rfc822 format available.
Message #76 received at 44664 <at> debbugs.gnu.org (full text, mbox):
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 <at> linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#44664; Package
emacs.
(Thu, 19 Nov 2020 14:28:01 GMT)
Full text and
rfc822 format available.
Message #79 received at 44664 <at> debbugs.gnu.org (full text, mbox):
> Date: Wed, 18 Nov 2020 23:06:30 +0300
> From: Jean Louis <bugs <at> gnu.support>
> Cc: larsi <at> gnus.org, schwab <at> linux-m68k.org, 44664 <at> 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?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#44664; Package
emacs.
(Thu, 19 Nov 2020 15:12:02 GMT)
Full text and
rfc822 format available.
Message #82 received at 44664 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
* Eli Zaretskii <eliz <at> gnu.org> [2020-11-19 17:28]:
> > Date: Wed, 18 Nov 2020 23:06:30 +0300
> > From: Jean Louis <bugs <at> gnu.support>
> > Cc: larsi <at> gnus.org, schwab <at> linux-m68k.org, 44664 <at> 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.
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">
Video on what is happening with `emacs -Q' is here:
https://gnu.support/images/tmp/2020-11-19-17:43:06.ogv
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.
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) ('')
There are text properties here:
font-lock-face (:foreground "white" :background "black" :inverse-video t)
fontified t
> 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.
Now I have eliminated everything that could point to my
customizations, thank you.
I have also run mutt within M-x term under `emacs -nw -Q' and I find
the same problem is there. At first I cannot even see the line with
2002-03-09. When I then go with the highlighted line from 2002-03-07
message beginning with Spy to 2002-03-10 visible message, the visible
message 2002-03-10 changes itself to 2002-03-09 or inserts the
2002-03-09 message, only then comes to some distortions of visibility
and me, I lose confidence if I am on the right message or not on the
right message.
You may find those screenshots attached showing you condition before I
move with the highlighted line over the invisible 2002-03-09 message,
which is shown later.
> Also, do you have the LS_COLORS environment variable set, and if so,
> what is its value?
Before anything I have removed all colors both from ls and mutt and
removed all control sequences from .bashrc and I feel better without
colors (surprisingly).
Side notes:
- mutt handles these messages in xterm without any distortions
- no other terminal I have like mate-terminal, lxterminal, etc. have
any visibility distortion on that character
- character referred here may not be the one causing problems and
multiple characters could be causing problems.
- I was using this file with mutt:
https://lists.gnu.org/archive/mbox/gnu-emacs-sources/2002-03
[1-condition-before.png (image/png, attachment)]
[2-condition-after.png (image/png, attachment)]
[3-xterm.png (image/png, attachment)]
[4-emacs-nw-Q-before.png (image/png, attachment)]
[5-emacs-nw-Q-after.png (image/png, attachment)]
Forcibly Merged 6718 44664.
Request was from
Stefan Kangas <stefan <at> marxist.se>
to
control <at> debbugs.gnu.org.
(Thu, 19 Nov 2020 15:33:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#44664; Package
emacs.
(Thu, 19 Nov 2020 16:17:01 GMT)
Full text and
rfc822 format available.
Message #87 received at 44664 <at> debbugs.gnu.org (full text, mbox):
> Date: Thu, 19 Nov 2020 18:11:19 +0300
> From: Jean Louis <bugs <at> gnu.support>
> Cc: larsi <at> gnus.org, schwab <at> linux-m68k.org, 44664 <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#44664; Package
emacs.
(Thu, 19 Nov 2020 16:54:01 GMT)
Full text and
rfc822 format available.
Message #90 received at 44664 <at> debbugs.gnu.org (full text, mbox):
* Eli Zaretskii <eliz <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#44664; Package
emacs.
(Thu, 19 Nov 2020 16:54:02 GMT)
Full text and
rfc822 format available.
Message #93 received at 44664 <at> debbugs.gnu.org (full text, mbox):
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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#44664; Package
emacs.
(Thu, 19 Nov 2020 17:29:01 GMT)
Full text and
rfc822 format available.
Message #96 received at 44664 <at> debbugs.gnu.org (full text, mbox):
> Date: Thu, 19 Nov 2020 19:38:04 +0300
> From: Jean Louis <bugs <at> gnu.support>
> Cc: larsi <at> gnus.org, schwab <at> linux-m68k.org, 44664 <at> debbugs.gnu.org
>
> * Eli Zaretskii <eliz <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#44664; Package
emacs.
(Thu, 19 Nov 2020 17:29:02 GMT)
Full text and
rfc822 format available.
Message #99 received at 44664 <at> debbugs.gnu.org (full text, mbox):
> Date: Thu, 19 Nov 2020 19:53:02 +0300
> From: Jean Louis <bugs <at> gnu.support>
> Cc: larsi <at> gnus.org, schwab <at> linux-m68k.org, 44664 <at> 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?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#44664; Package
emacs.
(Thu, 19 Nov 2020 17:46:01 GMT)
Full text and
rfc822 format available.
Message #102 received at 44664 <at> debbugs.gnu.org (full text, mbox):
* Eli Zaretskii <eliz <at> gnu.org> [2020-11-19 20:29]:
> > Date: Thu, 19 Nov 2020 19:53:02 +0300
> > From: Jean Louis <bugs <at> gnu.support>
> > Cc: larsi <at> gnus.org, schwab <at> linux-m68k.org, 44664 <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#44664; Package
emacs.
(Thu, 19 Nov 2020 17:57:01 GMT)
Full text and
rfc822 format available.
Message #105 received at 44664 <at> debbugs.gnu.org (full text, mbox):
> Date: Thu, 19 Nov 2020 20:41:32 +0300
> From: Jean Louis <bugs <at> gnu.support>
> Cc: larsi <at> gnus.org, schwab <at> linux-m68k.org, 44664 <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#44664; Package
emacs.
(Thu, 19 Nov 2020 21:08:01 GMT)
Full text and
rfc822 format available.
Message #108 received at 44664 <at> debbugs.gnu.org (full text, mbox):
Andreas Schwab <schwab <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#44664; Package
emacs.
(Thu, 19 Nov 2020 21:08:02 GMT)
Full text and
rfc822 format available.
Message #111 received at 44664 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#44664; Package
emacs.
(Fri, 20 Nov 2020 07:40:01 GMT)
Full text and
rfc822 format available.
Message #114 received at 44664 <at> debbugs.gnu.org (full text, mbox):
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: schwab <at> linux-m68k.org, bugs <at> gnu.support, 44664 <at> debbugs.gnu.org
> Date: Thu, 19 Nov 2020 22:07:42 +0100
>
> Eli Zaretskii <eliz <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#44664; Package
emacs.
(Tue, 24 Nov 2020 06:00:01 GMT)
Full text and
rfc822 format available.
Message #117 received at 44664 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#44664; Package
emacs.
(Tue, 24 Nov 2020 15:34:01 GMT)
Full text and
rfc822 format available.
Message #120 received at 44664 <at> debbugs.gnu.org (full text, mbox):
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: schwab <at> linux-m68k.org, bugs <at> gnu.support, 44664 <at> debbugs.gnu.org
> Date: Tue, 24 Nov 2020 06:58:58 +0100
>
> Eli Zaretskii <eliz <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#44664; Package
emacs.
(Wed, 25 Nov 2020 06:56:01 GMT)
Full text and
rfc822 format available.
Message #123 received at 44664 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Eli Zaretskii <eliz <at> 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:
[Message part 2 (image/png, inline)]
[Message part 3 (text/plain, inline)]
So that's a font that advertises itself as monospaced, but isn't really.
Let's see.. Oh, there's also "Noto Mono":
[Message part 4 (image/png, inline)]
[Message part 5 (text/plain, inline)]
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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#44664; Package
emacs.
(Wed, 25 Nov 2020 08:31:01 GMT)
Full text and
rfc822 format available.
Message #126 received at 44664 <at> debbugs.gnu.org (full text, mbox):
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 <at> linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#44664; Package
emacs.
(Wed, 25 Nov 2020 09:09:01 GMT)
Full text and
rfc822 format available.
Message #129 received at 44664 <at> debbugs.gnu.org (full text, mbox):
Andreas Schwab <schwab <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#44664; Package
emacs.
(Wed, 25 Nov 2020 09:25:01 GMT)
Full text and
rfc822 format available.
Message #132 received at 44664 <at> debbugs.gnu.org (full text, mbox):
Lars Ingebrigtsen <larsi <at> gnus.org> writes:
> Andreas Schwab <schwab <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#44664; Package
emacs.
(Wed, 25 Nov 2020 09:28:02 GMT)
Full text and
rfc822 format available.
Message #135 received at 44664 <at> debbugs.gnu.org (full text, mbox):
On Nov 25 2020, Lars Ingebrigtsen wrote:
> Andreas Schwab <schwab <at> 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 <at> linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#44664; Package
emacs.
(Wed, 25 Nov 2020 15:36:02 GMT)
Full text and
rfc822 format available.
Message #138 received at 44664 <at> debbugs.gnu.org (full text, mbox):
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: schwab <at> linux-m68k.org, bugs <at> gnu.support, 44664 <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#44664; Package
emacs.
(Thu, 26 Nov 2020 09:48:02 GMT)
Full text and
rfc822 format available.
Message #141 received at 44664 <at> debbugs.gnu.org (full text, mbox):
"Basil L. Contovounesios" <contovob <at> tcd.ie> writes:
> What does 'fc-match mono' give you?
larsi <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#44664; Package
emacs.
(Thu, 26 Nov 2020 09:52:02 GMT)
Full text and
rfc822 format available.
Message #144 received at 44664 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#44664; Package
emacs.
(Thu, 26 Nov 2020 10:14:02 GMT)
Full text and
rfc822 format available.
Message #147 received at 44664 <at> debbugs.gnu.org (full text, mbox):
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 <at> linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#44664; Package
emacs.
(Thu, 26 Nov 2020 10:17:01 GMT)
Full text and
rfc822 format available.
Message #150 received at 44664 <at> debbugs.gnu.org (full text, mbox):
Andreas Schwab <schwab <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#44664; Package
emacs.
(Thu, 26 Nov 2020 11:17:01 GMT)
Full text and
rfc822 format available.
Message #153 received at 44664 <at> debbugs.gnu.org (full text, mbox):
Lars Ingebrigtsen <larsi <at> gnus.org> writes:
> Andreas Schwab <schwab <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#44664; Package
emacs.
(Thu, 26 Nov 2020 11:22:01 GMT)
Full text and
rfc822 format available.
Message #156 received at 44664 <at> debbugs.gnu.org (full text, mbox):
Robert Pluim <rpluim <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#44664; Package
emacs.
(Thu, 26 Nov 2020 14:18:02 GMT)
Full text and
rfc822 format available.
Message #159 received at 44664 <at> debbugs.gnu.org (full text, mbox):
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: schwab <at> linux-m68k.org, bugs <at> gnu.support, 44664 <at> debbugs.gnu.org
> Date: Thu, 26 Nov 2020 10:50:57 +0100
>
> Eli Zaretskii <eliz <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#44664; Package
emacs.
(Thu, 26 Nov 2020 21:15:01 GMT)
Full text and
rfc822 format available.
Message #162 received at 44664 <at> debbugs.gnu.org (full text, mbox):
Lars Ingebrigtsen <larsi <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#44664; Package
emacs.
(Fri, 27 Nov 2020 07:52:02 GMT)
Full text and
rfc822 format available.
Message #165 received at 44664 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#44664; Package
emacs.
(Fri, 27 Nov 2020 07:54:02 GMT)
Full text and
rfc822 format available.
Message #168 received at 44664 <at> debbugs.gnu.org (full text, mbox):
"Basil L. Contovounesios" <contovob <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#44664; Package
emacs.
(Fri, 27 Nov 2020 08:16:02 GMT)
Full text and
rfc822 format available.
Message #171 received at 44664 <at> debbugs.gnu.org (full text, mbox):
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: schwab <at> linux-m68k.org, bugs <at> gnu.support, 44664 <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#44664; Package
emacs.
(Sun, 29 Nov 2020 09:59:02 GMT)
Full text and
rfc822 format available.
Message #174 received at 44664 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#44664; Package
emacs.
(Sun, 29 Nov 2020 15:47:02 GMT)
Full text and
rfc822 format available.
Message #177 received at 44664 <at> debbugs.gnu.org (full text, mbox):
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: schwab <at> linux-m68k.org, bugs <at> gnu.support, 44664 <at> debbugs.gnu.org
> Date: Sun, 29 Nov 2020 10:58:16 +0100
>
> Eli Zaretskii <eliz <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#44664; Package
emacs.
(Mon, 30 Nov 2020 10:06:02 GMT)
Full text and
rfc822 format available.
Message #180 received at 44664 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#44664; Package
emacs.
(Mon, 30 Nov 2020 16:14:02 GMT)
Full text and
rfc822 format available.
Message #183 received at 44664 <at> debbugs.gnu.org (full text, mbox):
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: schwab <at> linux-m68k.org, bugs <at> gnu.support, 44664 <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#44664; Package
emacs.
(Wed, 02 Dec 2020 09:40:01 GMT)
Full text and
rfc822 format available.
Message #186 received at 44664 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#44664; Package
emacs.
(Wed, 02 Dec 2020 15:03:01 GMT)
Full text and
rfc822 format available.
Message #189 received at 44664 <at> debbugs.gnu.org (full text, mbox):
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: schwab <at> linux-m68k.org, bugs <at> gnu.support, 44664 <at> debbugs.gnu.org
> Date: Wed, 02 Dec 2020 10:39:08 +0100
>
> Eli Zaretskii <eliz <at> 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?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#44664; Package
emacs.
(Wed, 02 Dec 2020 16:35:02 GMT)
Full text and
rfc822 format available.
Message #192 received at 44664 <at> debbugs.gnu.org (full text, mbox):
* Eli Zaretskii <eliz <at> gnu.org> [2020-12-02 18:03]:
> > From: Lars Ingebrigtsen <larsi <at> gnus.org>
> > Cc: schwab <at> linux-m68k.org, bugs <at> gnu.support, 44664 <at> debbugs.gnu.org
> > Date: Wed, 02 Dec 2020 10:39:08 +0100
> >
> > Eli Zaretskii <eliz <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#44664; Package
emacs.
(Thu, 03 Dec 2020 08:45:01 GMT)
Full text and
rfc822 format available.
Message #195 received at 44664 <at> debbugs.gnu.org (full text, mbox):
Jean Louis <bugs <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#44664; Package
emacs.
(Thu, 03 Dec 2020 08:56:01 GMT)
Full text and
rfc822 format available.
Message #198 received at 44664 <at> debbugs.gnu.org (full text, mbox):
* Lars Ingebrigtsen <larsi <at> gnus.org> [2020-12-03 11:44]:
> Jean Louis <bugs <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#44664; Package
emacs.
(Thu, 03 Dec 2020 09:03:02 GMT)
Full text and
rfc822 format available.
Message #201 received at 44664 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Jean Louis <bugs <at> 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:
[Message part 2 (image/png, inline)]
[Message part 3 (text/plain, inline)]
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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#44664; Package
emacs.
(Thu, 03 Dec 2020 15:16:01 GMT)
Full text and
rfc822 format available.
Message #204 received at 44664 <at> debbugs.gnu.org (full text, mbox):
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, schwab <at> linux-m68k.org,
> 44664 <at> debbugs.gnu.org
> Date: Thu, 03 Dec 2020 09:44:13 +0100
>
> Jean Louis <bugs <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#44664; Package
emacs.
(Thu, 03 Dec 2020 15:20:02 GMT)
Full text and
rfc822 format available.
Message #207 received at 44664 <at> debbugs.gnu.org (full text, mbox):
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, schwab <at> linux-m68k.org,
> 44664 <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#44664; Package
emacs.
(Thu, 03 Dec 2020 17:01:01 GMT)
Full text and
rfc822 format available.
Message #210 received at 44664 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#44664; Package
emacs.
(Thu, 03 Dec 2020 17:05:01 GMT)
Full text and
rfc822 format available.
Message #213 received at 44664 <at> debbugs.gnu.org (full text, mbox):
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: bugs <at> gnu.support, schwab <at> linux-m68k.org, 44664 <at> debbugs.gnu.org
> Date: Thu, 03 Dec 2020 17:59:48 +0100
>
> Eli Zaretskii <eliz <at> 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.
Forcibly Merged 6718 36983 44664.
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org.
(Wed, 02 Feb 2022 18:45:02 GMT)
Full text and
rfc822 format available.
This bug report was last modified 2 years and 82 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.