GNU bug report logs - #7840
23.2.91; default-terminal-coding-system not inherited by created terminals

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 7840 in the body.
You can then email your comments to 7840 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: bug-gnu-emacs <at> gnu.org
Subject: 23.2.91;
	default-terminal-coding-system not inherited by created terminals
Date: Thu, 13 Jan 2011 22:45:57 -0500

I have this in my ~/.emacs:

    (set-terminal-coding-system 'utf-8)

This is supposed to set the value of default-terminal-coding-system,
and it indeed does.  However, creating a new terminal, e.g. with
"emacsclient -t" when an Emacs daemon is running, does not set the
terminal encoding of the newly created terminal to utf-8.  I don't see
any code that attempts doing so; the only place where we do anything
with the terminal encoding is in create_terminal:

  terminal->keyboard_coding =
    (struct coding_system *) xmalloc (sizeof (struct coding_system));
  terminal->terminal_coding =
    (struct coding_system *) xmalloc (sizeof (struct coding_system));

  setup_coding_system (Qno_conversion, terminal->keyboard_coding);
  setup_coding_system (Qundecided, terminal->terminal_coding);

The net effect is that the user _must_ manually set up the terminal
and keyboard encoding on every terminal created by emacsclient.  I
think that's a misfeature.

Any reason not to honor default-terminal-coding-system and
default-keyboard-coding-system when we create a new terminal?


In GNU Emacs 23.2.91.1 (x86_64-unknown-linux-gnu, GTK+ Version 2.12.9)
 of 2010-12-11 on fencepost
configured using `configure  '--with-jpeg=no' '--with-gif=no' '--with-tiff=no''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  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: nil
  value of $XMODIFIERS: nil
  locale-coding-system: nil
  default enable-multibyte-characters: t

Major mode: Mail

Minor modes in effect:
  flyspell-mode: t
  display-time-mode: t
  show-paren-mode: t
  savehist-mode: t
  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

Recent input:
u c t SPC t e r m i n a l C-r C-r C-r C-r C-r C-r ESC 
[ 6 ~ ESC [ 6 ~ ESC O B ESC O B ESC O B ESC O B ESC 
O B ESC O B ESC O B ESC O B ESC O B ESC O B ESC O B 
ESC O B ESC O B ESC O B ESC O B ESC O B ESC O D ESC 
O D ESC O D ESC O D ESC x g r e p RET C-a f C-e ESC 
O B DEL c RET ESC C-v ESC C-v ESC C-v ESC C-v ESC C-v 
ESC C-v ESC C-v ESC C-v ESC C-v C-x o ESC [ 5 ~ ESC 
[ 5 ~ ESC O B ESC O A ESC O A ESC O A ESC O A ESC O 
A ESC O B ESC O B ESC O A RET C-x b I N B TAB RET C-x 
4 C-o ESC O A C-e TAB - TAB RET ESC : ( t e r m i n 
a l - c o d i n g - s y s t e m ) RET ESC p ESC p ESC 
p SPC SPC C-x C-c ESC [ > 0 ; 1 3 6 ; 0 c C-x b RET 
ESC : ESC O A RET C-x RET t ESC O A RET C-l ESC : ESC 
O A RET C-x 2 C-x 4 C-o ESC O A ESC O A RET C-x 0 C-x 
4 b RET C-u 9 C-x ^ ESC x r e p o C-h C-g C-g r ESC 
~ C-x 5 o C-x 5 0 ESC x r e p o r t - e m TAB RET

Recent messages:
Mark set
utf-8
(No files need saving)
When done with this frame, type C-x 5 0
nil
utf-8
Quit [2 times]
Modification-flag cleared
Scanning for dabbrevs...100%
dabbrev-expand: No dynamic expansion for `default-ter' found

Load-path shadows:
None found.

Features:
(shadow emacsbug debug gud easy-mmode grep compile comint ring
find-func pp help-mode view help-fns multi-isearch vc-bzr cc-mode
cc-fonts cc-menus cc-cmds cc-styles cc-align cc-engine cc-vars cc-defs
arc-mode archive-mode newcomment dabbrev flyspell ispell rmailsum
rmailmm message sendmail regexp-opt ecomplete rfc822 mml easymenu
mml-sec password-cache mm-decode mm-bodies mm-encode mailcap
mailabbrev nnheader gnus-util netrc gmm-utils wid-edit mailheader
canlock sha1 hex-util hashcash mail-parse rfc2231 rmail rfc2047
rfc2045 ietf-drums time-date qp mm-util mail-prsvr mail-utils server
time paren cus-start cus-load savehist saveplace 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 font-render-setting gtk x-toolkit x multi-tty
emacs)

Message #8 received at 7840 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 7840 <at> debbugs.gnu.org
Subject: Re: bug#7840: 23.2.91;
	default-terminal-coding-system not inherited by created terminals
Date: Fri, 14 Jan 2011 10:33:30 -0500

> Any reason not to honor default-terminal-coding-system and
> default-keyboard-coding-system when we create a new terminal?

Probably a simple oversight.


        Stefan

Message #13 received at 7840-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 7840-done <at> debbugs.gnu.org
Subject: Re: bug#7840: 23.2.91;
	default-terminal-coding-system not inherited by created terminals
Date: Sat, 12 Feb 2011 11:55:28 +0200

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: 7840 <at> debbugs.gnu.org
> Date: Fri, 14 Jan 2011 10:33:30 -0500
> 
> > Any reason not to honor default-terminal-coding-system and
> > default-keyboard-coding-system when we create a new terminal?
> 
> Probably a simple oversight.

Fixed by revision 100466 on the emacs-23 branch.

Message #16 received at 7840 <at> debbugs.gnu.org (full text, mbox):

From: Chong Yidong <cyd <at> stupidchicken.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, 7840 <at> debbugs.gnu.org
Subject: SYMBOL_VALUE in terminal.c (was 23.2.91;
	default-terminal-coding-system not inherited by created terminals)
Date: Sat, 12 Feb 2011 19:18:45 -0500

> 2011-02-12  Eli Zaretskii  <eliz <at> gnu.org>

> 	* terminal.c (create_terminal): Use default-keyboard-coding-system
> 	and default-terminal-coding-system to initialize coding systems of
> 	the new terminal.  (Bug#7840)
>
> !   keyboard_coding = SYMBOL_VALUE (intern ("default-keyboard-coding-system"));
> !   if (NILP (keyboard_coding)
> !       || EQ (keyboard_coding, Qunbound)
> !       || NILP (Fcoding_system_p (keyboard_coding)))
> !     keyboard_coding = Qno_conversion;
> !   terminal_coding = SYMBOL_VALUE (intern ("default-terminal-coding-system"));

This change doesn't build on the trunk, due to Stefan's 2010-04-20
change removing SYMBOL_VALUE.

I left out this change when doing the last merge from the branch.  Would
you mind working up a separate patch and applying it to the trunk?
(Fsymbol_value apparently doesn't work here, because the symbols can be
unbound and we don't want to signal an error.)

Thanks.

Message #19 received at 7840 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Chong Yidong <cyd <at> stupidchicken.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 7840 <at> debbugs.gnu.org
Subject: Re: SYMBOL_VALUE in terminal.c (was 23.2.91;
	default-terminal-coding-system not inherited by created terminals)
Date: Mon, 14 Feb 2011 13:05:44 -0500

>> * terminal.c (create_terminal): Use default-keyboard-coding-system
>> and default-terminal-coding-system to initialize coding systems of
>> the new terminal.  (Bug#7840)
>> 
>> !   keyboard_coding = SYMBOL_VALUE (intern ("default-keyboard-coding-system"));
>> !   if (NILP (keyboard_coding)
>> !       || EQ (keyboard_coding, Qunbound)
>> !       || NILP (Fcoding_system_p (keyboard_coding)))
>> !     keyboard_coding = Qno_conversion;
>> !   terminal_coding = SYMBOL_VALUE (intern ("default-terminal-coding-system"));

> This change doesn't build on the trunk, due to Stefan's 2010-04-20
> change removing SYMBOL_VALUE.

> I left out this change when doing the last merge from the branch.  Would
> you mind working up a separate patch and applying it to the trunk?
> (Fsymbol_value apparently doesn't work here, because the symbols can be
> unbound and we don't want to signal an error.)

We can just use Fboundp tests, when needed.


        Stefan

Message #22 received at 7840 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: cyd <at> stupidchicken.com, 7840 <at> debbugs.gnu.org
Subject: Re: SYMBOL_VALUE in terminal.c (was 23.2.91;
	default-terminal-coding-system not inherited by created terminals)
Date: Fri, 18 Feb 2011 16:51:13 +0200

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: Eli Zaretskii <eliz <at> gnu.org>,  7840 <at> debbugs.gnu.org
> Date: Mon, 14 Feb 2011 13:05:44 -0500
> 
> >> * terminal.c (create_terminal): Use default-keyboard-coding-system
> >> and default-terminal-coding-system to initialize coding systems of
> >> the new terminal.  (Bug#7840)
> >> 
> >> !   keyboard_coding = SYMBOL_VALUE (intern ("default-keyboard-coding-system"));
> >> !   if (NILP (keyboard_coding)
> >> !       || EQ (keyboard_coding, Qunbound)
> >> !       || NILP (Fcoding_system_p (keyboard_coding)))
> >> !     keyboard_coding = Qno_conversion;
> >> !   terminal_coding = SYMBOL_VALUE (intern ("default-terminal-coding-system"));
> 
> > This change doesn't build on the trunk, due to Stefan's 2010-04-20
> > change removing SYMBOL_VALUE.
> 
> > I left out this change when doing the last merge from the branch.  Would
> > you mind working up a separate patch and applying it to the trunk?
> > (Fsymbol_value apparently doesn't work here, because the symbols can be
> > unbound and we don't want to signal an error.)
> 
> We can just use Fboundp tests, when needed.

I used find_symbol_value instead, which seems to be the Emacs 24
equivalent of SYMBOL_VALUE in this situation.

Committed to the trunk.

Message #25 received at 7840 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: cyd <at> stupidchicken.com, 7840 <at> debbugs.gnu.org
Subject: Re: SYMBOL_VALUE in terminal.c (was 23.2.91;
	default-terminal-coding-system not inherited by created terminals)
Date: Fri, 18 Feb 2011 12:33:29 -0500

> I used find_symbol_value instead, which seems to be the Emacs 24
> equivalent of SYMBOL_VALUE in this situation.

Yes, both of them are undesirable since they're internal functions used
to implement Fsymbol_value.  Better use Fsymbol_value and Fboundp.


        Stefan

Message #28 received at 7840 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Cc: cyd <at> stupidchicken.com, 7840 <at> debbugs.gnu.org
Subject: Re: SYMBOL_VALUE in terminal.c (was 23.2.91;
	default-terminal-coding-system not inherited by created terminals)
Date: Fri, 18 Feb 2011 19:46:55 +0200

> From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
> Cc: cyd <at> stupidchicken.com, 7840 <at> debbugs.gnu.org
> Date: Fri, 18 Feb 2011 12:33:29 -0500
> 
> > I used find_symbol_value instead, which seems to be the Emacs 24
> > equivalent of SYMBOL_VALUE in this situation.
> 
> Yes, both of them are undesirable since they're internal functions used
> to implement Fsymbol_value.  Better use Fsymbol_value and Fboundp.

But find_symbol_value is used in quite a few places elsewhere in
Emacs.  That's why I thought it was kosher to use.  And
create_terminal is hardly a place where internal functions are
inappropriate to use, isn't it?

I also don't understand the "internal function" argument: it sounds
TRT to have a function that just fetches a symbol's value, without
signaling an error if it is unbound.  Fsymbol_value, as it is now, is
clearly coded for interactive use, which this isn't.

In any case, if you want people to avoid these APIs, please explain
more why you dislike them, because so far it is utterly unclear, at
least to me.

Message #31 received at 7840 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: cyd <at> stupidchicken.com, 7840 <at> debbugs.gnu.org
Subject: Re: SYMBOL_VALUE in terminal.c (was 23.2.91;
	default-terminal-coding-system not inherited by created terminals)
Date: Fri, 18 Feb 2011 16:35:18 -0500

> I also don't understand the "internal function" argument: it sounds
> TRT to have a function that just fetches a symbol's value, without
> signaling an error if it is unbound.  Fsymbol_value, as it is now, is
> clearly coded for interactive use, which this isn't.

You mean "Lisp use" rather than "interactive", right?

> In any case, if you want people to avoid these APIs, please explain
> more why you dislike them, because so far it is utterly unclear, at
> least to me.

Basically Emacs variables provide
get/set/letbind/unbind/boundp/make-local/makunbound and everything else
is internal.  Any code which is not directly related to implementing
that functionality should go through those entry points, IMO.

find_symbol_value is the least harmful of the internal functions,
indeed, but it still requires extra care from the caller since it can
return Qunbound which is a value which should never escape to Lisp code.


        Stefan

Message #34 received at 7840 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Cc: cyd <at> stupidchicken.com, 7840 <at> debbugs.gnu.org
Subject: Re: SYMBOL_VALUE in terminal.c
Date: Sat, 19 Feb 2011 10:05:36 +0200

> From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
> Cc: cyd <at> stupidchicken.com, 7840 <at> debbugs.gnu.org
> Date: Fri, 18 Feb 2011 16:35:18 -0500
> 
> > I also don't understand the "internal function" argument: it sounds
> > TRT to have a function that just fetches a symbol's value, without
> > signaling an error if it is unbound.  Fsymbol_value, as it is now, is
> > clearly coded for interactive use, which this isn't.
> 
> You mean "Lisp use" rather than "interactive", right?

No, I mean "interactive", as "in the context of some interactive API
call".  By contrast, create_terminal runs during Emacs initialization,
when there's no one to signal a useful error to.

If there were a way to have Fsymbol_value return nil instead of
signaling an error, or any other way to get at a symbol's value while
suppressing errors, I'd use that.  find_symbol_value looked just like
such an interface.

> > In any case, if you want people to avoid these APIs, please explain
> > more why you dislike them, because so far it is utterly unclear, at
> > least to me.
> 
> Basically Emacs variables provide
> get/set/letbind/unbind/boundp/make-local/makunbound and everything else
> is internal.  Any code which is not directly related to implementing
> that functionality should go through those entry points, IMO.

The entry points you mention are Lisp APIs.  Low-level C code would
need to jump through the hoops to use them safely, especially if it
runs during periods when the Emacs session is not yet fully set up.

> find_symbol_value is the least harmful of the internal functions,
> indeed, but it still requires extra care from the caller since it can
> return Qunbound which is a value which should never escape to Lisp code.

Checking the value in advance with Funboundp needs the same level of
care.  And all Fsymbol_value does is call find_symbol_value and then
signal an error if the result is Qunbound.  I really don't see the
difference, unless you are planning some significant change in the
implementation of Fsymbol_value VSN.

(Btw, I see several uses of `unbound' in Lisp files.)

Message #37 received at 7840 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: cyd <at> stupidchicken.com, 7840 <at> debbugs.gnu.org
Subject: Re: SYMBOL_VALUE in terminal.c
Date: Sat, 19 Feb 2011 16:14:43 -0500

> (Btw, I see several uses of `unbound' in Lisp files.)

No worried, it's unrelated: the Qunbound symbol is not interned.


        Stefan

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.