bug#18890: 23.4; current-input-mode differs whether or not -t/-c switch was passed to emacsclient

bug#18890: 23.4; current-input-mode differs whether or not -t/-c switch was passed to emacsclient

[Raphaël Droz]

First I run the emacs daemon:
$ emacs -Q --daemon

I happen to be using fr/latin9 eeepc keyboard where
the ë character is obtained through a dead key.
ë = ¨ e = Shift-^ e

### what work as expected
If I use
$ emacsclient -a '' -t anyfile.txt
to edit a file.
Pressing ë (Shift-^ e) outputs the desired character (ë)

In that case:
> M-x describe-key:
> > (self-insert-command N)

> M-: (terminal-parameters)
> > ((normal-erase-is-backspace . 0) (background-mode . dark) (keyboard-coding-saved-meta-mode t) (terminal-initted . terminal-init-rxvt))

> M-: (current-input-mode)
> > (t nil 0 7)

The behavior is the same when using:
$ emacsclient -a '' -c anyfile.txt
with the only exception that a new window is created instead of using
text-mode/virtual-terminal based emacs.



### what does *not* work as expected
If I use
$ emacsclient -a '' anyfile.txt
to edit a file (notice the absence of -t/-c switch)

Pressing ë (Shift-^ e) has the same effect as (capitalize-word ARG) (!)
In that case:
> M-x describe-key:
> > It is bound to M-c. (capitalize-word ARG)

> M-: (terminal-parameters)
> > ((normal-erase-is-backspace . 0) (background-mode . dark) (terminal-initted . terminal-init-rxvt)

> M-: (current-input-mode)
> > (t nil t 7)

Also note that:
> M-: (set-terminal-parameter nil 'keyboard-coding-saved-meta-mode t)
didn't change the behavior *but*

> M-: (set-input-meta-mode 8)
changed the behavior to the expected one (as with -t/-c)
(although keyboard-coding-saved-meta-mode is not set to "t" as a consequence)



A last thing, if an emacsclient -t is run first, then successive
call to emacsclient without -t nor -c will just change to buffer in the
already existing frame.
As this frame was created using -t, dead keys will behave normally.
The opposite can't be tested since I can't "join" an existing frame
created without any of -t nor -c.


First question:
why these -t/-c switches (which are only about frame and buffer), change
the way dead keys / meta-mode are setup ?
= Isn't this a bug ?

Side question: is forcing (set-input-meta-mode 8) in my ~/.emacs the
right fix or just a workaround for a deeper problem ?



In GNU Emacs 23.4.1 (i486-pc-linux-gnu, GTK+ Version 2.24.10)
 of 2012-09-09 on murphy, modified by Debian
configured using `configure  '--build' 'i486-linux-gnu' '--build' 'i486-linux-gnu' '--prefix=/usr' '--sharedstatedir=/var/lib' '--libexecdir=/usr/lib' '--localstatedir=/var/lib' '--infodir=/usr/share/info' '--mandir=/usr/share/man' '--with-pop=yes' '--enable-locallisppath=/etc/emacs23:/etc/emacs:/usr/local/share/emacs/23.4/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/23.4/site-lisp:/usr/share/emacs/site-lisp' '--with-crt-dir=/usr/lib/i386-linux-gnu' '--with-x=yes' '--with-x-toolkit=gtk' '--with-toolkit-scroll-bars' 'build_alias=i486-linux-gnu' 'CFLAGS=-g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -Wall -DDEBIAN -O2' 'CPPFLAGS=-D_FORTIFY_SOURCE=2''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: C
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: fr_FR.UTF-8
  value of $XMODIFIERS: nil
  locale-coding-system: utf-8-unix
  default enable-multibyte-characters: t

Major mode: Fundamental

Minor modes in effect:
  tooltip-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent messages:


Load-path shadows:
/usr/share/emacs23/site-lisp/css-mode/css-mode hides /usr/share/emacs/site-lisp/css-mode/css-mode
/usr/share/emacs/23.4/site-lisp/debian-startup hides /usr/share/emacs/site-lisp/debian-startup
/usr/share/emacs/23.4/site-lisp/cmake-data/cmake-mode hides /usr/share/emacs/site-lisp/cmake-mode
/usr/share/emacs23/site-lisp/dictionaries-common/flyspell hides /usr/share/emacs/23.4/lisp/textmodes/flyspell
/usr/share/emacs23/site-lisp/dictionaries-common/ispell hides /usr/share/emacs/23.4/lisp/textmodes/ispell
/usr/share/emacs23/site-lisp/css-mode/css-mode hides /usr/share/emacs/23.4/lisp/textmodes/css-mode

Features:
(shadow sort mail-extr message sendmail regexp-opt ecomplete rfc822 mml
mml-sec password-cache mm-decode mm-bodies mm-encode mailcap mail-parse
rfc2231 rfc2047 rfc2045 qp ietf-drums mailabbrev nnheader gnus-util
netrc time-date mm-util mail-prsvr gmm-utils wid-edit mailheader canlock
sha1 hex-util hashcash mail-utils emacsbug help-mode easymenu view debug
server debian-el debian-el-loaddefs emacs-goodies-el
emacs-goodies-custom emacs-goodies-loaddefs easy-mmode dpkg-dev-el
dpkg-dev-el-loaddefs tooltip ediff-hook vc-hooks lisp-float-type mwheel
x-win x-dnd font-setting tool-bar dnd fontset image fringe lisp-mode
register page menu-bar rfn-eshadow timer select scroll-bar mldrag mouse
jit-lock font-lock syntax facemenu font-core frame cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese case-table epa-hook jka-cmpr-hook help simple abbrev
loaddefs button minibuffer faces cus-face files text-properties overlay
md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote make-network-process dbusbind
system-font-setting font-render-setting gtk x-toolkit x multi-tty emacs)

bug#18890: 23.4; current-input-mode differs whether or not -t/-c switch was passed to emacsclient

[Raphaël Droz]

I found that after emacsclient -a '' is run, there were 2 ways to
restore a correct dead keys behavior:

1)
M-: (set-input-meta-mode 8)

2)
M-: (set-terminal-parameter nil 'keyboard-coding-saved-meta-mode t)
followed by
M-: (set-keyboard-coding-system 'utf-8)

But these does *not* have any effect when set inside my ~/.emacs
I initially though that because they were run too soon, or too late in
relation to loading mule.el
I was wrong in my previous email about the fact that adding
"(set-input-meta-mode 8)" to ~/.emacs solved the issue, it didn't.


After a deeper look it happens that (set-terminal-parameter) expect a
"terminal" argument.
It makes me think that the relation to emacsclient switches managing
terminal could be not so far.

By the way, still trying to localize the origin of the issue and finding
a viable ~/.emacs workaround.