[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#66825: last-coding-system-used in basic-save-buffer
From: |
Eli Zaretskii |
Subject: |
bug#66825: last-coding-system-used in basic-save-buffer |
Date: |
Mon, 30 Oct 2023 19:45:53 +0200 |
> From: Juri Linkov <juri@linkov.net>
> Cc: 66825@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.