* bug#7840: 23.2.91; default-terminal-coding-system not inherited by created terminals @ 2011-01-14 3:45 Eli Zaretskii 2011-01-14 15:33 ` Stefan Monnier 2011-02-13 0:18 ` bug#7840: SYMBOL_VALUE in terminal.c (was 23.2.91; default-terminal-coding-system not inherited by created terminals) Chong Yidong 0 siblings, 2 replies; 11+ messages in thread From: Eli Zaretskii @ 2011-01-14 3:45 UTC (permalink / raw) To: 7840 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) ^ permalink raw reply [flat|nested] 11+ messages in thread
* bug#7840: 23.2.91; default-terminal-coding-system not inherited by created terminals 2011-01-14 3:45 bug#7840: 23.2.91; default-terminal-coding-system not inherited by created terminals Eli Zaretskii @ 2011-01-14 15:33 ` Stefan Monnier 2011-02-12 9:55 ` Eli Zaretskii 2011-02-13 0:18 ` bug#7840: SYMBOL_VALUE in terminal.c (was 23.2.91; default-terminal-coding-system not inherited by created terminals) Chong Yidong 1 sibling, 1 reply; 11+ messages in thread From: Stefan Monnier @ 2011-01-14 15:33 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 7840 > 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* bug#7840: 23.2.91; default-terminal-coding-system not inherited by created terminals 2011-01-14 15:33 ` Stefan Monnier @ 2011-02-12 9:55 ` Eli Zaretskii 0 siblings, 0 replies; 11+ messages in thread From: Eli Zaretskii @ 2011-02-12 9:55 UTC (permalink / raw) To: Stefan Monnier; +Cc: 7840-done > From: Stefan Monnier <monnier@iro.umontreal.ca> > Cc: 7840@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. ^ permalink raw reply [flat|nested] 11+ messages in thread
* bug#7840: SYMBOL_VALUE in terminal.c (was 23.2.91; default-terminal-coding-system not inherited by created terminals) 2011-01-14 3:45 bug#7840: 23.2.91; default-terminal-coding-system not inherited by created terminals Eli Zaretskii 2011-01-14 15:33 ` Stefan Monnier @ 2011-02-13 0:18 ` Chong Yidong 2011-02-14 18:05 ` Stefan Monnier 1 sibling, 1 reply; 11+ messages in thread From: Chong Yidong @ 2011-02-13 0:18 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 7840 > 2011-02-12 Eli Zaretskii <eliz@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. ^ permalink raw reply [flat|nested] 11+ messages in thread
* bug#7840: SYMBOL_VALUE in terminal.c (was 23.2.91; default-terminal-coding-system not inherited by created terminals) 2011-02-13 0:18 ` bug#7840: SYMBOL_VALUE in terminal.c (was 23.2.91; default-terminal-coding-system not inherited by created terminals) Chong Yidong @ 2011-02-14 18:05 ` Stefan Monnier 2011-02-18 14:51 ` Eli Zaretskii 0 siblings, 1 reply; 11+ messages in thread From: Stefan Monnier @ 2011-02-14 18:05 UTC (permalink / raw) To: Chong Yidong; +Cc: 7840 >> * 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* bug#7840: SYMBOL_VALUE in terminal.c (was 23.2.91; default-terminal-coding-system not inherited by created terminals) 2011-02-14 18:05 ` Stefan Monnier @ 2011-02-18 14:51 ` Eli Zaretskii 2011-02-18 17:33 ` Stefan Monnier 0 siblings, 1 reply; 11+ messages in thread From: Eli Zaretskii @ 2011-02-18 14:51 UTC (permalink / raw) To: Stefan Monnier; +Cc: cyd, 7840 > From: Stefan Monnier <monnier@iro.umontreal.ca> > Cc: Eli Zaretskii <eliz@gnu.org>, 7840@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. ^ permalink raw reply [flat|nested] 11+ messages in thread
* bug#7840: SYMBOL_VALUE in terminal.c (was 23.2.91; default-terminal-coding-system not inherited by created terminals) 2011-02-18 14:51 ` Eli Zaretskii @ 2011-02-18 17:33 ` Stefan Monnier 2011-02-18 17:46 ` Eli Zaretskii 0 siblings, 1 reply; 11+ messages in thread From: Stefan Monnier @ 2011-02-18 17:33 UTC (permalink / raw) To: Eli Zaretskii; +Cc: cyd, 7840 > 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* bug#7840: SYMBOL_VALUE in terminal.c (was 23.2.91; default-terminal-coding-system not inherited by created terminals) 2011-02-18 17:33 ` Stefan Monnier @ 2011-02-18 17:46 ` Eli Zaretskii 2011-02-18 21:35 ` Stefan Monnier 0 siblings, 1 reply; 11+ messages in thread From: Eli Zaretskii @ 2011-02-18 17:46 UTC (permalink / raw) To: Stefan Monnier; +Cc: cyd, 7840 > From: Stefan Monnier <monnier@IRO.UMontreal.CA> > Cc: cyd@stupidchicken.com, 7840@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. ^ permalink raw reply [flat|nested] 11+ messages in thread
* bug#7840: SYMBOL_VALUE in terminal.c (was 23.2.91; default-terminal-coding-system not inherited by created terminals) 2011-02-18 17:46 ` Eli Zaretskii @ 2011-02-18 21:35 ` Stefan Monnier 2011-02-19 8:05 ` bug#7840: SYMBOL_VALUE in terminal.c Eli Zaretskii 0 siblings, 1 reply; 11+ messages in thread From: Stefan Monnier @ 2011-02-18 21:35 UTC (permalink / raw) To: Eli Zaretskii; +Cc: cyd, 7840 > 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* bug#7840: SYMBOL_VALUE in terminal.c 2011-02-18 21:35 ` Stefan Monnier @ 2011-02-19 8:05 ` Eli Zaretskii 2011-02-19 21:14 ` Stefan Monnier 0 siblings, 1 reply; 11+ messages in thread From: Eli Zaretskii @ 2011-02-19 8:05 UTC (permalink / raw) To: Stefan Monnier; +Cc: cyd, 7840 > From: Stefan Monnier <monnier@IRO.UMontreal.CA> > Cc: cyd@stupidchicken.com, 7840@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.) ^ permalink raw reply [flat|nested] 11+ messages in thread
* bug#7840: SYMBOL_VALUE in terminal.c 2011-02-19 8:05 ` bug#7840: SYMBOL_VALUE in terminal.c Eli Zaretskii @ 2011-02-19 21:14 ` Stefan Monnier 0 siblings, 0 replies; 11+ messages in thread From: Stefan Monnier @ 2011-02-19 21:14 UTC (permalink / raw) To: Eli Zaretskii; +Cc: cyd, 7840 > (Btw, I see several uses of `unbound' in Lisp files.) No worried, it's unrelated: the Qunbound symbol is not interned. Stefan ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2011-02-19 21:14 UTC | newest] Thread overview: 11+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2011-01-14 3:45 bug#7840: 23.2.91; default-terminal-coding-system not inherited by created terminals Eli Zaretskii 2011-01-14 15:33 ` Stefan Monnier 2011-02-12 9:55 ` Eli Zaretskii 2011-02-13 0:18 ` bug#7840: SYMBOL_VALUE in terminal.c (was 23.2.91; default-terminal-coding-system not inherited by created terminals) Chong Yidong 2011-02-14 18:05 ` Stefan Monnier 2011-02-18 14:51 ` Eli Zaretskii 2011-02-18 17:33 ` Stefan Monnier 2011-02-18 17:46 ` Eli Zaretskii 2011-02-18 21:35 ` Stefan Monnier 2011-02-19 8:05 ` bug#7840: SYMBOL_VALUE in terminal.c Eli Zaretskii 2011-02-19 21:14 ` Stefan Monnier
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.