bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#24759: 25.1.50; electric-quote-mode


From: Eli Zaretskii
Subject: bug#24759: 25.1.50; electric-quote-mode
Date: Sun, 23 Oct 2016 11:51:50 +0300

> Cc: 24759@debbugs.gnu.org
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Sun, 23 Oct 2016 01:24:15 -0700
> 
> > What kind of indication do you have in mind?
> 
> A locale that uses some non-UTF-8 multibyte encoding.

It isn't clear that this will help.  If that locale's encoding can
encode the offending characters, Emacs will already use it silently
without any prompts.  Beyond that, inferring a preference for some
non-UTF-8 encoding from the fact that the locale's encoding is
multibyte and not UTF-8 sounds far-fetched to me.

> >> In a unibyte European locale, UTF-8 should be the first-listed
> >> multibyte encoding by default.
> >
> > Why not list it the first always?
> 
> I wouldn't object. People who prefer non-UTF-8 multibyte locales might not 
> like 
> it (I'm not such a person so I can't say).

I don't think we should do this as the first approximation; we should
just make sure UTF-8 is the first in the list.  If later users will
complain about this, we could introduce a defcustom for such a "second
best" encoding, perhaps with a suitably guessed default value.  But I
wouldn't go there without specific requests and use cases.

> > If the single prompt we now issue already annoys
> > you, it hardly makes sense to do the same multiple times.
> 
> It's not merely the prompt that annoys me. It's that the prompt can occur 
> long 
> after the problem it diagnoses.

But the buffer we pop up clearly shows the problematic characters, and
also describes which of them couldn't be encoded with what
coding-systems that were tried.  So I think this provides enough
information for the user to decide what to do, and the fact that the
insertion happened much earlier doesn't matter, because the
information is not lost.  In particular, one of the valid reactions to
the prompt is to type C-g, then go to the buffer and delete/replace
the offending characters, and then try saving again.

> We could suppress the prompt in later occurrences if the user doesn't want to 
> see it again.

We could, but it's not a yes/no kind of answer, because the user might
not want to see another prompt for characters that require an encoding
she already saw, but might still want prompts for characters that
require other encodings.

For example, if I insert a Latin-1 character, I will be prompted and
decode I don't want to see prompts about any other characters that are
encodable with ISO-8859-1.  But if I later insert a character that
cannot be encoded with ISO-8859-1, I might still want to see the
prompt.

So I think this is a lot of hassle for something that works well in
practice for the past several years.  Changing it will most probably
open a can of worms (the current situation took several iterations to
get right).  So I'd rather we invest our efforts in silently doing TRT
in more use cases.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]