bug#24759: 25.1.50; electric-quote-mode

bug#24759: 25.1.50; electric-quote-mode

[Dani Moncayo]

Hello,

I may be missing something, but electric-quote-mode does not seem to
work here.

From `emacs -Q', if I create a new text-mode buffer

  C-x b foo
  M-x text-mode

then I enable electric quoting in that buffer

  M-x electric-quote-local-mode

and then I type [``foo''] or [`foo'], no quote conversion takes place.

Am I missing something?

TIA

In GNU Emacs 25.1.50.1 (i686-pc-mingw32)
 of 2016-10-19 built on LEG570
Repository revision: 8988327d548db7b69f30ea15496ccb0726fa4502
Windowing system distributor 'Microsoft Corp.', version 10.0.14393
Configured using:
 'configure --host=i686-pc-mingw32'

Configured features:
XPM JPEG TIFF GIF PNG RSVG SOUND NOTIFY ACL GNUTLS LIBXML2 ZLIB
TOOLKIT_SCROLL_BARS

Important settings:
  value of $LANG: ENU
  locale-coding-system: cp1252

Major mode: Text

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  electric-quote-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t


Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message dired format-spec rfc822 mml
mml-sec password-cache epg epg-config gnus-util mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail
rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils misearch
multi-isearch cl-extra help-fns help-mode easymenu cl-loaddefs pcase
cl-lib time-date mule-util tooltip eldoc electric uniquify ediff-hook
vc-hooks lisp-float-type mwheel dos-w32 ls-lisp disp-table w32-win
w32-vars term/common-win tool-bar dnd fontset image regexp-opt fringe
tabulated-list newcomment elisp-mode lisp-mode prog-mode register page
menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock
syntax facemenu font-core frame cl-generic cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms
cp51932 hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese charscript case-table epa-hook jka-cmpr-hook help
simple abbrev minibuffer cl-preloaded nadvice loaddefs button faces
cus-face macroexp files text-properties overlay sha1 md5 base64 format
env code-pages mule custom widget hashtable-print-readable backquote
w32notify w32 multi-tty make-network-process emacs)

Memory information:
((conses 8 91051 7113)
 (symbols 32 19702 0)
 (miscs 32 185 237)
 (strings 16 15931 4229)
 (string-bytes 1 430123)
 (vectors 8 12502)
 (vector-slots 4 438930 5422)
 (floats 8 165 224)
 (intervals 28 384 92)
 (buffers 516 21))

-- 
Dani Moncayo

bug#24759: 25.1.50; electric-quote-mode

[Eli Zaretskii]

> From: Dani Moncayo <dmoncayo@gmail.com>
> Date: Fri, 21 Oct 2016 21:38:43 +0200
> 
> I may be missing something, but electric-quote-mode does not seem to
> work here.
> 
> >From `emacs -Q', if I create a new text-mode buffer
> 
>   C-x b foo
>   M-x text-mode
> 
> then I enable electric quoting in that buffer
> 
>   M-x electric-quote-local-mode
> 
> and then I type [``foo''] or [`foo'], no quote conversion takes place.

I guess your buffer-file-coding-system is neither 'undecided' nor
anything that can encode the curved quotes.  Try

  C-x RET f utf-8 RET

and then type the above again.

Paul, I think this condition:

  (defun electric--insertable-p (string)
    (or (not buffer-file-coding-system)
	(eq (coding-system-base buffer-file-coding-system) 'undecided)
	(not (unencodable-char-position nil nil buffer-file-coding-system
					nil string))))

should also accept a coding-system that is the default-value of
buffer-file-coding-system, because that's how buffers are created.
When the file is saved, Emacs will ask for a proper encoding, which is
not a catastrophe.

bug#24759: 25.1.50; electric-quote-mode

[Dani Moncayo]

> I guess your buffer-file-coding-system is neither 'undecided' nor
> anything that can encode the curved quotes.  Try
>
>   C-x RET f utf-8 RET
>
> and then type the above again.

Your guess is right.  After doing the above, the electric quote
conversion works.

> Paul, I think this condition:
>
>   (defun electric--insertable-p (string)
>     (or (not buffer-file-coding-system)
>         (eq (coding-system-base buffer-file-coding-system) 'undecided)
>         (not (unencodable-char-position nil nil buffer-file-coding-system
>                                         nil string))))
>
> should also accept a coding-system that is the default-value of
> buffer-file-coding-system, because that's how buffers are created.
> When the file is saved, Emacs will ask for a proper encoding, which is
> not a catastrophe.

I have no opinion on that but I think that, if this minor mode isn't
going to work with every possible buffer-file-coding-system, that
limitation should be explained somehow in the *Help* text of the minor
mode, to avoid confusing some users.

Thanks.

-- 
Dani Moncayo

bug#24759: 25.1.50; electric-quote-mode

[Paul Eggert]

[-- Attachment #1: Type: text/plain, Size: 199 bytes --]

On 10/21/2016 01:26 PM, Dani Moncayo wrote:
> hat
> limitation should be explained somehow in the*Help*  text of the minor
> mode,

Sure, that's easy enough. I installed the attached into emacs-25.


[-- Attachment #2: 0001-lisp-electric.el-electric-quote-mode-Improve-doc-Bug.patch --]
[-- Type: application/x-patch, Size: 811 bytes --]

bug#24759: 25.1.50; electric-quote-mode

[Paul Eggert]

On 10/21/2016 12:58 PM, Eli Zaretskii wrote:
> I think this condition:
>
>    (defun electric--insertable-p (string)
>      (or (not buffer-file-coding-system)
> 	(eq (coding-system-base buffer-file-coding-system) 'undecided)
> 	(not (unencodable-char-position nil nil buffer-file-coding-system
> 					nil string))))
>
> should also accept a coding-system that is the default-value of
> buffer-file-coding-system, because that's how buffers are created.
> When the file is saved, Emacs will ask for a proper encoding, which is
> not a catastrophe.

Wouldn't this lead to problems? If I use electric quoting in a unibyte 
French locale, where I the default is an ISO 8859 encoding and 
buffer-file-coding-system is something like iso-latin-1-unix, when I 
later save the file Emacs will say "Select coding system (default 
chinese-iso-8bit): ". This is hardly user-friendly, even if we improve 
Emacs to guess UTF-8, as there may be a long interval between typing ` 
and saving the buffer.

bug#24759: 25.1.50; electric-quote-mode

[Eli Zaretskii]

> Cc: 24759@debbugs.gnu.org
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Fri, 21 Oct 2016 14:04:56 -0700
> 
> On 10/21/2016 12:58 PM, Eli Zaretskii wrote:
> > I think this condition:
> >
> >    (defun electric--insertable-p (string)
> >      (or (not buffer-file-coding-system)
> > 	(eq (coding-system-base buffer-file-coding-system) 'undecided)
> > 	(not (unencodable-char-position nil nil buffer-file-coding-system
> > 					nil string))))
> >
> > should also accept a coding-system that is the default-value of
> > buffer-file-coding-system, because that's how buffers are created.
> > When the file is saved, Emacs will ask for a proper encoding, which is
> > not a catastrophe.
> 
> Wouldn't this lead to problems? If I use electric quoting in a unibyte 
> French locale, where I the default is an ISO 8859 encoding and 
> buffer-file-coding-system is something like iso-latin-1-unix, when I 
> later save the file Emacs will say "Select coding system (default 
> chinese-iso-8bit): ". This is hardly user-friendly, even if we improve 
> Emacs to guess UTF-8, as there may be a long interval between typing ` 
> and saving the buffer.

This is standard Emacs behavior.  Emacs never makes any tests of the
current buffer-file-coding-system when you insert characters.  You
will see the same at save-buffer time if you insert the curved quotes
with, e.g., "C-x 8 [", where we insert the character no matter what is
the current buffer-file-coding-system.  Users who use
electric-quote-mode and don't have UTF-8 as their default encoding
will get accustomed to this prompt soon enough.

So I actually question the need for any test in electric--insertable-p.
What bad things, besides the prompt at save-buffer time, will happen
if we remove the test, and insert the characters unconditionally?

bug#24759: 25.1.50; electric-quote-mode

[Eli Zaretskii]

> Date: Sat, 22 Oct 2016 09:49:00 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 24759@debbugs.gnu.org
> 
> So I actually question the need for any test in electric--insertable-p.
> What bad things, besides the prompt at save-buffer time, will happen
> if we remove the test, and insert the characters unconditionally?

And if electric-quote-mode wants to be more user-friendly, it could
ask, upon the first insertion of any electric quote character into a
buffer, whether the user would like to her buffer-file-coding-system
switched to UTF-8.

bug#24759: 25.1.50; electric-quote-mode

[Dani Moncayo]

>> So I actually question the need for any test in electric--insertable-p.
>> What bad things, besides the prompt at save-buffer time, will happen
>> if we remove the test, and insert the characters unconditionally?
>
> And if electric-quote-mode wants to be more user-friendly, it could
> ask, upon the first insertion of any electric quote character into a
> buffer, whether the user would like to her buffer-file-coding-system
> switched to UTF-8.

I'd like such a feature, but I'd rather make it general (not specific
to electric-quote-mode).  That is, whenever a buffer gets a character
(whether typed, yanked, electrically inserted, ...) which is not
representable in the current buffer-file-coding-system, Emacs could
offer the user to switch the coding system to UTF-8 (or another one
which can represent all the characters currently present in the
buffer), like happens when the buffer is about to be saved to a file.

-- 
Dani Moncayo

bug#24759: 25.1.50; electric-quote-mode

[Eli Zaretskii]

> From: Dani Moncayo <dmoncayo@gmail.com>
> Date: Sat, 22 Oct 2016 10:16:35 +0200
> Cc: Paul Eggert <eggert@cs.ucla.edu>, 24759@debbugs.gnu.org
> 
> > And if electric-quote-mode wants to be more user-friendly, it could
> > ask, upon the first insertion of any electric quote character into a
> > buffer, whether the user would like to her buffer-file-coding-system
> > switched to UTF-8.
> 
> I'd like such a feature, but I'd rather make it general (not specific
> to electric-quote-mode).  That is, whenever a buffer gets a character
> (whether typed, yanked, electrically inserted, ...) which is not
> representable in the current buffer-file-coding-system, Emacs could
> offer the user to switch the coding system to UTF-8 (or another one
> which can represent all the characters currently present in the
> buffer), like happens when the buffer is about to be saved to a file.

IMO, this would be too annoying and detrimental to performance in many
cases.  I think you underestimate how much 'insert' is used in Emacs,
without the user knowing anything about that.  In most such cases, the
buffer into which the character is entered will never be saved to any
file.

My proposal was specifically for the case where keyboard input caused
these characters be inserted after conversion by electric-quote-mode,
which hopefully restricts the applicable use cases to those where the
user is typing at the keyboard.

bug#24759: 25.1.50; electric-quote-mode

[Dani Moncayo]

>> > And if electric-quote-mode wants to be more user-friendly, it could
>> > ask, upon the first insertion of any electric quote character into a
>> > buffer, whether the user would like to her buffer-file-coding-system
>> > switched to UTF-8.
>>
>> I'd like such a feature, but I'd rather make it general (not specific
>> to electric-quote-mode).  That is, whenever a buffer gets a character
>> (whether typed, yanked, electrically inserted, ...) which is not
>> representable in the current buffer-file-coding-system, Emacs could
>> offer the user to switch the coding system to UTF-8 (or another one
>> which can represent all the characters currently present in the
>> buffer), like happens when the buffer is about to be saved to a file.
>
> IMO, this would be too annoying and detrimental to performance in many
> cases.  I think you underestimate how much 'insert' is used in Emacs,
> without the user knowing anything about that.  In most such cases, the
> buffer into which the character is entered will never be saved to any
> file.
>
> My proposal was specifically for the case where keyboard input caused
> these characters be inserted after conversion by electric-quote-mode,
> which hopefully restricts the applicable use cases to those where the
> user is typing at the keyboard.

OK.  In that case I withdraw my general approach.

> Date: Sat, 22 Oct 2016 09:49:00 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 24759@debbugs.gnu.org
>
> So I actually question the need for any test in electric--insertable-p.
> What bad things, besides the prompt at save-buffer time, will happen
> if we remove the test, and insert the characters unconditionally?

FWIW: I'd also prefer to remove that check from electric-quote-mode,
so that the quote conversion would always happen (if the minor mode is
enabled in the current buffer), regardless of
buffer-file-coding-system.

Thanks.

-- 
Dani Moncayo

bug#24759: 25.1.50; electric-quote-mode

[Paul Eggert]

Eli Zaretskii wrote:
>> when I
>> > later save the file Emacs will say "Select coding system (default
>> > chinese-iso-8bit): ". This is hardly user-friendly, even if we improve
>> > Emacs to guess UTF-8, as there may be a long interval between typing `
>> > and saving the buffer.
> This is standard Emacs behavior.

If it is, then the standard behavior is wrong. For starters, Emacs should not 
default to chinese-iso-8bit in a unibyte French-language environment merely 
because the buffer has a curved quote. That can't be what a typical French user 
wants.

The problem can be reproduced without electric-quote mode, as follows:

LC_ALL=fr_FR.iso88591 emacs -Q newfile
C-x 8 [ RET
C-x C-s


More generally, if I type any character that won't be saved, I should be 
notified when I type it, not ages later when I save the buffer. This should be 
done independently of whether electric-quote mode is in use.

bug#24759: 25.1.50; electric-quote-mode

[Eli Zaretskii]

> Cc: dmoncayo@gmail.com, 24759@debbugs.gnu.org
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Sat, 22 Oct 2016 11:47:58 -0700
> 
> Eli Zaretskii wrote:
> >> when I
> >> > later save the file Emacs will say "Select coding system (default
> >> > chinese-iso-8bit): ". This is hardly user-friendly, even if we improve
> >> > Emacs to guess UTF-8, as there may be a long interval between typing `
> >> > and saving the buffer.
> > This is standard Emacs behavior.
> 
> If it is, then the standard behavior is wrong.

It was like that since Emacs 20.1.  I don't see what changed now that
it's suddenly a problem.  I guess you are simply unused to see these
prompts due to your locale, that's all.

> For starters, Emacs should not default to chinese-iso-8bit in a
> unibyte French-language environment merely because the buffer has a
> curved quote.

Emacs collects all the encodings that can handle all of the
characters, then sorts them; chinese-iso-8bit is just the one that
comes up first in the sorted order.  If you are hinting that UTF-8
should come up first, we should just change the sorting order, that's
all.

> That can't be what a typical French user wants.

We have no idea what the user might want.  We can guess at best, and
offer the list of the alternatives from which to choose.  Which is
what we do.

> More generally, if I type any character that won't be saved, I should be 
> notified when I type it, not ages later when I save the buffer.

I disagree.  Most buffers will never be saved.  And even if they will
be, the user could delete the character by the time she saves it.

I don't see how we can do better here than we already do, except by
making the first alternative more suitable for today's world.

bug#24759: 25.1.50; electric-quote-mode

[Eli Zaretskii]

> Date: Sat, 22 Oct 2016 22:04:28 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 24759@debbugs.gnu.org
> 
> > For starters, Emacs should not default to chinese-iso-8bit in a
> > unibyte French-language environment merely because the buffer has a
> > curved quote.
> 
> Emacs collects all the encodings that can handle all of the
> characters, then sorts them; chinese-iso-8bit is just the one that
> comes up first in the sorted order.  If you are hinting that UTF-8
> should come up first, we should just change the sorting order, that's
> all.
> 
> > That can't be what a typical French user wants.
> 
> We have no idea what the user might want.  We can guess at best, and
> offer the list of the alternatives from which to choose.  Which is
> what we do.

Please also note that by the time this prompt is displayed, Emacs has
already tried to see whether several default encodings corresponding
to the user locale and preferences can encode the text, and the answer
was NO (this information is included in the buffer popped up to the
user).  If one of the default encodings could encode the text, Emacs
would have used it without asking any questions.

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.

bug#24759: 25.1.50; electric-quote-mode

[Paul Eggert]

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.

> 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.

> 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. In a unibyte 
European locale, UTF-8 should be the first-listed multibyte encoding by default.

> 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.

It's a bit like spelling checking. Many users prefer checking spelling on the 
fly, rather than checking only when you save the file.

bug#24759: 25.1.50; electric-quote-mode

[Eli Zaretskii]

> Cc: 24759@debbugs.gnu.org
> From: Paul Eggert <eggert@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.

bug#24759: 25.1.50; electric-quote-mode

[Paul Eggert]

Eli Zaretskii wrote:

>> 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?

A locale that uses some non-UTF-8 multibyte encoding.

>> 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).

> 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.

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

>> 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.

A bit like, not exactly like. The point is that users often find it more 
convenient to see problems right away. For example, although an 
improperly-parenthesized Lisp buffer can be saved, it's still nice to have 
parenthesis-matching enabled as I type, so that I can see and fix parenthesis 
problems while they're still fresh in my mind.

bug#24759: 25.1.50; electric-quote-mode

[Eli Zaretskii]

> 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.

bug#24759: 25.1.50; electric-quote-mode

[Andreas Schwab]

On Okt 22 2016, Paul Eggert <eggert@cs.ucla.edu> wrote:

> If it is, then the standard behavior is wrong. For starters, Emacs should
> not default to chinese-iso-8bit in a unibyte French-language environment
> merely because the buffer has a curved quote. That can't be what a typical
> French user wants.

A typical French user will use a utf-8 locale.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

bug#24759: 25.1.50; electric-quote-mode

[Paul Eggert]

Andreas Schwab wrote:
> A typical French user will use a utf-8 locale.

Yes, and to some extent this subthread is a tempest in a teapot, since typical 
French users now either use a UTF-8 locale, or perhaps the C locale, and Emacs 
works fine in both these cases. That is, when I run this:

LC_ALL=C emacs -Q newfile
C-x 8 [ RET
C-x C-s

on Fedora 24, Emacs saves the file using UTF-8 without prompting the user for an 
encoding - basically, it is bypassing the locale settings for this file, which 
is a reasonable thing to do.

As I understand it, this subthread is about what Emacs should do in a unibyte 
locale that isn't the C locale. It's not clear to me why these locales (which 
are no longer that important) should be treated differently from a unibyte C 
locale for this sort of situation.

bug#24759: 25.1.50; electric-quote-mode

[Eli Zaretskii]

> Cc: Eli Zaretskii <eliz@gnu.org>, 24759@debbugs.gnu.org
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Sat, 22 Oct 2016 20:55:25 -0700
> 
> As I understand it, this subthread is about what Emacs should do in a unibyte 
> locale that isn't the C locale. It's not clear to me why these locales (which 
> are no longer that important) should be treated differently from a unibyte C 
> locale for this sort of situation.

Because a C locale basically means you have no non-trivial default
encoding.  IOW, your default is 'undecided'.  In such cases, we prefer
UTF-8 automatically if it can do the job (and it usually can), since
the user doesn't have any specific preferences.

So I think we should indeed remove the electric--insertable-p test in
electric-quote-mode, on the emacs-25 branch.

A related change (which IMO should be done on master) is to make UTF-8
be the first encoding in the sorted list of encodings Emacs offers
when the defaults cannot cope with some characters in a buffer about
to be saved or sent to a subprocess.  But this related change is not a
prerequisite for removing the electric--insertable-p test, as it is a
general improvement in the Emacs guesswork, not something specific to
the issue at hand in this bug report.

bug#24759: 25.1.50; electric-quote-mode

[Paul Eggert]

[-- Attachment #1: Type: text/plain, Size: 169 bytes --]

Eli Zaretskii wrote:
> So I think we should indeed remove the electric--insertable-p test in
> electric-quote-mode, on the emacs-25 branch.

OK, done with the attached.

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-electric-quote-mode-no-longer-worries-about-coding.patch --]
[-- Type: text/x-diff; name="0001-electric-quote-mode-no-longer-worries-about-coding.patch", Size: 4467 bytes --]

From da6bd602c8603a23c6c63e4d4676333d91388be0 Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Sun, 23 Oct 2016 01:14:23 -0700
Subject: [PATCH] electric-quote mode no longer worries about coding

* doc/emacs/text.texi (Quotation Marks), etc/NEWS: Document this.
* lisp/electric.el (electric--insertable-p): Remove.
All uses removed (Bug#24759).
---
 doc/emacs/text.texi |  4 +---
 etc/NEWS            |  6 ++++++
 lisp/electric.el    | 21 ++++-----------------
 3 files changed, 11 insertions(+), 20 deletions(-)

diff --git a/doc/emacs/text.texi b/doc/emacs/text.texi
index 579f788..7fa0804 100644
--- a/doc/emacs/text.texi
+++ b/doc/emacs/text.texi
@@ -422,9 +422,7 @@ Quotation Marks
 
   Electric Quote mode makes it easier to type curved quotes.  As you
 type characters it optionally converts @t{`} to @t{‘}, @t{'} to @t{’},
-@t{``} to @t{“}, and @t{''} to @t{”}.  These conversions are
-suppressed in buffers whose coding systems cannot represent curved
-quote characters.
+@t{``} to @t{“}, and @t{''} to @t{”}.
 
 @vindex electric-quote-paragraph
 @vindex electric-quote-comment
diff --git a/etc/NEWS b/etc/NEWS
index 5b89639..a5bcb8d 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -38,6 +38,12 @@ fontsets if the default font supports these characters.  Set this
 variable to nil to disable the new behavior and get back the old
 behavior.
 
++++
+** 'electric-quote-mode' is no longer suppressed in a buffer whose
+whose coding system cannot represent curved quote characters.
+Instead, users can deal with the unrepresentable characters in the
+usual way when they save the buffer.
+
 ---
 ** New variable 'inhibit-compacting-font-caches'.
 Set this variable to a non-nil value to speed up display of characters
diff --git a/lisp/electric.el b/lisp/electric.el
index b6697e0..ab9770b 100644
--- a/lisp/electric.el
+++ b/lisp/electric.el
@@ -430,12 +430,6 @@ electric-quote-paragraph
   :version "25.1"
   :type 'boolean :safe 'booleanp :group 'electricity)
 
-(defun electric--insertable-p (string)
-  (or (not buffer-file-coding-system)
-      (eq (coding-system-base buffer-file-coding-system) 'undecided)
-      (not (unencodable-char-position nil nil buffer-file-coding-system
-                                      nil string))))
-
 (defun electric-quote-post-self-insert-function ()
   "Function that `electric-quote-mode' adds to `post-self-insert-hook'.
 This requotes when a quoting key is typed."
@@ -460,8 +454,7 @@ electric-quote-post-self-insert-function
       (when start
         (save-excursion
           (if (eq last-command-event ?\`)
-              (cond ((and (electric--insertable-p "“")
-                          (search-backward "‘`" (- (point) 2) t))
+              (cond ((search-backward "‘`" (- (point) 2) t)
                      (replace-match "“")
                      (when (and electric-pair-mode
                                 (eq (cdr-safe
@@ -469,16 +462,13 @@ electric-quote-post-self-insert-function
                                     (char-after)))
                        (delete-char 1))
                      (setq last-command-event ?“))
-                    ((and (electric--insertable-p "‘")
-                          (search-backward "`" (1- (point)) t))
+                    ((search-backward "`" (1- (point)) t)
                      (replace-match "‘")
                      (setq last-command-event ?‘)))
-            (cond ((and (electric--insertable-p "”")
-                        (search-backward "’'" (- (point) 2) t))
+            (cond ((search-backward "’'" (- (point) 2) t)
                    (replace-match "”")
                    (setq last-command-event ?”))
-                  ((and (electric--insertable-p "’")
-                        (search-backward "'" (1- (point)) t))
+                  ((search-backward "'" (1- (point)) t)
                    (replace-match "’")
                    (setq last-command-event ?’)))))))))
 
@@ -497,9 +487,6 @@ electric-quote-mode
 `electric-quote-comment', `electric-quote-string', and
 `electric-quote-paragraph'.
 
-Electric quoting is suppressed in a buffer whose coding system
-cannot represent the replacement characters.
-
 This is a global minor mode.  To toggle the mode in a single buffer,
 use `electric-quote-local-mode'."
   :global t :group 'electricity
-- 
2.7.4

bug#24759: 25.1.50; electric-quote-mode

[Eli Zaretskii]

> Cc: schwab@linux-m68k.org, 24759@debbugs.gnu.org
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Sun, 23 Oct 2016 01:15:47 -0700
> 
> Eli Zaretskii wrote:
> > So I think we should indeed remove the electric--insertable-p test in
> > electric-quote-mode, on the emacs-25 branch.
> 
> OK, done with the attached.

Thanks, I think this bug can be closed now.  Dani, any objections?

bug#24759: 25.1.50; electric-quote-mode

[Dani Moncayo]

On Sun, Oct 23, 2016 at 10:55 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>> Cc: schwab@linux-m68k.org, 24759@debbugs.gnu.org
>> From: Paul Eggert <eggert@cs.ucla.edu>
>> Date: Sun, 23 Oct 2016 01:15:47 -0700
>>
>> Eli Zaretskii wrote:
>> > So I think we should indeed remove the electric--insertable-p test in
>> > electric-quote-mode, on the emacs-25 branch.
>>
>> OK, done with the attached.
>
> Thanks, I think this bug can be closed now.  Dani, any objections?

No, none.  Thanks to both of you.

-- 
Dani Moncayo

bug#24759: 25.1.50; electric-quote-mode

[Paul Eggert]

Dani Moncayo wrote:
> On Sun, Oct 23, 2016 at 10:55 AM, Eli Zaretskii <eliz@gnu.org> wrote:

>> Thanks, I think this bug can be closed now.  Dani, any objections?
>
> No, none.  Thanks to both of you.
>

You're welcome. Closing the bug.