GNU bug report logs - #24759
25.1.50; electric-quote-mode

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 24759 <at> debbugs.gnu.org
Subject: bug#24759: 25.1.50; electric-quote-mode
Date: Sun, 23 Oct 2016 10:13:20 +0300

> Cc: 24759 <at> debbugs.gnu.org
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> Date: Sat, 22 Oct 2016 21:10:08 -0700
> 
> Eli Zaretskii wrote:
> > Once we have tried all those defaults, and found they cannot do the
> > job, we've exhausted our potential of guessing "what the user wants"
> > reliably, so we must now ask the user to tell us that.
> 
> It is odd that Emacs uses UTF-8 without questions in the C locale, but prompts 
> and suggest a Chinese encoding in a unibyte French locale.

I tried to explain the logic behind this in another message.

> > It was like that since Emacs 20.1.  I don't see what changed now that
> > it's suddenly a problem.
> 
> Emacs is now more likely to have non-unibyte text, partly due to its fancier 
> quoting and partly because Unicode is more ubiquitous than it was in 1997 when 
> Emacs 20.1 was released. So the problem is more likely to occur now.

I'm not sure you are right (the original Emacs 20.x m17n was heavily
biased towards ISO-2022 encodings, which are multibyte), but I don't
think it matters.

> > If you are hinting that UTF-8 should come up first
> 
> UTF-8 should be the most-preferred multibyte encoding nowadays, unless there is 
> a reasonable indication that the user prefers something else.

What kind of indication do you have in mind?

> In a unibyte European locale, UTF-8 should be the first-listed
> multibyte encoding by default.

Why not list it the first always?  That sounds simpler to me, because
it doesn't require any guesswork about the user preferences beyond
what we do already.  The encoding we offer as the first alternative
now has nothing to do with user preferences, so why would we introduce
such preferences?

> > Most buffers will never be saved.
> 
> For buffers that don't correspond to files, we needn't bother with any of this 
> checking. But for buffers that correspond to files with restrictive encodings, 
> it would be helpful to warn users earlier rather than later about this sort of 
> problem.

First, buffers that correspond to files are not the only case where
this encoding prompt can pop up.  Text sent to a subprocess or to the
network (like this email message I'm typing) is another.

And second, I think you underestimate the annoyance that would result
from such prompting.  If the single prompt we now issue already annoys
you, it hardly makes sense to do the same multiple times.  It is
better to try to minimize the prompts by silently doing TRT whenever
we can.

> It's a bit like spelling checking.

It's not.  A mis-spelled buffer can be saved, but we cannot save a
buffer without knowing how to encode it.

Previous Next

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