GNU bug report logs - #66825
last-coding-system-used in basic-save-buffer

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: 66825 <at> debbugs.gnu.org
Subject: bug#66825: last-coding-system-used in basic-save-buffer
Date: Mon, 30 Oct 2023 19:45:53 +0200

> From: Juri Linkov <juri <at> linkov.net>
> Cc: 66825 <at> debbugs.gnu.org
> Date: Mon, 30 Oct 2023 19:20:19 +0200
> 
> >>     message_with_string ((NUMBERP (append)
> >> 			  ? "Updated %s"
> >> 			  : ! NILP (append)
> >> 			  ? "Added to %s"
> >> 			  : "Wrote %s"),
> >> 			 visit_file, 1);
> >
> > How does message_with_string update the mode line?
> 
> I'm not know, some deeper function needs to update the mode line
> when the multi-line message resizes the echo area.

I think it's because message_with_string eventually calls redisplay,
and redisplay updates the mode line as part of its job.

> > And why does last-coding-system-used get set to raw-text-unix in this
> > scenario anyway?
> 
> Because send_process needs to set it to raw-text-unix for ispell:
> 
>   send_process (Lisp_Object proc, const char *buf, ptrdiff_t len, Lisp_Object object)
>   {
>     Vlast_coding_system_used = CODING_ID_NAME (coding->id);

I think this happens because the string sent to the speller is a
plain-ASCII string, and those are almost always unibyte strings.

So I think the local binding of last-coding-system-used around the
call to project-mode-line is TRT, it just needs a better comment to
explain why it's needed.

I think this should also teach us a lesson: calling arbitrary complex
code from mode-line's :eval forms is in general risky business and
should be avoided as much as possible.

Previous Next

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