all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Paul Eggert <eggert@cs.ucla.edu>
Cc: 24759@debbugs.gnu.org
Subject: bug#24759: 25.1.50; electric-quote-mode
Date: Sun, 23 Oct 2016 11:51:50 +0300	[thread overview]
Message-ID: <83zilvo3bt.fsf@gnu.org> (raw)
In-Reply-To: <2ee8a0d1-46b8-3b44-3721-806538daca82@cs.ucla.edu> (message from Paul Eggert on Sun, 23 Oct 2016 01:24:15 -0700)

> 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	other threads:[~2016-10-23  8:51 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-21 19:38 bug#24759: 25.1.50; electric-quote-mode Dani Moncayo
2016-10-21 19:58 ` Eli Zaretskii
2016-10-21 20:26   ` Dani Moncayo
2016-10-21 21:01     ` Paul Eggert
2016-10-21 21:04   ` Paul Eggert
2016-10-22  6:49     ` Eli Zaretskii
2016-10-22  7:47       ` Eli Zaretskii
2016-10-22  8:16         ` Dani Moncayo
2016-10-22  9:10           ` Eli Zaretskii
2016-10-22 10:36             ` Dani Moncayo
2016-10-22 18:47       ` Paul Eggert
2016-10-22 19:04         ` Eli Zaretskii
2016-10-22 19:34           ` Eli Zaretskii
2016-10-23  4:10             ` Paul Eggert
2016-10-23  7:13               ` Eli Zaretskii
2016-10-23  8:24                 ` Paul Eggert
2016-10-23  8:51                   ` Eli Zaretskii [this message]
2016-10-22 19:20         ` Andreas Schwab
2016-10-23  3:55           ` Paul Eggert
2016-10-23  7:00             ` Eli Zaretskii
2016-10-23  8:15               ` Paul Eggert
2016-10-23  8:55                 ` Eli Zaretskii
2016-10-23  9:15                   ` Dani Moncayo
2016-10-23  9:28                     ` Paul Eggert

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83zilvo3bt.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=24759@debbugs.gnu.org \
    --cc=eggert@cs.ucla.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.