* bug#37530: 26.1; Tack characters translated incorrectly
@ 2019-09-26 21:31 Axel Svensson
2019-09-27 5:26 ` Eli Zaretskii
0 siblings, 1 reply; 26+ messages in thread
From: Axel Svensson @ 2019-09-26 21:31 UTC (permalink / raw)
To: 37530
To reproduce:
Start emacs with the -Q option under X11.
Press a key mapped to keysym 0xbfc.
It is expected that the character "⊢" (Right Tack, U+22a2) is inserted.
Instead, the character "⊣" (Left Tack, U+22a3) is inserted.
Press a key mapped to keysym 0xbdc.
It is expected that the character "⊣" (Left Tack, U+22a3) is inserted.
Instead, the character "⊢" (Right Tack, U+22a2) is inserted.
Press a key mapped to keysym 0xbc2.
It is expected that the character "⊤" (Down Tack, U+22a4) is inserted.
Instead, the character "⊥" (Up Tack, U+22a5) is inserted.
Press a key mapped to keysym 0xbce.
It is expected that the character "⊥" (Up Tack, U+22a5) is inserted.
Instead, the character "⊤" (Down Tack, U+22a4) is inserted.
Press C-h l to run view-lossage.
The last lines display the erroneous characters that were inserted,
rather than the expected characters.
⊣ [self-insert-command]
⊢ [self-insert-command]
⊥ [self-insert-command]
⊤ [self-insert-command]
C-h l [view-lossage]
In order to confirm that the behavior I have stated as expected is the
correct one, look to the XKB keysym definitions:
> #define XKB_KEY_downtack 0x0bc2 /* U+22A4 DOWN TACK */
> #define XKB_KEY_uptack 0x0bce /* U+22A5 UP TACK */
> #define XKB_KEY_lefttack 0x0bdc /* U+22A3 LEFT TACK */
> #define XKB_KEY_righttack 0x0bfc /* U+22A2 RIGHT TACK */
These can be found at:
https://github.com/xkbcommon/libxkbcommon/blob/master/xkbcommon/xkbcommon-keysyms.h
It is understandable that bugs like these can go unnoticed seeing that
these characters probably aren't part of any widely used keyboard
layout. If this bug can be confirmed, and depending on what caused it,
it might be beneficial to add the complete mapping from X11 keysyms to
Unicode codepoints as automated tests. I'm willing to provide this
mapping, including source references.
In GNU Emacs 26.1 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.24.4)
of 2019-02-03, modified by Debian built on zam904
Windowing system distributor 'The X.Org Foundation', version 11.0.12004000
System Description: Debian GNU/Linux 10 (buster)
Configured using:
'configure --build x86_64-linux-gnu --prefix=/usr
--sharedstatedir=/var/lib --libexecdir=/usr/lib
--localstatedir=/var/lib --infodir=/usr/share/info
--mandir=/usr/share/man --enable-libsystemd --with-pop=yes
--enable-locallisppath=/etc/emacs:/usr/local/share/emacs/26.1/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/26.1/site-lisp:/usr/share/emacs/site-lisp
--with-sound=alsa --without-gconf --with-mailutils --build
x86_64-linux-gnu --prefix=/usr --sharedstatedir=/var/lib
--libexecdir=/usr/lib --localstatedir=/var/lib
--infodir=/usr/share/info --mandir=/usr/share/man --enable-libsystemd
--with-pop=yes
--enable-locallisppath=/etc/emacs:/usr/local/share/emacs/26.1/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/26.1/site-lisp:/usr/share/emacs/site-lisp
--with-sound=alsa --without-gconf --with-mailutils --with-x=yes
--with-x-toolkit=gtk3 --with-toolkit-scroll-bars 'CFLAGS=-g -O2
-fdebug-prefix-map=/build/emacs-26.1+1=. -fstack-protector-strong
-Wformat -Werror=format-security -Wall' 'CPPFLAGS=-Wdate-time
-D_FORTIFY_SOURCE=2' LDFLAGS=-Wl,-z,relro'
Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GSETTINGS NOTIFY
ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB
TOOLKIT_SCROLL_BARS GTK3 X11 THREADS LIBSYSTEMD LCMS2
Important settings:
value of $LC_ALL: en_US.UTF-8
value of $LANG: en_US.UTF-8
locale-coding-system: utf-8-unix
Major mode: Fundamental
Minor modes in effect:
show-paren-mode: t
delete-selection-mode: t
editorconfig-mode: t
global-magit-file-mode: t
magit-file-mode: t
diff-auto-refine-mode: t
magit-auto-revert-mode: t
auto-revert-mode: t
global-git-commit-mode: t
async-bytecomp-package-mode: t
shell-dirtrack-mode: t
cl-old-struct-compat-mode: t
tooltip-mode: t
global-eldoc-mode: t
electric-indent-mode: t
mouse-wheel-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
column-number-mode: t
line-number-mode: t
transient-mark-mode: t
Load-path shadows:
/home/user/.emacs.d/elpa/async-20190503.656/async-bytecomp hides
/usr/share/emacs/site-lisp/elpa/async-1.9.3/async-bytecomp
/home/user/.emacs.d/elpa/async-20190503.656/dired-async hides
/usr/share/emacs/site-lisp/elpa/async-1.9.3/dired-async
/home/user/.emacs.d/elpa/async-20190503.656/async-pkg hides
/usr/share/emacs/site-lisp/elpa/async-1.9.3/async-pkg
/home/user/.emacs.d/elpa/async-20190503.656/async hides
/usr/share/emacs/site-lisp/elpa/async-1.9.3/async
/home/user/.emacs.d/elpa/async-20190503.656/async-autoloads hides
/usr/share/emacs/site-lisp/elpa/async-1.9.3/async-autoloads
/home/user/.emacs.d/elpa/async-20190503.656/smtpmail-async hides
/usr/share/emacs/site-lisp/elpa/async-1.9.3/smtpmail-async
/home/user/.emacs.d/elpa/dash-20190424.1804/dash hides
/usr/share/emacs/site-lisp/elpa/dash-2.14.1/dash
/home/user/.emacs.d/elpa/dash-20190424.1804/dash-autoloads hides
/usr/share/emacs/site-lisp/elpa/dash-2.14.1/dash-autoloads
/home/user/.emacs.d/elpa/dash-20190424.1804/dash-pkg hides
/usr/share/emacs/site-lisp/elpa/dash-2.14.1/dash-pkg
/home/user/.emacs.d/elpa/async-20190503.656/dired-async hides
/usr/share/emacs/site-lisp/elpa-src/async-1.9.3/dired-async
/home/user/.emacs.d/elpa/async-20190503.656/async-pkg hides
/usr/share/emacs/site-lisp/elpa-src/async-1.9.3/async-pkg
/home/user/.emacs.d/elpa/async-20190503.656/async-bytecomp hides
/usr/share/emacs/site-lisp/elpa-src/async-1.9.3/async-bytecomp
/home/user/.emacs.d/elpa/async-20190503.656/async hides
/usr/share/emacs/site-lisp/elpa-src/async-1.9.3/async
/home/user/.emacs.d/elpa/async-20190503.656/async-autoloads hides
/usr/share/emacs/site-lisp/elpa-src/async-1.9.3/async-autoloads
/home/user/.emacs.d/elpa/async-20190503.656/smtpmail-async hides
/usr/share/emacs/site-lisp/elpa-src/async-1.9.3/smtpmail-async
/home/user/.emacs.d/elpa/dash-20190424.1804/dash-autoloads hides
/usr/share/emacs/site-lisp/elpa-src/dash-2.14.1/dash-autoloads
/home/user/.emacs.d/elpa/dash-20190424.1804/dash-pkg hides
/usr/share/emacs/site-lisp/elpa-src/dash-2.14.1/dash-pkg
/home/user/.emacs.d/elpa/dash-20190424.1804/dash hides
/usr/share/emacs/site-lisp/elpa-src/dash-2.14.1/dash
/usr/share/emacs/site-lisp/elpa/ghub-3.0.0/buck hides
/usr/share/emacs/site-lisp/elpa-src/ghub-3.0.0/buck
/usr/share/emacs/site-lisp/elpa/ghub-3.0.0/ghub-graphql hides
/usr/share/emacs/site-lisp/elpa-src/ghub-3.0.0/ghub-graphql
/usr/share/emacs/site-lisp/elpa/ghub-3.0.0/ghub-autoloads hides
/usr/share/emacs/site-lisp/elpa-src/ghub-3.0.0/ghub-autoloads
/usr/share/emacs/site-lisp/elpa/ghub-3.0.0/ghub-pkg hides
/usr/share/emacs/site-lisp/elpa-src/ghub-3.0.0/ghub-pkg
/usr/share/emacs/site-lisp/elpa/ghub-3.0.0/glab hides
/usr/share/emacs/site-lisp/elpa-src/ghub-3.0.0/glab
/usr/share/emacs/site-lisp/elpa/ghub-3.0.0/ghub hides
/usr/share/emacs/site-lisp/elpa-src/ghub-3.0.0/ghub
/usr/share/emacs/site-lisp/elpa/ghub-3.0.0/gogs hides
/usr/share/emacs/site-lisp/elpa-src/ghub-3.0.0/gogs
/usr/share/emacs/site-lisp/elpa/ghub-3.0.0/gtea hides
/usr/share/emacs/site-lisp/elpa-src/ghub-3.0.0/gtea
/usr/share/emacs/site-lisp/elpa/git-commit-2.90.1/git-commit-pkg hides
/usr/share/emacs/site-lisp/elpa-src/git-commit-2.90.1/git-commit-pkg
/usr/share/emacs/site-lisp/elpa/git-commit-2.90.1/git-commit-autoloads
hides /usr/share/emacs/site-lisp/elpa-src/git-commit-2.90.1/git-commit-autoloads
/usr/share/emacs/site-lisp/elpa/git-commit-2.90.1/git-commit hides
/usr/share/emacs/site-lisp/elpa-src/git-commit-2.90.1/git-commit
/usr/share/emacs/site-lisp/elpa/graphql-0.1.1/graphql hides
/usr/share/emacs/site-lisp/elpa-src/graphql-0.1.1/graphql
/usr/share/emacs/site-lisp/elpa/graphql-0.1.1/graphql-autoloads hides
/usr/share/emacs/site-lisp/elpa-src/graphql-0.1.1/graphql-autoloads
/usr/share/emacs/site-lisp/elpa/graphql-0.1.1/graphql-pkg hides
/usr/share/emacs/site-lisp/elpa-src/graphql-0.1.1/graphql-pkg
/usr/share/emacs/site-lisp/elpa/haskell-mode-16.1/haskell-commands
hides /usr/share/emacs/site-lisp/elpa-src/haskell-mode-16.1/haskell-commands
/usr/share/emacs/site-lisp/elpa/haskell-mode-16.1/haskell-font-lock
hides /usr/share/emacs/site-lisp/elpa-src/haskell-mode-16.1/haskell-font-lock
/usr/share/emacs/site-lisp/elpa/haskell-mode-16.1/haskell-mode-autoloads
hides /usr/share/emacs/site-lisp/elpa-src/haskell-mode-16.1/haskell-mode-autoloads
/usr/share/emacs/site-lisp/elpa/haskell-mode-16.1/haskell-unicode-input-method
hides /usr/share/emacs/site-lisp/elpa-src/haskell-mode-16.1/haskell-unicode-input-method
/usr/share/emacs/site-lisp/elpa/haskell-mode-16.1/haskell-session
hides /usr/share/emacs/site-lisp/elpa-src/haskell-mode-16.1/haskell-session
/usr/share/emacs/site-lisp/elpa/haskell-mode-16.1/haskell-c2hs hides
/usr/share/emacs/site-lisp/elpa-src/haskell-mode-16.1/haskell-c2hs
/usr/share/emacs/site-lisp/elpa/haskell-mode-16.1/haskell-sandbox
hides /usr/share/emacs/site-lisp/elpa-src/haskell-mode-16.1/haskell-sandbox
/usr/share/emacs/site-lisp/elpa/haskell-mode-16.1/haskell-repl hides
/usr/share/emacs/site-lisp/elpa-src/haskell-mode-16.1/haskell-repl
/usr/share/emacs/site-lisp/elpa/haskell-mode-16.1/ghc-core hides
/usr/share/emacs/site-lisp/elpa-src/haskell-mode-16.1/ghc-core
/usr/share/emacs/site-lisp/elpa/haskell-mode-16.1/w3m-haddock hides
/usr/share/emacs/site-lisp/elpa-src/haskell-mode-16.1/w3m-haddock
/usr/share/emacs/site-lisp/elpa/haskell-mode-16.1/haskell-process
hides /usr/share/emacs/site-lisp/elpa-src/haskell-mode-16.1/haskell-process
/usr/share/emacs/site-lisp/elpa/haskell-mode-16.1/haskell-mode-pkg
hides /usr/share/emacs/site-lisp/elpa-src/haskell-mode-16.1/haskell-mode-pkg
/usr/share/emacs/site-lisp/elpa/haskell-mode-16.1/haskell-ghc-support
hides /usr/share/emacs/site-lisp/elpa-src/haskell-mode-16.1/haskell-ghc-support
/usr/share/emacs/site-lisp/elpa/haskell-mode-16.1/ghci-script-mode
hides /usr/share/emacs/site-lisp/elpa-src/haskell-mode-16.1/ghci-script-mode
/usr/share/emacs/site-lisp/elpa/haskell-mode-16.1/haskell-move-nested
hides /usr/share/emacs/site-lisp/elpa-src/haskell-mode-16.1/haskell-move-nested
/usr/share/emacs/site-lisp/elpa/haskell-mode-16.1/haskell-collapse
hides /usr/share/emacs/site-lisp/elpa-src/haskell-mode-16.1/haskell-collapse
/usr/share/emacs/site-lisp/elpa/haskell-mode-16.1/haskell-complete-module
hides /usr/share/emacs/site-lisp/elpa-src/haskell-mode-16.1/haskell-complete-module
/usr/share/emacs/site-lisp/elpa/haskell-mode-16.1/haskell-presentation-mode
hides /usr/share/emacs/site-lisp/elpa-src/haskell-mode-16.1/haskell-presentation-mode
/usr/share/emacs/site-lisp/elpa/haskell-mode-16.1/highlight-uses-mode
hides /usr/share/emacs/site-lisp/elpa-src/haskell-mode-16.1/highlight-uses-mode
/usr/share/emacs/site-lisp/elpa/haskell-mode-16.1/haskell-indentation
hides /usr/share/emacs/site-lisp/elpa-src/haskell-mode-16.1/haskell-indentation
/usr/share/emacs/site-lisp/elpa/haskell-mode-16.1/haskell-align-imports
hides /usr/share/emacs/site-lisp/elpa-src/haskell-mode-16.1/haskell-align-imports
/usr/share/emacs/site-lisp/elpa/haskell-mode-16.1/haskell-indent hides
/usr/share/emacs/site-lisp/elpa-src/haskell-mode-16.1/haskell-indent
/usr/share/emacs/site-lisp/elpa/haskell-mode-16.1/haskell hides
/usr/share/emacs/site-lisp/elpa-src/haskell-mode-16.1/haskell
/usr/share/emacs/site-lisp/elpa/haskell-mode-16.1/haskell-customize
hides /usr/share/emacs/site-lisp/elpa-src/haskell-mode-16.1/haskell-customize
/usr/share/emacs/site-lisp/elpa/haskell-mode-16.1/haskell-interactive-mode
hides /usr/share/emacs/site-lisp/elpa-src/haskell-mode-16.1/haskell-interactive-mode
/usr/share/emacs/site-lisp/elpa/haskell-mode-16.1/haskell-decl-scan
hides /usr/share/emacs/site-lisp/elpa-src/haskell-mode-16.1/haskell-decl-scan
/usr/share/emacs/site-lisp/elpa/haskell-mode-16.1/haskell-string hides
/usr/share/emacs/site-lisp/elpa-src/haskell-mode-16.1/haskell-string
/usr/share/emacs/site-lisp/elpa/haskell-mode-16.1/haskell-navigate-imports
hides /usr/share/emacs/site-lisp/elpa-src/haskell-mode-16.1/haskell-navigate-imports
/usr/share/emacs/site-lisp/elpa/haskell-mode-16.1/haskell-hoogle hides
/usr/share/emacs/site-lisp/elpa-src/haskell-mode-16.1/haskell-hoogle
/usr/share/emacs/site-lisp/elpa/haskell-mode-16.1/haskell-utils hides
/usr/share/emacs/site-lisp/elpa-src/haskell-mode-16.1/haskell-utils
/usr/share/emacs/site-lisp/elpa/haskell-mode-16.1/haskell-compile
hides /usr/share/emacs/site-lisp/elpa-src/haskell-mode-16.1/haskell-compile
/usr/share/emacs/site-lisp/elpa/haskell-mode-16.1/haskell-mode hides
/usr/share/emacs/site-lisp/elpa-src/haskell-mode-16.1/haskell-mode
/usr/share/emacs/site-lisp/elpa/haskell-mode-16.1/haskell-completions
hides /usr/share/emacs/site-lisp/elpa-src/haskell-mode-16.1/haskell-completions
/usr/share/emacs/site-lisp/elpa/haskell-mode-16.1/haskell-modules
hides /usr/share/emacs/site-lisp/elpa-src/haskell-mode-16.1/haskell-modules
/usr/share/emacs/site-lisp/elpa/haskell-mode-16.1/haskell-menu hides
/usr/share/emacs/site-lisp/elpa-src/haskell-mode-16.1/haskell-menu
/usr/share/emacs/site-lisp/elpa/haskell-mode-16.1/haskell-doc hides
/usr/share/emacs/site-lisp/elpa-src/haskell-mode-16.1/haskell-doc
/usr/share/emacs/site-lisp/elpa/haskell-mode-16.1/haskell-compat hides
/usr/share/emacs/site-lisp/elpa-src/haskell-mode-16.1/haskell-compat
/usr/share/emacs/site-lisp/elpa/haskell-mode-16.1/inf-haskell hides
/usr/share/emacs/site-lisp/elpa-src/haskell-mode-16.1/inf-haskell
/usr/share/emacs/site-lisp/elpa/haskell-mode-16.1/haskell-debug hides
/usr/share/emacs/site-lisp/elpa-src/haskell-mode-16.1/haskell-debug
/usr/share/emacs/site-lisp/elpa/haskell-mode-16.1/haskell-sort-imports
hides /usr/share/emacs/site-lisp/elpa-src/haskell-mode-16.1/haskell-sort-imports
/usr/share/emacs/site-lisp/elpa/haskell-mode-16.1/haskell-lexeme hides
/usr/share/emacs/site-lisp/elpa-src/haskell-mode-16.1/haskell-lexeme
/usr/share/emacs/site-lisp/elpa/haskell-mode-16.1/haskell-cabal hides
/usr/share/emacs/site-lisp/elpa-src/haskell-mode-16.1/haskell-cabal
/usr/share/emacs/site-lisp/elpa/haskell-mode-16.1/haskell-load hides
/usr/share/emacs/site-lisp/elpa-src/haskell-mode-16.1/haskell-load
/usr/share/emacs/site-lisp/elpa/let-alist-1.0.5/let-alist-pkg hides
/usr/share/emacs/site-lisp/elpa-src/let-alist-1.0.5/let-alist-pkg
/usr/share/emacs/site-lisp/elpa/let-alist-1.0.5/let-alist-autoloads
hides /usr/share/emacs/site-lisp/elpa-src/let-alist-1.0.5/let-alist-autoloads
/usr/share/emacs/site-lisp/elpa/let-alist-1.0.5/let-alist hides
/usr/share/emacs/site-lisp/elpa-src/let-alist-1.0.5/let-alist
/usr/share/emacs/site-lisp/elpa/magit-2.90.1/magit-wip hides
/usr/share/emacs/site-lisp/elpa-src/magit-2.90.1/magit-wip
/usr/share/emacs/site-lisp/elpa/magit-2.90.1/magit-remote hides
/usr/share/emacs/site-lisp/elpa-src/magit-2.90.1/magit-remote
/usr/share/emacs/site-lisp/elpa/magit-2.90.1/magit-blame hides
/usr/share/emacs/site-lisp/elpa-src/magit-2.90.1/magit-blame
/usr/share/emacs/site-lisp/elpa/magit-2.90.1/magit-autoloads hides
/usr/share/emacs/site-lisp/elpa-src/magit-2.90.1/magit-autoloads
/usr/share/emacs/site-lisp/elpa/magit-2.90.1/magit-obsolete hides
/usr/share/emacs/site-lisp/elpa-src/magit-2.90.1/magit-obsolete
/usr/share/emacs/site-lisp/elpa/magit-2.90.1/magit-ediff hides
/usr/share/emacs/site-lisp/elpa-src/magit-2.90.1/magit-ediff
/usr/share/emacs/site-lisp/elpa/magit-2.90.1/magit-core hides
/usr/share/emacs/site-lisp/elpa-src/magit-2.90.1/magit-core
/usr/share/emacs/site-lisp/elpa/magit-2.90.1/magit-push hides
/usr/share/emacs/site-lisp/elpa-src/magit-2.90.1/magit-push
/usr/share/emacs/site-lisp/elpa/magit-2.90.1/magit-process hides
/usr/share/emacs/site-lisp/elpa-src/magit-2.90.1/magit-process
/usr/share/emacs/site-lisp/elpa/magit-2.90.1/magit-log hides
/usr/share/emacs/site-lisp/elpa-src/magit-2.90.1/magit-log
/usr/share/emacs/site-lisp/elpa/magit-2.90.1/magit-git hides
/usr/share/emacs/site-lisp/elpa-src/magit-2.90.1/magit-git
/usr/share/emacs/site-lisp/elpa/magit-2.90.1/magit-apply hides
/usr/share/emacs/site-lisp/elpa-src/magit-2.90.1/magit-apply
/usr/share/emacs/site-lisp/elpa/magit-2.90.1/magit-clone hides
/usr/share/emacs/site-lisp/elpa-src/magit-2.90.1/magit-clone
/usr/share/emacs/site-lisp/elpa/magit-2.90.1/magit-collab hides
/usr/share/emacs/site-lisp/elpa-src/magit-2.90.1/magit-collab
/usr/share/emacs/site-lisp/elpa/magit-2.90.1/magit-tag hides
/usr/share/emacs/site-lisp/elpa-src/magit-2.90.1/magit-tag
/usr/share/emacs/site-lisp/elpa/magit-2.90.1/magit-margin hides
/usr/share/emacs/site-lisp/elpa-src/magit-2.90.1/magit-margin
/usr/share/emacs/site-lisp/elpa/magit-2.90.1/magit-bisect hides
/usr/share/emacs/site-lisp/elpa-src/magit-2.90.1/magit-bisect
/usr/share/emacs/site-lisp/elpa/magit-2.90.1/magit-reset hides
/usr/share/emacs/site-lisp/elpa-src/magit-2.90.1/magit-reset
/usr/share/emacs/site-lisp/elpa/magit-2.90.1/magit-repos hides
/usr/share/emacs/site-lisp/elpa-src/magit-2.90.1/magit-repos
/usr/share/emacs/site-lisp/elpa/magit-2.90.1/magit-pkg hides
/usr/share/emacs/site-lisp/elpa-src/magit-2.90.1/magit-pkg
/usr/share/emacs/site-lisp/elpa/magit-2.90.1/git-rebase hides
/usr/share/emacs/site-lisp/elpa-src/magit-2.90.1/git-rebase
/usr/share/emacs/site-lisp/elpa/magit-2.90.1/magit-bookmark hides
/usr/share/emacs/site-lisp/elpa-src/magit-2.90.1/magit-bookmark
/usr/share/emacs/site-lisp/elpa/magit-2.90.1/magit-mode hides
/usr/share/emacs/site-lisp/elpa-src/magit-2.90.1/magit-mode
/usr/share/emacs/site-lisp/elpa/magit-2.90.1/magit-worktree hides
/usr/share/emacs/site-lisp/elpa-src/magit-2.90.1/magit-worktree
/usr/share/emacs/site-lisp/elpa/magit-2.90.1/magit-imenu hides
/usr/share/emacs/site-lisp/elpa-src/magit-2.90.1/magit-imenu
/usr/share/emacs/site-lisp/elpa/magit-2.90.1/magit-notes hides
/usr/share/emacs/site-lisp/elpa-src/magit-2.90.1/magit-notes
/usr/share/emacs/site-lisp/elpa/magit-2.90.1/magit-sequence hides
/usr/share/emacs/site-lisp/elpa-src/magit-2.90.1/magit-sequence
/usr/share/emacs/site-lisp/elpa/magit-2.90.1/magit-stash hides
/usr/share/emacs/site-lisp/elpa-src/magit-2.90.1/magit-stash
/usr/share/emacs/site-lisp/elpa/magit-2.90.1/magit-status hides
/usr/share/emacs/site-lisp/elpa-src/magit-2.90.1/magit-status
/usr/share/emacs/site-lisp/elpa/magit-2.90.1/magit-fetch hides
/usr/share/emacs/site-lisp/elpa-src/magit-2.90.1/magit-fetch
/usr/share/emacs/site-lisp/elpa/magit-2.90.1/magit-section hides
/usr/share/emacs/site-lisp/elpa-src/magit-2.90.1/magit-section
/usr/share/emacs/site-lisp/elpa/magit-2.90.1/magit hides
/usr/share/emacs/site-lisp/elpa-src/magit-2.90.1/magit
/usr/share/emacs/site-lisp/elpa/magit-2.90.1/magit-utils hides
/usr/share/emacs/site-lisp/elpa-src/magit-2.90.1/magit-utils
/usr/share/emacs/site-lisp/elpa/magit-2.90.1/magit-gitignore hides
/usr/share/emacs/site-lisp/elpa-src/magit-2.90.1/magit-gitignore
/usr/share/emacs/site-lisp/elpa/magit-2.90.1/magit-merge hides
/usr/share/emacs/site-lisp/elpa-src/magit-2.90.1/magit-merge
/usr/share/emacs/site-lisp/elpa/magit-2.90.1/magit-patch hides
/usr/share/emacs/site-lisp/elpa-src/magit-2.90.1/magit-patch
/usr/share/emacs/site-lisp/elpa/magit-2.90.1/magit-autorevert hides
/usr/share/emacs/site-lisp/elpa-src/magit-2.90.1/magit-autorevert
/usr/share/emacs/site-lisp/elpa/magit-2.90.1/magit-extras hides
/usr/share/emacs/site-lisp/elpa-src/magit-2.90.1/magit-extras
/usr/share/emacs/site-lisp/elpa/magit-2.90.1/magit-refs hides
/usr/share/emacs/site-lisp/elpa-src/magit-2.90.1/magit-refs
/usr/share/emacs/site-lisp/elpa/magit-2.90.1/magit-commit hides
/usr/share/emacs/site-lisp/elpa-src/magit-2.90.1/magit-commit
/usr/share/emacs/site-lisp/elpa/magit-2.90.1/magit-files hides
/usr/share/emacs/site-lisp/elpa-src/magit-2.90.1/magit-files
/usr/share/emacs/site-lisp/elpa/magit-2.90.1/magit-branch hides
/usr/share/emacs/site-lisp/elpa-src/magit-2.90.1/magit-branch
/usr/share/emacs/site-lisp/elpa/magit-2.90.1/magit-subtree hides
/usr/share/emacs/site-lisp/elpa-src/magit-2.90.1/magit-subtree
/usr/share/emacs/site-lisp/elpa/magit-2.90.1/magit-pull hides
/usr/share/emacs/site-lisp/elpa-src/magit-2.90.1/magit-pull
/usr/share/emacs/site-lisp/elpa/magit-2.90.1/magit-submodule hides
/usr/share/emacs/site-lisp/elpa-src/magit-2.90.1/magit-submodule
/usr/share/emacs/site-lisp/elpa/magit-2.90.1/magit-diff hides
/usr/share/emacs/site-lisp/elpa-src/magit-2.90.1/magit-diff
/usr/share/emacs/site-lisp/elpa/magit-popup-2.12.5/magit-popup hides
/usr/share/emacs/site-lisp/elpa-src/magit-popup-2.12.5/magit-popup
/usr/share/emacs/site-lisp/elpa/magit-popup-2.12.5/magit-popup-autoloads
hides /usr/share/emacs/site-lisp/elpa-src/magit-popup-2.12.5/magit-popup-autoloads
/usr/share/emacs/site-lisp/elpa/magit-popup-2.12.5/magit-popup-pkg
hides /usr/share/emacs/site-lisp/elpa-src/magit-popup-2.12.5/magit-popup-pkg
/usr/share/emacs/site-lisp/elpa/treepy-0.1.1/treepy-autoloads hides
/usr/share/emacs/site-lisp/elpa-src/treepy-0.1.1/treepy-autoloads
/usr/share/emacs/site-lisp/elpa/treepy-0.1.1/treepy hides
/usr/share/emacs/site-lisp/elpa-src/treepy-0.1.1/treepy
/usr/share/emacs/site-lisp/elpa/treepy-0.1.1/treepy-pkg hides
/usr/share/emacs/site-lisp/elpa-src/treepy-0.1.1/treepy-pkg
/usr/share/emacs/site-lisp/elpa/with-editor-2.6.0/with-editor-autoloads
hides /usr/share/emacs/site-lisp/elpa-src/with-editor-2.6.0/with-editor-autoloads
/usr/share/emacs/site-lisp/elpa/with-editor-2.6.0/with-editor-pkg
hides /usr/share/emacs/site-lisp/elpa-src/with-editor-2.6.0/with-editor-pkg
/usr/share/emacs/site-lisp/elpa/with-editor-2.6.0/with-editor hides
/usr/share/emacs/site-lisp/elpa-src/with-editor-2.6.0/with-editor
/usr/share/emacs/site-lisp/latex-cjk-thai/thai-word hides
/usr/share/emacs/26.1/lisp/language/thai-word
/usr/share/emacs/site-lisp/elpa/let-alist-1.0.5/let-alist hides
/usr/share/emacs/26.1/lisp/emacs-lisp/let-alist
Features:
(shadow mail-extr emacsbug sendmail ruler-mode hl-line hexl dcl-mode
tempo term/xterm xterm repeat bat-mode ox-odt ox-latex ox-icalendar
ox-html ox-ascii ox-publish ox thai-util thai-word magit-ediff
ediff-merg ediff-wind ediff-diff ediff-mult ediff-help ediff-init
ediff-util ediff calc-forms calc-alg calc-ext calc-menu calc
calc-loaddefs calc-macs dired-x editorconfig-conf-mode magit-subtree
rng-xsd xsd-regexp rng-cmpct nxml-mode-expansions rng-nxml rng-valid
rng-loc rng-uri rng-parse nxml-parse rng-match rng-dt rng-util rng-pttrn
nxml-ns nxml-mode nxml-outln nxml-rap nxml-util nxml-enc xmltok timezone
w3m-hist w3m-e21 w3m-ccl ccl w3m-fsf w3m-favicon w3m-image w3m-proc
w3m-util webjump sort iso-transl ffap url-file url-dired markdown-mode
autoconf autoconf-mode magit-gitignore tabify man apropos wdired
parseclj-ast smartparens-markdown smartparens-text smartparens-ruby
autoload mm-archive pp cus-edit cus-start cus-load url-cache tramp-cache
cl-print debug disp-table whitespace tar-mode tex-mode latexenc
python-el-fgallina-expansions python cider-selector cider-scratch
arc-mode archive-mode cider-find pkg-info epl network-stream starttls
eieio-opt git-rebase help-fns radix-tree novice magit-extras
bug-reference mhtml-mode flyspell ispell org-rmail org-mhe org-irc
org-info org-gnus nnir org-docview org-bibtex bibtex org-bbdb org-w3m
conf-mode dired-aux misearch multi-isearch vc-git sh-script executable
editorconfig-core editorconfig-core-handle editorconfig-fnmatch ibuf-ext
ibuffer ibuffer-loaddefs fringemark doc-view jka-compr image-mode
gnus-async nntp gnus-sum gnus-group gnus-undo gnus-start gnus-cloud
nnimap nnmail mail-source utf7 netrc nnoo gnus-spec gnus-int gnus-range
gnus-win org-mobile org-agenda org-install w3m-load paren saveplace ido
table delsel grep editorconfig helm helm-source eieio-compat
helm-multi-match helm-lib sass-mode haml-mode js-mode-expansions js
css-mode-expansions css-mode html-mode-expansions sgml-mode eww mm-url
gnus nnheader wid-edit url-queue shr svg xml dom browse-url
ruby-mode-expansions ruby-mode cider tramp-sh cider-debug
cider-inspector cider-browse-ns cider-mode cider-completion
cider-profile cider-eval cider-repl-history pulse cider-repl
cider-resolve cider-test cider-overlays cider-stacktrace cider-doc
cider-browse-spec org-table org-element avl-tree generator
the-org-mode-expansions org org-macro org-footnote org-pcomplete
org-list org-faces org-entities noutline outline org-version
ob-emacs-lisp ob ob-tangle org-src ob-ref ob-lob ob-table ob-keys ob-exp
ob-comint ob-core ob-eval org-compat org-macs org-loaddefs cal-menu
calendar cal-loaddefs cider-grimoire cider-popup cider-eldoc
cider-client cider-common cider-util color cider-connection
sesman-browser nrepl-client tramp tramp-compat tramp-loaddefs trampver
ucs-normalize parse-time queue nrepl-dict cider-compat spinner parseedn
parseclj-parser parseclj-lex a auto-complete popup gtags php-mode
php-project mode-local find-func speedbar sb-image ezimage dframe etags
xref flymake-proc flymake warnings cc-langs cc-mode-expansions cc-mode
cc-fonts cc-guess cc-menus cc-cmds cc-styles cc-align cc-engine cc-vars
cc-defs php-face php on-screen ace-jump-mode cl yasnippet elec-pair
sml-mode-expansions sml-mode compile smie expand-region
text-mode-expansions clojure-mode-expansions er-basic-expansions
expand-region-core expand-region-custom multiple-cursors
mc-hide-unmatched-lines-mode mc-separate-operations
rectangular-region-mode mc-mark-pop mc-mark-more mc-cycle-cursors
mc-edit-lines multiple-cursors-core rect rainbow-delimiters smartparens
thingatpt paredit sesman vc vc-dispatcher clojure-mode project lisp-mnt
subr-x align undo-tree diff enclose edmacro kmacro magit-submodule
magit-obsolete magit-blame magit-stash magit-bisect magit-push
magit-pull magit-fetch magit-clone magit-remote magit-commit
magit-sequence magit-notes magit-worktree magit-tag magit-merge
magit-branch magit-reset magit-collab ghub-graphql treepy graphql pcase
ghub url-http tls gnutls url-gw nsm url-auth url url-proxy url-privacy
url-expand url-methods url-history url-cookie url-domsuf url-util
mailcap let-alist json map magit-files magit-refs magit-status magit
magit-repos magit-apply magit-wip magit-log which-func imenu magit-diff
smerge-mode diff-mode magit-core magit-autorevert autorevert filenotify
magit-process magit-margin magit-mode git-commit magit-git magit-section
magit-utils magit-popup crm log-edit easy-mmode message rmc puny dired
dired-loaddefs format-spec rfc822 mml mml-sec epa derived epg gnus-util
rmail rmail-loaddefs time-date mm-decode mm-bodies mm-encode mail-parse
rfc2231 rfc2047 rfc2045 mm-util ietf-drums mail-prsvr mailabbrev
mail-utils gmm-utils mailheader pcvs-util add-log with-editor cl-extra
help-mode async-bytecomp advice async shell pcomplete comint ansi-color
ring server dash finder-inf info rx package easymenu epg-config
url-handlers url-parse auth-source cl-seq eieio eieio-core cl-macs
eieio-loaddefs password-cache url-vars seq byte-opt gv bytecomp
byte-compile cconv cl-loaddefs cl-lib erlang-start mule-util 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 menu-bar rfn-eshadow isearch timer
select scroll-bar mouse jit-lock font-lock syntax facemenu font-core
term/tty-colors frame 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 minibuffer cl-preloaded nadvice loaddefs
button faces cus-face macroexp files text-properties overlay sha1 md5
base64 format env code-pages mule custom widget hashtable-print-readable
backquote dbusbind inotify lcms2 dynamic-setting system-font-setting
font-render-setting move-toolbar gtk x-toolkit x multi-tty
make-network-process emacs)
Memory information:
((conses 16 1432347 1227349)
(symbols 48 89818 0)
(miscs 40 8985 8359)
(strings 32 329044 135987)
(string-bytes 1 22119338)
(vectors 16 130522)
(vector-slots 8 3038737 167354)
(floats 8 731 3073)
(intervals 56 75576 3438)
(buffers 992 292))
^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#37530: 26.1; Tack characters translated incorrectly
2019-09-26 21:31 bug#37530: 26.1; Tack characters translated incorrectly Axel Svensson
@ 2019-09-27 5:26 ` Eli Zaretskii
2019-09-27 10:37 ` Axel Svensson
` (2 more replies)
0 siblings, 3 replies; 26+ messages in thread
From: Eli Zaretskii @ 2019-09-27 5:26 UTC (permalink / raw)
To: Axel Svensson; +Cc: 37530
> From: Axel Svensson <mail@axelsvensson.com>
> Date: Thu, 26 Sep 2019 23:31:34 +0200
>
> Press C-h l to run view-lossage.
> The last lines display the erroneous characters that were inserted,
> rather than the expected characters.
> ⊣ [self-insert-command]
> ⊢ [self-insert-command]
> ⊥ [self-insert-command]
> ⊤ [self-insert-command]
> C-h l [view-lossage]
>
> In order to confirm that the behavior I have stated as expected is the
> correct one, look to the XKB keysym definitions:
> > #define XKB_KEY_downtack 0x0bc2 /* U+22A4 DOWN TACK */
> > #define XKB_KEY_uptack 0x0bce /* U+22A5 UP TACK */
> > #define XKB_KEY_lefttack 0x0bdc /* U+22A3 LEFT TACK */
> > #define XKB_KEY_righttack 0x0bfc /* U+22A2 RIGHT TACK */
> These can be found at:
> https://github.com/xkbcommon/libxkbcommon/blob/master/xkbcommon/xkbcommon-keysyms.h
>
> It is understandable that bugs like these can go unnoticed seeing that
> these characters probably aren't part of any widely used keyboard
> layout. If this bug can be confirmed, and depending on what caused it,
> it might be beneficial to add the complete mapping from X11 keysyms to
> Unicode codepoints as automated tests. I'm willing to provide this
> mapping, including source references.
Isn't the output of "C-h l" evidence that Emacs actually received the
codepoints it displayed? IOW, how do we know this is a problem in
Emacs and not in the keyboard configuration and/or driver software?
Thanks.
^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#37530: 26.1; Tack characters translated incorrectly
2019-09-27 5:26 ` Eli Zaretskii
@ 2019-09-27 10:37 ` Axel Svensson
2019-09-27 13:15 ` Eli Zaretskii
2019-09-27 13:03 ` Lars Ingebrigtsen
2019-09-27 13:32 ` Lars Ingebrigtsen
2 siblings, 1 reply; 26+ messages in thread
From: Axel Svensson @ 2019-09-27 10:37 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 37530
On Fri, Sep 27, 2019, 07:27 Eli Zaretskii <eliz@gnu.org> wrote:
>
> Isn't the output of "C-h l" evidence that Emacs actually received the
> codepoints it displayed? IOW, how do we know this is a problem in
> Emacs and not in the keyboard configuration and/or driver software?
>
> Thanks.
Good point. The following tests confirm that the mistranslation is in
Emacs, and specifically in its handling of X11 events, and not in the
setup:
- Install xdotool (On debian, `apt-get install xdotool`)
- In order to test an application's tack character interpretation:
- In a terminal, run:
sleep 3; xdotool \
key --delay 500 uptack \
key --delay 500 downtack \
key --delay 500 lefttack \
key --delay 500 righttack
- Quickly switch focus to the application you want to test
- Wait 5 seconds
- Investigate the effect in the application. If the application is
such that it attempts to display characters that are inputted via
the keyboard, it should display the string "⊥⊤⊣⊢".
On my setup, the following are the results of using the test above for
emacs, compared to a few other applications:
- GNU Emacs 26.1 started with -Q:
The string "⊤⊥⊢⊣" is displayed, which is wrong.
- Gnome Terminal 3.30.2:
The string "⊥⊤⊣⊢" is displayed, as expected.
- GNU Emacs 26.1 started with -Q -nw under Gnome Terminal 3.30.2:
The string "⊥⊤⊣⊢" is displayed, as expected.
- Chromium 73, with focus in the address bar:
The string "⊥⊤⊣⊢" is displayed, as expected.
- Firefox 60.8.0esr 64-bit, with focus in the address bar:
The string "⊥⊤⊣⊢" is displayed, as expected.
- xterm:
No characters are displayed.
- xev (in package xutils, x11-utils, or similar):
This application prints debugging information for X11 events. See
the output below. It confirms that the setup is sending correct key
events. However, XLookupString refuses to translate the keysym to a
utf-8 string. I believe this might mean that it is up to the
applications to find a way to translate the keysyms, and can explain
why some applications do not display any characters. However, it does
not explain why emacs displays the wrong characters.
===== Begin relevant part of xev output =====
MappingNotify event, serial 32, synthetic NO, window 0x0,
request MappingKeyboard, first_keycode 123, count 1
MappingNotify event, serial 32, synthetic NO, window 0x0,
request MappingKeyboard, first_keycode 123, count 1
MappingNotify event, serial 32, synthetic NO, window 0x0,
request MappingKeyboard, first_keycode 123, count 1
MappingNotify event, serial 32, synthetic NO, window 0x0,
request MappingKeyboard, first_keycode 123, count 1
KeyPress event, serial 36, synthetic NO, window 0x2c00001,
root 0x388, subw 0x0, time 141855379, (513,324), root:(516,777),
state 0x0, keycode 123 (keysym 0xbce, uptack), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False
MappingNotify event, serial 36, synthetic NO, window 0x0,
request MappingKeyboard, first_keycode 123, count 1
MappingNotify event, serial 36, synthetic NO, window 0x0,
request MappingKeyboard, first_keycode 123, count 1
MappingNotify event, serial 36, synthetic NO, window 0x0,
request MappingKeyboard, first_keycode 123, count 1
MappingNotify event, serial 36, synthetic NO, window 0x0,
request MappingKeyboard, first_keycode 123, count 1
MappingNotify event, serial 36, synthetic NO, window 0x0,
request MappingKeyboard, first_keycode 123, count 1
MappingNotify event, serial 36, synthetic NO, window 0x0,
request MappingKeyboard, first_keycode 123, count 1
MappingNotify event, serial 36, synthetic NO, window 0x0,
request MappingKeyboard, first_keycode 123, count 1
MappingNotify event, serial 36, synthetic NO, window 0x0,
request MappingKeyboard, first_keycode 123, count 1
KeyRelease event, serial 36, synthetic NO, window 0x2c00001,
root 0x388, subw 0x0, time 141855632, (513,324), root:(516,777),
state 0x0, keycode 123 (keysym 0xbce, uptack), same_screen YES,
XLookupString gives 0 bytes:
XFilterEvent returns: False
MappingNotify event, serial 44, synthetic NO, window 0x0,
request MappingKeyboard, first_keycode 123, count 1
MappingNotify event, serial 44, synthetic NO, window 0x0,
request MappingKeyboard, first_keycode 123, count 1
MappingNotify event, serial 44, synthetic NO, window 0x0,
request MappingKeyboard, first_keycode 123, count 1
MappingNotify event, serial 44, synthetic NO, window 0x0,
request MappingKeyboard, first_keycode 123, count 1
MappingNotify event, serial 44, synthetic NO, window 0x0,
request MappingKeyboard, first_keycode 123, count 1
MappingNotify event, serial 44, synthetic NO, window 0x0,
request MappingKeyboard, first_keycode 123, count 1
MappingNotify event, serial 44, synthetic NO, window 0x0,
request MappingKeyboard, first_keycode 123, count 1
MappingNotify event, serial 44, synthetic NO, window 0x0,
request MappingKeyboard, first_keycode 123, count 1
KeyPress event, serial 44, synthetic NO, window 0x2c00001,
root 0x388, subw 0x0, time 141855885, (513,324), root:(516,777),
state 0x0, keycode 123 (keysym 0xbc2, downtack), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False
MappingNotify event, serial 52, synthetic NO, window 0x0,
request MappingKeyboard, first_keycode 123, count 1
MappingNotify event, serial 52, synthetic NO, window 0x0,
request MappingKeyboard, first_keycode 123, count 1
MappingNotify event, serial 52, synthetic NO, window 0x0,
request MappingKeyboard, first_keycode 123, count 1
MappingNotify event, serial 52, synthetic NO, window 0x0,
request MappingKeyboard, first_keycode 123, count 1
MappingNotify event, serial 52, synthetic NO, window 0x0,
request MappingKeyboard, first_keycode 123, count 1
MappingNotify event, serial 52, synthetic NO, window 0x0,
request MappingKeyboard, first_keycode 123, count 1
MappingNotify event, serial 52, synthetic NO, window 0x0,
request MappingKeyboard, first_keycode 123, count 1
MappingNotify event, serial 52, synthetic NO, window 0x0,
request MappingKeyboard, first_keycode 123, count 1
KeyRelease event, serial 52, synthetic NO, window 0x2c00001,
root 0x388, subw 0x0, time 141856137, (513,324), root:(516,777),
state 0x0, keycode 123 (keysym 0xbc2, downtack), same_screen YES,
XLookupString gives 0 bytes:
XFilterEvent returns: False
MappingNotify event, serial 60, synthetic NO, window 0x0,
request MappingKeyboard, first_keycode 123, count 1
MappingNotify event, serial 60, synthetic NO, window 0x0,
request MappingKeyboard, first_keycode 123, count 1
MappingNotify event, serial 60, synthetic NO, window 0x0,
request MappingKeyboard, first_keycode 123, count 1
MappingNotify event, serial 60, synthetic NO, window 0x0,
request MappingKeyboard, first_keycode 123, count 1
MappingNotify event, serial 60, synthetic NO, window 0x0,
request MappingKeyboard, first_keycode 123, count 1
MappingNotify event, serial 60, synthetic NO, window 0x0,
request MappingKeyboard, first_keycode 123, count 1
MappingNotify event, serial 60, synthetic NO, window 0x0,
request MappingKeyboard, first_keycode 123, count 1
MappingNotify event, serial 60, synthetic NO, window 0x0,
request MappingKeyboard, first_keycode 123, count 1
KeyPress event, serial 60, synthetic NO, window 0x2c00001,
root 0x388, subw 0x0, time 141856392, (513,324), root:(516,777),
state 0x0, keycode 123 (keysym 0xbdc, lefttack), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False
MappingNotify event, serial 68, synthetic NO, window 0x0,
request MappingKeyboard, first_keycode 123, count 1
MappingNotify event, serial 68, synthetic NO, window 0x0,
request MappingKeyboard, first_keycode 123, count 1
MappingNotify event, serial 68, synthetic NO, window 0x0,
request MappingKeyboard, first_keycode 123, count 1
MappingNotify event, serial 68, synthetic NO, window 0x0,
request MappingKeyboard, first_keycode 123, count 1
MappingNotify event, serial 68, synthetic NO, window 0x0,
request MappingKeyboard, first_keycode 123, count 1
MappingNotify event, serial 68, synthetic NO, window 0x0,
request MappingKeyboard, first_keycode 123, count 1
MappingNotify event, serial 68, synthetic NO, window 0x0,
request MappingKeyboard, first_keycode 123, count 1
MappingNotify event, serial 68, synthetic NO, window 0x0,
request MappingKeyboard, first_keycode 123, count 1
KeyRelease event, serial 68, synthetic NO, window 0x2c00001,
root 0x388, subw 0x0, time 141856643, (513,324), root:(516,777),
state 0x0, keycode 123 (keysym 0xbdc, lefttack), same_screen YES,
XLookupString gives 0 bytes:
XFilterEvent returns: False
MappingNotify event, serial 76, synthetic NO, window 0x0,
request MappingKeyboard, first_keycode 123, count 1
MappingNotify event, serial 76, synthetic NO, window 0x0,
request MappingKeyboard, first_keycode 123, count 1
MappingNotify event, serial 76, synthetic NO, window 0x0,
request MappingKeyboard, first_keycode 123, count 1
MappingNotify event, serial 76, synthetic NO, window 0x0,
request MappingKeyboard, first_keycode 123, count 1
MappingNotify event, serial 76, synthetic NO, window 0x0,
request MappingKeyboard, first_keycode 123, count 1
MappingNotify event, serial 76, synthetic NO, window 0x0,
request MappingKeyboard, first_keycode 123, count 1
MappingNotify event, serial 76, synthetic NO, window 0x0,
request MappingKeyboard, first_keycode 123, count 1
MappingNotify event, serial 76, synthetic NO, window 0x0,
request MappingKeyboard, first_keycode 123, count 1
KeyPress event, serial 76, synthetic NO, window 0x2c00001,
root 0x388, subw 0x0, time 141856898, (513,324), root:(516,777),
state 0x0, keycode 123 (keysym 0xbfc, righttack), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False
MappingNotify event, serial 84, synthetic NO, window 0x0,
request MappingKeyboard, first_keycode 123, count 1
MappingNotify event, serial 84, synthetic NO, window 0x0,
request MappingKeyboard, first_keycode 123, count 1
MappingNotify event, serial 84, synthetic NO, window 0x0,
request MappingKeyboard, first_keycode 123, count 1
MappingNotify event, serial 84, synthetic NO, window 0x0,
request MappingKeyboard, first_keycode 123, count 1
MappingNotify event, serial 84, synthetic NO, window 0x0,
request MappingKeyboard, first_keycode 123, count 1
MappingNotify event, serial 84, synthetic NO, window 0x0,
request MappingKeyboard, first_keycode 123, count 1
MappingNotify event, serial 84, synthetic NO, window 0x0,
request MappingKeyboard, first_keycode 123, count 1
MappingNotify event, serial 84, synthetic NO, window 0x0,
request MappingKeyboard, first_keycode 123, count 1
KeyRelease event, serial 92, synthetic NO, window 0x2c00001,
root 0x388, subw 0x0, time 141857162, (513,324), root:(516,777),
state 0x0, keycode 123 (keysym 0xbfc, righttack), same_screen YES,
XLookupString gives 0 bytes:
XFilterEvent returns: False
MappingNotify event, serial 92, synthetic NO, window 0x0,
request MappingKeyboard, first_keycode 123, count 1
MappingNotify event, serial 92, synthetic NO, window 0x0,
request MappingKeyboard, first_keycode 123, count 1
MappingNotify event, serial 92, synthetic NO, window 0x0,
request MappingKeyboard, first_keycode 123, count 1
MappingNotify event, serial 92, synthetic NO, window 0x0,
request MappingKeyboard, first_keycode 123, count 1
FocusOut event, serial 96, synthetic NO, window 0x2c00001,
mode NotifyGrab, detail NotifyNonlinear
===== End relevant part of xev output =====
^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#37530: 26.1; Tack characters translated incorrectly
2019-09-27 5:26 ` Eli Zaretskii
2019-09-27 10:37 ` Axel Svensson
@ 2019-09-27 13:03 ` Lars Ingebrigtsen
2019-09-27 13:32 ` Lars Ingebrigtsen
2 siblings, 0 replies; 26+ messages in thread
From: Lars Ingebrigtsen @ 2019-09-27 13:03 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Axel Svensson, 37530
Eli Zaretskii <eliz@gnu.org> writes:
> Isn't the output of "C-h l" evidence that Emacs actually received the
> codepoints it displayed? IOW, how do we know this is a problem in
> Emacs and not in the keyboard configuration and/or driver software?
I've always wondered how Emacs actually does this thing, but have never
had a peek, so I rummaged around in keyboard.c for a bit. If I'm
reading the code right, we get an event, and then pick out the
symbol_num from that (and that's probably they keycode in X parlance),
and then we end up here (under X):
/* Convert a keysym to its name. */
char *
get_keysym_name (int keysym)
{
char *value;
block_input ();
value = XKeysymToString (keysym);
unblock_input ();
return value;
}
But I'm a bit lost in how that name is translated into a character.
Uhm... OK, there's a hash table called x-keysym-table.
(format "%x" (gethash #x0bc2 x-keysym-table))
=> "22a5"
> > #define XKB_KEY_downtack 0x0bc2 /* U+22A4 DOWN TACK */
> > #define XKB_KEY_uptack 0x0bce /* U+22A5 UP TACK */
> > #define XKB_KEY_lefttack 0x0bdc /* U+22A3 LEFT TACK */
> > #define XKB_KEY_righttack 0x0bfc /* U+22A2 RIGHT TACK */
And that's wrong, according to the bug reporter. Now where does that
come from? Some grepping shows w-win.el:
;; Table from Kuhn's proposed additions to the `KEYSYM Encoding'
;; appendix to the X protocol definition.
(dolist
...
(#xbc2 . ?⊥)
Oh, there it is.
Character code properties: customize what to show
name: UP TACK
general-category: Sm (Symbol, Math)
decomposition: (8869) ('⊥')
So we've got some wrong data in x-win.el?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#37530: 26.1; Tack characters translated incorrectly
2019-09-27 10:37 ` Axel Svensson
@ 2019-09-27 13:15 ` Eli Zaretskii
2019-09-27 13:17 ` Axel Svensson
0 siblings, 1 reply; 26+ messages in thread
From: Eli Zaretskii @ 2019-09-27 13:15 UTC (permalink / raw)
To: Axel Svensson; +Cc: 37530
> From: Axel Svensson <mail@axelsvensson.com>
> Date: Fri, 27 Sep 2019 12:37:29 +0200
> Cc: 37530@debbugs.gnu.org
>
> - GNU Emacs 26.1 started with -Q:
> The string "⊤⊥⊢⊣" is displayed, which is wrong.
> - Gnome Terminal 3.30.2:
> The string "⊥⊤⊣⊢" is displayed, as expected.
> - GNU Emacs 26.1 started with -Q -nw under Gnome Terminal 3.30.2:
> The string "⊥⊤⊣⊢" is displayed, as expected.
> - Chromium 73, with focus in the address bar:
> The string "⊥⊤⊣⊢" is displayed, as expected.
> - Firefox 60.8.0esr 64-bit, with focus in the address bar:
> The string "⊥⊤⊣⊢" is displayed, as expected.
Looks like this is due to the list in x-win.el, which starts on line
320 there. Can someone proofread that list and see if we have other
similar problems? It looks our data was taken from here:
https://www.cl.cam.ac.uk/~mgk25/ucs/keysyms.pdf
^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#37530: 26.1; Tack characters translated incorrectly
2019-09-27 13:15 ` Eli Zaretskii
@ 2019-09-27 13:17 ` Axel Svensson
0 siblings, 0 replies; 26+ messages in thread
From: Axel Svensson @ 2019-09-27 13:17 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 37530
On Fri, Sep 27, 2019 at 3:16 PM Eli Zaretskii <eliz@gnu.org> wrote:
> Looks like this is due to the list in x-win.el, which starts on line
> 320 there. Can someone proofread that list and see if we have other
> similar problems? It looks our data was taken from here:
>
> https://www.cl.cam.ac.uk/~mgk25/ucs/keysyms.pdf
I'm on it.
^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#37530: 26.1; Tack characters translated incorrectly
2019-09-27 5:26 ` Eli Zaretskii
2019-09-27 10:37 ` Axel Svensson
2019-09-27 13:03 ` Lars Ingebrigtsen
@ 2019-09-27 13:32 ` Lars Ingebrigtsen
2019-09-27 13:44 ` Eli Zaretskii
2019-09-27 14:10 ` Axel Svensson
2 siblings, 2 replies; 26+ messages in thread
From: Lars Ingebrigtsen @ 2019-09-27 13:32 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Axel Svensson, 37530
The following patch updates out map with the data from the .h file:
(setq map
(let ((map nil))
(with-temp-buffer
(insert-file-contents "/usr/include/xkbcommon/xkbcommon-keysyms.h")
(while (re-search-forward "#define +XKB_KEY.*0x\\([a-fA-Z0-9]+\\).*U\\+\\([a-fA-Z0-9]+\\)" nil t)
(push (cons (string-to-number (match-string 1) 16)
(string-to-number (match-string 2) 16))
map)))
(nreverse map)))
Does this look OK to everybody?
In addition, there's a huge number of keysyms in that file that we do
not do mappings to characters for. Hm... but those are all over
#x1000174, so I guess they're mapped to Unicode code points directly?
/* Keysyms directly mapped to Unicode characters. */
if (keysym >= 0x01000000 && keysym <= 0x0110FFFF)
*counts digits*
Yeah, that seems correct, I guess?
diff --git a/lisp/term/x-win.el b/lisp/term/x-win.el
index 56061371fe..119cd3d0a9 100644
--- a/lisp/term/x-win.el
+++ b/lisp/term/x-win.el
@@ -822,8 +822,8 @@ vendor-specific-keysyms
(#xab7 . ?⅚)
(#xab8 . ?℅)
(#xabb . ?‒)
- (#xabc . ?〈)
- (#xabe . ?〉)
+ (#xabc . ?⟨)
+ (#xabe . ?⟩)
(#xac3 . ?⅛)
(#xac4 . ?⅜)
(#xac5 . ?⅝)
@@ -883,20 +883,20 @@ vendor-specific-keysyms
(#xba8 . ?∨)
(#xba9 . ?∧)
(#xbc0 . ?¯)
- (#xbc2 . ?⊥)
+ (#xbc2 . ?⊤)
(#xbc3 . ?∩)
(#xbc4 . ?⌊)
(#xbc6 . ?_)
(#xbca . ?∘)
(#xbcc . ?⎕)
- (#xbce . ?⊤)
+ (#xbce . ?⊥)
(#xbcf . ?○)
(#xbd3 . ?⌈)
(#xbd6 . ?∪)
(#xbd8 . ?⊃)
(#xbda . ?⊂)
- (#xbdc . ?⊢)
- (#xbfc . ?⊣)
+ (#xbdc . ?⊣)
+ (#xbfc . ?⊢)
;; Hebrew
(#xcdf . ?‗)
(#xce0 . ?א)
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
^ permalink raw reply related [flat|nested] 26+ messages in thread
* bug#37530: 26.1; Tack characters translated incorrectly
2019-09-27 13:32 ` Lars Ingebrigtsen
@ 2019-09-27 13:44 ` Eli Zaretskii
2019-09-27 13:50 ` Lars Ingebrigtsen
2019-09-27 14:10 ` Axel Svensson
1 sibling, 1 reply; 26+ messages in thread
From: Eli Zaretskii @ 2019-09-27 13:44 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: mail, 37530
> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Axel Svensson <mail@axelsvensson.com>, 37530@debbugs.gnu.org
> Date: Fri, 27 Sep 2019 15:32:30 +0200
>
> The following patch updates out map with the data from the .h file:
>
> (setq map
> (let ((map nil))
> (with-temp-buffer
> (insert-file-contents "/usr/include/xkbcommon/xkbcommon-keysyms.h")
> (while (re-search-forward "#define +XKB_KEY.*0x\\([a-fA-Z0-9]+\\).*U\\+\\([a-fA-Z0-9]+\\)" nil t)
> (push (cons (string-to-number (match-string 1) 16)
> (string-to-number (match-string 2) 16))
> map)))
> (nreverse map)))
>
> Does this look OK to everybody?
Sorry, this is not enough. We cannot blindly use some alternative
source, especially as the other source was determined to be
inaccurate. How do we know that header file is accurate? (And what
is the license of that file, btw?)
I'd like someone to do the research and find out why Markus Kuhn's
suggestions were changed. I'd like also to state the source of the
data and the information about the change reason(s) in x-win.el, where
we have the mapping.
> In addition, there's a huge number of keysyms in that file that we do
> not do mappings to characters for. Hm... but those are all over
> #x1000174, so I guess they're mapped to Unicode code points directly?
>
> /* Keysyms directly mapped to Unicode characters. */
> if (keysym >= 0x01000000 && keysym <= 0x0110FFFF)
To answer the question, one needs to compare the keysyms with the
corresponding codepoints. If they are identical, then the mapping is
trivial.
Thanks.
^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#37530: 26.1; Tack characters translated incorrectly
2019-09-27 13:44 ` Eli Zaretskii
@ 2019-09-27 13:50 ` Lars Ingebrigtsen
2019-09-27 13:59 ` Eli Zaretskii
0 siblings, 1 reply; 26+ messages in thread
From: Lars Ingebrigtsen @ 2019-09-27 13:50 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: mail, 37530
Eli Zaretskii <eliz@gnu.org> writes:
> Sorry, this is not enough. We cannot blindly use some alternative
> source, especially as the other source was determined to be
> inaccurate. How do we know that header file is accurate? (And what
> is the license of that file, btw?)
The X license.
> I'd like someone to do the research and find out why Markus Kuhn's
> suggestions were changed. I'd like also to state the source of the
> data and the information about the change reason(s) in x-win.el, where
> we have the mapping.
If somebody wants to do that research, be my guest. I don't see the
point -- this is the data the X server uses, so it's authoritative.
>> In addition, there's a huge number of keysyms in that file that we do
>> not do mappings to characters for. Hm... but those are all over
>> #x1000174, so I guess they're mapped to Unicode code points directly?
>>
>> /* Keysyms directly mapped to Unicode characters. */
>> if (keysym >= 0x01000000 && keysym <= 0x0110FFFF)
>
> To answer the question, one needs to compare the keysyms with the
> corresponding codepoints. If they are identical, then the mapping is
> trivial.
I don't understand what you mean. The comment says that the keysyms in
the 0x01000000 to 0x0110FFFF range map directly to code points. What is
there to compare?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#37530: 26.1; Tack characters translated incorrectly
2019-09-27 13:50 ` Lars Ingebrigtsen
@ 2019-09-27 13:59 ` Eli Zaretskii
2019-09-27 14:03 ` Lars Ingebrigtsen
2019-09-27 14:18 ` Axel Svensson
0 siblings, 2 replies; 26+ messages in thread
From: Eli Zaretskii @ 2019-09-27 13:59 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: mail, 37530
> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: mail@axelsvensson.com, 37530@debbugs.gnu.org
> Date: Fri, 27 Sep 2019 15:50:47 +0200
>
> > I'd like someone to do the research and find out why Markus Kuhn's
> > suggestions were changed. I'd like also to state the source of the
> > data and the information about the change reason(s) in x-win.el, where
> > we have the mapping.
>
> If somebody wants to do that research, be my guest. I don't see the
> point -- this is the data the X server uses, so it's authoritative.
I'd like to hear more opinions, please.
> >> /* Keysyms directly mapped to Unicode characters. */
> >> if (keysym >= 0x01000000 && keysym <= 0x0110FFFF)
> >
> > To answer the question, one needs to compare the keysyms with the
> > corresponding codepoints. If they are identical, then the mapping is
> > trivial.
>
> I don't understand what you mean. The comment says that the keysyms in
> the 0x01000000 to 0x0110FFFF range map directly to code points. What is
> there to compare?
Perhaps I've misunderstood where the code was taken from. You didn't
say.
^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#37530: 26.1; Tack characters translated incorrectly
2019-09-27 13:59 ` Eli Zaretskii
@ 2019-09-27 14:03 ` Lars Ingebrigtsen
2019-09-27 14:18 ` Axel Svensson
1 sibling, 0 replies; 26+ messages in thread
From: Lars Ingebrigtsen @ 2019-09-27 14:03 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: mail, 37530
Eli Zaretskii <eliz@gnu.org> writes:
> Perhaps I've misunderstood where the code was taken from. You didn't
> say.
It's in xterm.c in handle_one_xevent.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#37530: 26.1; Tack characters translated incorrectly
2019-09-27 13:32 ` Lars Ingebrigtsen
2019-09-27 13:44 ` Eli Zaretskii
@ 2019-09-27 14:10 ` Axel Svensson
2019-09-27 14:19 ` Lars Ingebrigtsen
2019-09-27 14:25 ` Eli Zaretskii
1 sibling, 2 replies; 26+ messages in thread
From: Axel Svensson @ 2019-09-27 14:10 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: 37530
On Fri, Sep 27, 2019 at 3:33 PM Lars Ingebrigtsen <larsi@gnus.org> wrote:
> In addition, there's a huge number of keysyms in that file that we do
> not do mappings to characters for. Hm... but those are all over
> #x1000174, so I guess they're mapped to Unicode code points directly?
I found three more keysyms missing:
#define XKB_KEY_Ukrainian_ghe_with_upturn 0x06ad /* U+0491
CYRILLIC SMALL LETTER GHE WITH UPTURN */
#define XKB_KEY_Ukrainian_GHE_WITH_UPTURN 0x06bd /* U+0490
CYRILLIC CAPITAL LETTER GHE WITH UPTURN */
#define XKB_KEY_permille 0x0ad5 /* U+2030 PER
MILLE SIGN */
This is according to
https://github.com/xkbcommon/libxkbcommon/blob/master/xkbcommon/xkbcommon-keysyms.h
> - (#xabc . ?〈)
> - (#xabe . ?〉)
> + (#xabc . ?⟨)
> + (#xabe . ?⟩)
What is the source for this change? Why would you change
left/right-pointing brackets for the mathematical ones, in the section
for publishing?
> - (#xbc2 . ?⊥)
> + (#xbc2 . ?⊤)
> (#xbc3 . ?∩)
> (#xbc4 . ?⌊)
> (#xbc6 . ?_)
> (#xbca . ?∘)
> (#xbcc . ?⎕)
> - (#xbce . ?⊤)
> + (#xbce . ?⊥)
> (#xbcf . ?○)
> (#xbd3 . ?⌈)
> (#xbd6 . ?∪)
> (#xbd8 . ?⊃)
> (#xbda . ?⊂)
> - (#xbdc . ?⊢)
> - (#xbfc . ?⊣)
> + (#xbdc . ?⊣)
> + (#xbfc . ?⊢)
I agree.
^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#37530: 26.1; Tack characters translated incorrectly
2019-09-27 13:59 ` Eli Zaretskii
2019-09-27 14:03 ` Lars Ingebrigtsen
@ 2019-09-27 14:18 ` Axel Svensson
1 sibling, 0 replies; 26+ messages in thread
From: Axel Svensson @ 2019-09-27 14:18 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Lars Ingebrigtsen, 37530
On Fri, Sep 27, 2019 at 3:59 PM Eli Zaretskii <eliz@gnu.org> wrote:
> > > I'd like someone to do the research and find out why Markus Kuhn's
> > > suggestions were changed. I'd like also to state the source of the
> > > data and the information about the change reason(s) in x-win.el, where
> > > we have the mapping.
> >
> > If somebody wants to do that research, be my guest. I don't see the
> > point -- this is the data the X server uses, so it's authoritative.
>
> I'd like to hear more opinions, please.
>
My opinion is that keysym mappings that aren't part of the
authoritative X11 source should still be added.
Motivation: IIUC, X11 clients primarily receive keysyms, not code
points. How the translation is done is then up to the application.
Many applications do this translation using an application-internal
mapping (like indeed Emacs is) without necessarily referring to
whatever is present on the OS. These mappings, drawing from several
sources, have few if any conflicts. Therefore, the sensible,
pragmatic, common and expected thing to do is to attempt to translate
them rather than ignore them, even if they aren't present in the
source files on the OS in question. If Emacs receives a key event with
a certain keysym, the user clearly expects the application to do
something with it.
^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#37530: 26.1; Tack characters translated incorrectly
2019-09-27 14:10 ` Axel Svensson
@ 2019-09-27 14:19 ` Lars Ingebrigtsen
2019-09-27 14:57 ` Axel Svensson
2019-09-27 14:25 ` Eli Zaretskii
1 sibling, 1 reply; 26+ messages in thread
From: Lars Ingebrigtsen @ 2019-09-27 14:19 UTC (permalink / raw)
To: Axel Svensson; +Cc: 37530
Axel Svensson <mail@axelsvensson.com> writes:
>> - (#xabc . ?〈)
>> - (#xabe . ?〉)
>> + (#xabc . ?⟨)
>> + (#xabe . ?⟩)
>
> What is the source for this change? Why would you change
> left/right-pointing brackets for the mathematical ones, in the section
> for publishing?
Let's see... it's this:
#define XKB_KEY_leftanglebracket 0x0abc /*(U+27E8 MATHEMATICAL LEFT ANGLE BRACKET)*/
#define XKB_KEY_rightanglebracket 0x0abe /*(U+27E9 MATHEMATICAL RIGHT ANGLE BRACKET)*/
Does your xkeysyms have this differently?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#37530: 26.1; Tack characters translated incorrectly
2019-09-27 14:10 ` Axel Svensson
2019-09-27 14:19 ` Lars Ingebrigtsen
@ 2019-09-27 14:25 ` Eli Zaretskii
2019-09-27 14:48 ` Axel Svensson
1 sibling, 1 reply; 26+ messages in thread
From: Eli Zaretskii @ 2019-09-27 14:25 UTC (permalink / raw)
To: Axel Svensson; +Cc: larsi, 37530
> From: Axel Svensson <mail@axelsvensson.com>
> Date: Fri, 27 Sep 2019 16:10:20 +0200
> Cc: Eli Zaretskii <eliz@gnu.org>, 37530@debbugs.gnu.org
>
> I found three more keysyms missing:
> #define XKB_KEY_Ukrainian_ghe_with_upturn 0x06ad /* U+0491
> CYRILLIC SMALL LETTER GHE WITH UPTURN */
> #define XKB_KEY_Ukrainian_GHE_WITH_UPTURN 0x06bd /* U+0490
> CYRILLIC CAPITAL LETTER GHE WITH UPTURN */
> #define XKB_KEY_permille 0x0ad5 /* U+2030 PER
> MILLE SIGN */
> This is according to
> https://github.com/xkbcommon/libxkbcommon/blob/master/xkbcommon/xkbcommon-keysyms.h
Do we know, or can find out, since what version of X are these
mappings in effect? I think we should consider whether the version
where this appeared is old enough for us to use this unconditionally.
^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#37530: 26.1; Tack characters translated incorrectly
2019-09-27 14:25 ` Eli Zaretskii
@ 2019-09-27 14:48 ` Axel Svensson
2019-09-27 15:30 ` Eli Zaretskii
0 siblings, 1 reply; 26+ messages in thread
From: Axel Svensson @ 2019-09-27 14:48 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Lars Ingebrigtsen, 37530
On Fri, Sep 27, 2019 at 4:25 PM Eli Zaretskii <eliz@gnu.org> wrote:
> Do we know, or can find out, since what version of X are these
> mappings in effect? I think we should consider whether the version
> where this appeared is old enough for us to use this unconditionally.
Otherwise, what condition should there be to use them, and why?
If a key event arrives with these keysyms, what else could they possibly mean?
^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#37530: 26.1; Tack characters translated incorrectly
2019-09-27 14:19 ` Lars Ingebrigtsen
@ 2019-09-27 14:57 ` Axel Svensson
0 siblings, 0 replies; 26+ messages in thread
From: Axel Svensson @ 2019-09-27 14:57 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: 37530
On Fri, Sep 27, 2019 at 4:19 PM Lars Ingebrigtsen <larsi@gnus.org> wrote:
> #define XKB_KEY_leftanglebracket 0x0abc /*(U+27E8 MATHEMATICAL LEFT ANGLE BRACKET)*/
> #define XKB_KEY_rightanglebracket 0x0abe /*(U+27E9 MATHEMATICAL RIGHT ANGLE BRACKET)*/
>
> Does your xkeysyms have this differently?
No, my bad.
In summary, these are the changes I believe should be made:
#define XKB_KEY_Ukrainian_ghe_with_upturn 0x06ad /* U+0491
CYRILLIC SMALL LETTER GHE WITH UPTURN */
#define XKB_KEY_Ukrainian_GHE_WITH_UPTURN 0x06bd /* U+0490
CYRILLIC CAPITAL LETTER GHE WITH UPTURN */
#define XKB_KEY_signifblank 0x0aac /*(U+2423 OPEN BOX)*/
#define XKB_KEY_leftanglebracket 0x0abc /*(U+27E8
MATHEMATICAL LEFT ANGLE BRACKET)*/
#define XKB_KEY_decimalpoint 0x0abd /*(U+002E FULL STOP)*/
#define XKB_KEY_rightanglebracket 0x0abe /*(U+27E9
MATHEMATICAL RIGHT ANGLE BRACKET)*/
#define XKB_KEY_permille 0x0ad5 /* U+2030 PER
MILLE SIGN */
#define XKB_KEY_downtack 0x0bc2 /* U+22A4 DOWN TACK */
#define XKB_KEY_uptack 0x0bce /* U+22A5 UP TACK */
#define XKB_KEY_lefttack 0x0bdc /* U+22A3 LEFT TACK */
#define XKB_KEY_righttack 0x0bfc /* U+22A2 RIGHT TACK */
Also, I found another discrepancy that seems like an error on XKB side:
#define XKB_KEY_approxeq 0x1002248 /* U+2245 ALMOST
EQUAL TO */
^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#37530: 26.1; Tack characters translated incorrectly
2019-09-27 14:48 ` Axel Svensson
@ 2019-09-27 15:30 ` Eli Zaretskii
2019-09-27 17:19 ` Axel Svensson
0 siblings, 1 reply; 26+ messages in thread
From: Eli Zaretskii @ 2019-09-27 15:30 UTC (permalink / raw)
To: Axel Svensson; +Cc: larsi, 37530
> From: Axel Svensson <mail@axelsvensson.com>
> Date: Fri, 27 Sep 2019 16:48:46 +0200
> Cc: Lars Ingebrigtsen <larsi@gnus.org>, 37530@debbugs.gnu.org
>
> On Fri, Sep 27, 2019 at 4:25 PM Eli Zaretskii <eliz@gnu.org> wrote:
> > Do we know, or can find out, since what version of X are these
> > mappings in effect? I think we should consider whether the version
> > where this appeared is old enough for us to use this unconditionally.
>
> Otherwise, what condition should there be to use them, and why?
> If a key event arrives with these keysyms, what else could they possibly mean?
I thought that older versions might perhaps assign different mappings
to the same keysyms. If they don't assign any mappings, then I agree
with you.
^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#37530: 26.1; Tack characters translated incorrectly
2019-09-27 15:30 ` Eli Zaretskii
@ 2019-09-27 17:19 ` Axel Svensson
2019-09-27 18:35 ` Eli Zaretskii
0 siblings, 1 reply; 26+ messages in thread
From: Axel Svensson @ 2019-09-27 17:19 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Lars Ingebrigtsen, 37530
[-- Attachment #1: Type: text/plain, Size: 1599 bytes --]
On Fri, Sep 27, 2019 at 5:33 PM Eli Zaretskii <eliz@gnu.org> wrote:
> I thought that older versions might perhaps assign different mappings
> to the same keysyms. If they don't assign any mappings, then I agree
> with you.
XKB lists quite a few keysyms as deprecated, but no keysyms we have
discussed here are affected.
I believe this indicates that they have never been used for another
mapping previously, but I haven't checked extensively.
However, it is also stated in xkbcommon-keysyms.h that:
> * Where the correspondence is either not one-to-one or semantically
> * unclear, the Unicode position and name are enclosed in
> * parentheses. Such legacy keysyms should be considered deprecated
> * and are not recommended for use in future keyboard mappings.
This affects four of the keysyms mentioned:
> #define XKB_KEY_signifblank 0x0aac /*(U+2423 OPEN BOX)*/
> #define XKB_KEY_leftanglebracket 0x0abc /*(U+27E8 MATHEMATICAL LEFT ANGLE BRACKET)*/
> #define XKB_KEY_decimalpoint 0x0abd /*(U+002E FULL STOP)*/
> #define XKB_KEY_rightanglebracket 0x0abe /*(U+27E9 MATHEMATICAL RIGHT ANGLE BRACKET)*/
For two of these keysyms, I managed to find at least one application
that agrees with the current Emacs mapping that we now consider
changing:
> {0xabc, 0x2329},
> {0xabe, 0x232a},
See https://fossies.org/dox/putty-src/xkeysym_8c_source.html
I believe that we should consider carefully whether changing these two
mappings could introduce a regression for some use case, e.g.
PuTTY/ssh/emacs.
My proposed changes are attached.
[-- Attachment #2: bug-37530.diff --]
[-- Type: text/x-patch, Size: 2895 bytes --]
diff --git a/lisp/term/x-win.el b/lisp/term/x-win.el
index 56061371fe..17bbbaeb12 100644
--- a/lisp/term/x-win.el
+++ b/lisp/term/x-win.el
@@ -579,6 +579,7 @@ as returned by `x-server-vendor'."
(#x6aa . ?њ)
(#x6ab . ?ћ)
(#x6ac . ?ќ)
+ (#x6ad . ?ґ) ;; Source: xkbcommon-keysyms.h
(#x6ae . ?ў)
(#x6af . ?џ)
(#x6b0 . ?№)
@@ -594,6 +595,7 @@ as returned by `x-server-vendor'."
(#x6ba . ?Њ)
(#x6bb . ?Ћ)
(#x6bc . ?Ќ)
+ (#x6bd . ?ґ) ;; Source: xkbcommon-keysyms.h
(#x6be . ?Ў)
(#x6bf . ?Џ)
(#x6c0 . ?ю)
@@ -810,6 +812,7 @@ as returned by `x-server-vendor'."
(#xaa8 . ? )
(#xaa9 . ?—)
(#xaaa . ?–)
+ (#xaac . ?␣) ;; Source: xkbcommon-keysyms.h
(#xaae . ?…)
(#xaaf . ?‥)
(#xab0 . ?⅓)
@@ -822,7 +825,15 @@ as returned by `x-server-vendor'."
(#xab7 . ?⅚)
(#xab8 . ?℅)
(#xabb . ?‒)
+ ;; In xkbcommon-keysyms.h, the keysyms 0xabc and 0xabe are listed as
+ ;; U+27E8 and U+27E9 respectively. However, the parenthesis indicate
+ ;; that these mappings are not one-to-one and that these keysyms are
+ ;; deprecated. In order to not introduce any incompatibility with
+ ;; possible existing workflows that expect these keysyms to map as they
+ ;; currently do, to 0x2329 and 0x232a, respectively, they are left as
+ ;; they are. In particular, PuTTY is known to agree with this mapping.
(#xabc . ?〈)
+ (#xabd . ?.) ;; Source: xkbcommon-keysyms.h
(#xabe . ?〉)
(#xac3 . ?⅛)
(#xac4 . ?⅜)
@@ -839,6 +850,7 @@ as returned by `x-server-vendor'."
(#xad2 . ?“)
(#xad3 . ?”)
(#xad4 . ?℞)
+ (#xad5 . ?‰) ;; Source: xkbcommon-keysyms.h
(#xad6 . ?′)
(#xad7 . ?″)
(#xad9 . ?✝)
@@ -883,20 +895,28 @@ as returned by `x-server-vendor'."
(#xba8 . ?∨)
(#xba9 . ?∧)
(#xbc0 . ?¯)
- (#xbc2 . ?⊥)
+ (#xbc2 . ?⊤)
+ ;; Source for #xbc2: xkbcommon-keysyms.h. Note that the
+ ;; `KEYSYM Encoding' appendix to the X protocol definition is incorrect.
(#xbc3 . ?∩)
(#xbc4 . ?⌊)
(#xbc6 . ?_)
(#xbca . ?∘)
(#xbcc . ?⎕)
- (#xbce . ?⊤)
+ (#xbce . ?⊥)
+ ;; Source for #xbce: xkbcommon-keysyms.h. Note that the
+ ;; `KEYSYM Encoding' appendix to the X protocol definition is incorrect.
(#xbcf . ?○)
(#xbd3 . ?⌈)
(#xbd6 . ?∪)
(#xbd8 . ?⊃)
(#xbda . ?⊂)
- (#xbdc . ?⊢)
- (#xbfc . ?⊣)
+ (#xbdc . ?⊣)
+ ;; Source for #xbdc: xkbcommon-keysyms.h. Note that the
+ ;; `KEYSYM Encoding' appendix to the X protocol definition is incorrect.
+ (#xbfc . ?⊢)
+ ;; Source for #xbfc: xkbcommon-keysyms.h. Note that the
+ ;; `KEYSYM Encoding' appendix to the X protocol definition is incorrect.
;; Hebrew
(#xcdf . ?‗)
(#xce0 . ?א)
@@ -1143,6 +1163,9 @@ as returned by `x-server-vendor'."
;; #x0aff CURSOR Publish
;; #x0dde THAI MAIHANAKAT Thai
+;; However, xkbcommon-keysyms.h do have mappings for #x0aac and #x0abd,
+;; which are used above.
+
\f
;;;; Selections
^ permalink raw reply related [flat|nested] 26+ messages in thread
* bug#37530: 26.1; Tack characters translated incorrectly
2019-09-27 17:19 ` Axel Svensson
@ 2019-09-27 18:35 ` Eli Zaretskii
2019-09-27 20:05 ` Axel Svensson
0 siblings, 1 reply; 26+ messages in thread
From: Eli Zaretskii @ 2019-09-27 18:35 UTC (permalink / raw)
To: Axel Svensson; +Cc: larsi, 37530
> From: Axel Svensson <mail@axelsvensson.com>
> Date: Fri, 27 Sep 2019 19:19:46 +0200
> Cc: Lars Ingebrigtsen <larsi@gnus.org>, 37530@debbugs.gnu.org
>
> For two of these keysyms, I managed to find at least one application
> that agrees with the current Emacs mapping that we now consider
> changing:
> > {0xabc, 0x2329},
> > {0xabe, 0x232a},
> See https://fossies.org/dox/putty-src/xkeysym_8c_source.html
>
> I believe that we should consider carefully whether changing these two
> mappings could introduce a regression for some use case, e.g.
> PuTTY/ssh/emacs.
>
> My proposed changes are attached.
Thank, I'd like to state in a comment the full file name of the header
file on a typical Posix host, and the version of X from which this
file came.
^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#37530: 26.1; Tack characters translated incorrectly
2019-09-27 18:35 ` Eli Zaretskii
@ 2019-09-27 20:05 ` Axel Svensson
2019-09-28 6:18 ` Eli Zaretskii
0 siblings, 1 reply; 26+ messages in thread
From: Axel Svensson @ 2019-09-27 20:05 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Lars Ingebrigtsen, 37530
On Fri, Sep 27, 2019 at 8:36 PM Eli Zaretskii <eliz@gnu.org> wrote:
> Thank, I'd like to state in a comment the full file name of the header
> file on a typical Posix host, and the version of X from which this
> file came.
I was working off of xkbcommon trunk.
The repo is at https://github.com/xkbcommon/libxkbcommon
Path in repo is xkbcommon/xkbcommon-keysyms.h
However, this file seems to be auto-generated from X11 system files
(outside of the repo).
It does seem that all the material we need is present in
/usr/include/X11/keysymdef.h
I'm not sure about the version though.
^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#37530: 26.1; Tack characters translated incorrectly
2019-09-27 20:05 ` Axel Svensson
@ 2019-09-28 6:18 ` Eli Zaretskii
2019-09-28 13:44 ` Axel Svensson
0 siblings, 1 reply; 26+ messages in thread
From: Eli Zaretskii @ 2019-09-28 6:18 UTC (permalink / raw)
To: Axel Svensson; +Cc: larsi, 37530
> From: Axel Svensson <mail@axelsvensson.com>
> Date: Fri, 27 Sep 2019 22:05:30 +0200
> Cc: Lars Ingebrigtsen <larsi@gnus.org>, 37530@debbugs.gnu.org
>
> On Fri, Sep 27, 2019 at 8:36 PM Eli Zaretskii <eliz@gnu.org> wrote:
> > Thank, I'd like to state in a comment the full file name of the header
> > file on a typical Posix host, and the version of X from which this
> > file came.
>
> I was working off of xkbcommon trunk.
> The repo is at https://github.com/xkbcommon/libxkbcommon
> Path in repo is xkbcommon/xkbcommon-keysyms.h
> However, this file seems to be auto-generated from X11 system files
> (outside of the repo).
> It does seem that all the material we need is present in
> /usr/include/X11/keysymdef.h
Yes, I think we need only to quote this last file name.
> I'm not sure about the version though.
Looks like the canonical way of finding out the version is
xdpyinfo | grep version
or maybe
X -version
Thanks.
^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#37530: 26.1; Tack characters translated incorrectly
2019-09-28 6:18 ` Eli Zaretskii
@ 2019-09-28 13:44 ` Axel Svensson
2019-09-28 14:12 ` Eli Zaretskii
0 siblings, 1 reply; 26+ messages in thread
From: Axel Svensson @ 2019-09-28 13:44 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Lars Ingebrigtsen, 37530
[-- Attachment #1: Type: text/plain, Size: 440 bytes --]
On Sat, Sep 28, 2019 at 8:18 AM Eli Zaretskii <eliz@gnu.org> wrote:
> Yes, I think we need only to quote this last file name.
Agree. New patch attached with AN ERROR CORRECTED and
comments/references improved.
BTW, in xorgproto (the source), the relevant portions of keysymdef.h
have been unchanged since 2012-02-20 (commit ab1fba1).
Beyond being authoritative, I think that could give us some confidence
that they are de-facto standard.
[-- Attachment #2: bug-37530-v2.diff --]
[-- Type: text/x-patch, Size: 3375 bytes --]
diff --git a/lisp/term/x-win.el b/lisp/term/x-win.el
index 56061371fe..d4681e3e9f 100644
--- a/lisp/term/x-win.el
+++ b/lisp/term/x-win.el
@@ -302,7 +302,11 @@ as returned by `x-server-vendor'."
(setq i (1+ i))))
;; Table from Kuhn's proposed additions to the `KEYSYM Encoding'
-;; appendix to the X protocol definition.
+;; appendix to the X protocol definition. As indicated, some of these
+;; have been corrected using information found in keysymdef.h which
+;; on a typical system is installed at /usr/include/X11/keysymdef.h. The
+;; version used here is from xorgproto version 2019.1 found here:
+;; https://gitlab.freedesktop.org/xorg/proto/xorgproto/blob/e0bba743ae7c549c58f92677b239ec7878548228/include/X11/keysymdef.h
(dolist
(pair
'(
@@ -579,6 +583,7 @@ as returned by `x-server-vendor'."
(#x6aa . ?њ)
(#x6ab . ?ћ)
(#x6ac . ?ќ)
+ (#x6ad . ?ґ) ;; Source: keysymdef.h
(#x6ae . ?ў)
(#x6af . ?џ)
(#x6b0 . ?№)
@@ -594,6 +599,7 @@ as returned by `x-server-vendor'."
(#x6ba . ?Њ)
(#x6bb . ?Ћ)
(#x6bc . ?Ќ)
+ (#x6bd . ?Ґ) ;; Source: keysymdef.h
(#x6be . ?Ў)
(#x6bf . ?Џ)
(#x6c0 . ?ю)
@@ -810,6 +816,7 @@ as returned by `x-server-vendor'."
(#xaa8 . ? )
(#xaa9 . ?—)
(#xaaa . ?–)
+ (#xaac . ?␣) ;; Source: keysymdef.h
(#xaae . ?…)
(#xaaf . ?‥)
(#xab0 . ?⅓)
@@ -822,7 +829,17 @@ as returned by `x-server-vendor'."
(#xab7 . ?⅚)
(#xab8 . ?℅)
(#xabb . ?‒)
+ ;; In keysymdef.h, the keysyms 0xabc and 0xabe are listed as
+ ;; U+27E8 and U+27E9 respectively. However, the parentheses
+ ;; indicate that these mappings are deprecated legacy keysyms
+ ;; that are either not one-to-one or semantically unclear. In
+ ;; order to not introduce any incompatibility with possible
+ ;; existing workflows that expect these keysyms to map as they
+ ;; currently do, to 0x2329 and 0x232a, respectively, they are
+ ;; left as they are. In particular, PuTTY is known to agree with
+ ;; this mapping.
(#xabc . ?〈)
+ (#xabd . ?.) ;; Source: keysymdef.h
(#xabe . ?〉)
(#xac3 . ?⅛)
(#xac4 . ?⅜)
@@ -839,6 +856,7 @@ as returned by `x-server-vendor'."
(#xad2 . ?“)
(#xad3 . ?”)
(#xad4 . ?℞)
+ (#xad5 . ?‰) ;; Source: keysymdef.h
(#xad6 . ?′)
(#xad7 . ?″)
(#xad9 . ?✝)
@@ -883,20 +901,29 @@ as returned by `x-server-vendor'."
(#xba8 . ?∨)
(#xba9 . ?∧)
(#xbc0 . ?¯)
- (#xbc2 . ?⊥)
+ ;; Source for #xbc2: keysymdef.h. Note that the
+ ;; `KEYSYM Encoding' appendix to the X protocol definition is
+ ;; incorrect.
+ (#xbc2 . ?⊤)
(#xbc3 . ?∩)
(#xbc4 . ?⌊)
(#xbc6 . ?_)
(#xbca . ?∘)
(#xbcc . ?⎕)
- (#xbce . ?⊤)
+ ;; Source for #xbce: keysymdef.h. Note that the
+ ;; `KEYSYM Encoding' appendix to the X protocol definition is
+ ;; incorrect.
+ (#xbce . ?⊥)
(#xbcf . ?○)
(#xbd3 . ?⌈)
(#xbd6 . ?∪)
(#xbd8 . ?⊃)
(#xbda . ?⊂)
- (#xbdc . ?⊢)
- (#xbfc . ?⊣)
+ ;; Source for #xbdc and #xbfc: keysymdef.h. Note that the
+ ;; `KEYSYM Encoding' appendix to the X protocol definition is
+ ;; incorrect.
+ (#xbdc . ?⊣)
+ (#xbfc . ?⊢)
;; Hebrew
(#xcdf . ?‗)
(#xce0 . ?א)
@@ -1143,6 +1170,9 @@ as returned by `x-server-vendor'."
;; #x0aff CURSOR Publish
;; #x0dde THAI MAIHANAKAT Thai
+;; However, keysymdef.h does have mappings for #x0aac and #x0abd, which
+;; are used above.
+
\f
;;;; Selections
^ permalink raw reply related [flat|nested] 26+ messages in thread
* bug#37530: 26.1; Tack characters translated incorrectly
2019-09-28 13:44 ` Axel Svensson
@ 2019-09-28 14:12 ` Eli Zaretskii
2019-09-28 14:30 ` Axel Svensson
0 siblings, 1 reply; 26+ messages in thread
From: Eli Zaretskii @ 2019-09-28 14:12 UTC (permalink / raw)
To: Axel Svensson; +Cc: larsi, 37530
> From: Axel Svensson <mail@axelsvensson.com>
> Date: Sat, 28 Sep 2019 15:44:01 +0200
> Cc: Lars Ingebrigtsen <larsi@gnus.org>, 37530@debbugs.gnu.org
>
> BTW, in xorgproto (the source), the relevant portions of keysymdef.h
> have been unchanged since 2012-02-20 (commit ab1fba1).
> Beyond being authoritative, I think that could give us some confidence
> that they are de-facto standard.
Right.
Thanks, I pushed the patch. A coupe of nits for the future:
. Our convention is to leave 2 spaces between sentences in
documentation and comments.
. Please accompany your changes with a ChangeLog-style commit log
message (see CONTRIBUTE for details). If a bug number is known,
please include it in the log message.
Finally, if you intend to contribute more changes to Emacs, I'd
encourage you to start your legal paperwork now, so that we will be
able to receive your contributions in the future (this contribution
was small enough to receive it without copyright assignment). I can
send you the form to fill and the instructions off-list, if you are
interested.
^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#37530: 26.1; Tack characters translated incorrectly
2019-09-28 14:12 ` Eli Zaretskii
@ 2019-09-28 14:30 ` Axel Svensson
2019-09-28 14:48 ` Eli Zaretskii
0 siblings, 1 reply; 26+ messages in thread
From: Axel Svensson @ 2019-09-28 14:30 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Lars Ingebrigtsen, 37530
On Sat, Sep 28, 2019 at 4:13 PM Eli Zaretskii <eliz@gnu.org> wrote:
> . Our convention is to leave 2 spaces between sentences in
> documentation and comments.
Noted. Are these conventions documented somewhere? For example, I was
unable to determine the exact line length convention.
> . Please accompany your changes with a ChangeLog-style commit log
> message (see CONTRIBUTE for details). If a bug number is known,
> please include it in the log message.
Thank you, noted.
>
> Finally, if you intend to contribute more changes to Emacs, I'd
> encourage you to start your legal paperwork now, so that we will be
> able to receive your contributions in the future (this contribution
> was small enough to receive it without copyright assignment). I can
> send you the form to fill and the instructions off-list, if you are
> interested.
Yes please.
^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#37530: 26.1; Tack characters translated incorrectly
2019-09-28 14:30 ` Axel Svensson
@ 2019-09-28 14:48 ` Eli Zaretskii
0 siblings, 0 replies; 26+ messages in thread
From: Eli Zaretskii @ 2019-09-28 14:48 UTC (permalink / raw)
To: Axel Svensson; +Cc: larsi, 37530
> From: Axel Svensson <mail@axelsvensson.com>
> Date: Sat, 28 Sep 2019 16:30:31 +0200
> Cc: Lars Ingebrigtsen <larsi@gnus.org>, 37530@debbugs.gnu.org
>
> On Sat, Sep 28, 2019 at 4:13 PM Eli Zaretskii <eliz@gnu.org> wrote:
> > . Our convention is to leave 2 spaces between sentences in
> > documentation and comments.
> Noted. Are these conventions documented somewhere? For example, I was
> unable to determine the exact line length convention.
Everything should be in CONTRIBUTE. The 2 spaces rule definitely is
there.
> > Finally, if you intend to contribute more changes to Emacs, I'd
> > encourage you to start your legal paperwork now, so that we will be
> > able to receive your contributions in the future (this contribution
> > was small enough to receive it without copyright assignment). I can
> > send you the form to fill and the instructions off-list, if you are
> > interested.
>
> Yes please.
Thanks, form sent off-list.
^ permalink raw reply [flat|nested] 26+ messages in thread
end of thread, other threads:[~2019-09-28 14:48 UTC | newest]
Thread overview: 26+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2019-09-26 21:31 bug#37530: 26.1; Tack characters translated incorrectly Axel Svensson
2019-09-27 5:26 ` Eli Zaretskii
2019-09-27 10:37 ` Axel Svensson
2019-09-27 13:15 ` Eli Zaretskii
2019-09-27 13:17 ` Axel Svensson
2019-09-27 13:03 ` Lars Ingebrigtsen
2019-09-27 13:32 ` Lars Ingebrigtsen
2019-09-27 13:44 ` Eli Zaretskii
2019-09-27 13:50 ` Lars Ingebrigtsen
2019-09-27 13:59 ` Eli Zaretskii
2019-09-27 14:03 ` Lars Ingebrigtsen
2019-09-27 14:18 ` Axel Svensson
2019-09-27 14:10 ` Axel Svensson
2019-09-27 14:19 ` Lars Ingebrigtsen
2019-09-27 14:57 ` Axel Svensson
2019-09-27 14:25 ` Eli Zaretskii
2019-09-27 14:48 ` Axel Svensson
2019-09-27 15:30 ` Eli Zaretskii
2019-09-27 17:19 ` Axel Svensson
2019-09-27 18:35 ` Eli Zaretskii
2019-09-27 20:05 ` Axel Svensson
2019-09-28 6:18 ` Eli Zaretskii
2019-09-28 13:44 ` Axel Svensson
2019-09-28 14:12 ` Eli Zaretskii
2019-09-28 14:30 ` Axel Svensson
2019-09-28 14:48 ` Eli Zaretskii
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).