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

Previous Next

Full log

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

Previous Next

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