Re: [PATCH] Enable customisation for electric-quote-mode chars

[Eli Zaretskii <eliz@gnu.org>]

> From: Göktuğ Kayaalp <self@gkayaalp.com>
> Cc: eggert@cs.ucla.edu, emacs-devel@gnu.org
> Date: Mon, 29 Aug 2016 19:27:42 +0300
> 
> > From: Eli Zaretskii <eliz@gnu.org>
> > Date: 2016-08-29 06:08:25 PM +0300
> > Eli Zaretskii wrote:
> >> From: Göktuğ Kayaalp <self@gkayaalp.com>
> >> Cc: eliz@gnu.org, emacs-devel@gnu.org
> >> Date: Mon, 29 Aug 2016 08:28:19 +0300
> 
> (I'm sorry for /borrowing/ your citation style, but it's very nice, I
> couldn't refuse.  Hope that doesn't annoy you :)  I've made it a bit
> different though.)

It's not me, it's Rmail that's doing this.  (No, I'm not annoyed, of
course not.)

> >> +quote characters.  It's possible to change the default quotes listed
> >> +above, by customizing the variable @code{electric-quote-chars}, a list
> >> +of four characters, where the items correspond to the left single
> >> +quote, the right single quote, the left double quote and the right
> >> +double quote, respectively, whose default value is
> >> +@code{'(?‘ ?’ ?“ ?”)}.
> >
> > There's no need to go to such detail when describing a customizable
> > option.  The Customize interface should be enough for the user to
> > figure out what to do.
> 
> Then I can remove the part after reference to the variable name, and
> improve the defcustom's documentation (see below).  Is that okay?

Yes.

> >   Default (‘..’ “..”)
> >   Arabic (".." ”..“)
> >   German  (‚..‛ „..“)
> >   French (‹..› «..»)
> >   Cyrillic (‚..‘ «..»)
> >
> > etc.  WDYT?  (See https://en.wikipedia.org/wiki/Quotation_mark for
> > some more.)
> 
> Well I think we'd rather not do that but improve the docstring instead,
> because, looking at the big summary table on the page you linked [1]
> there's not only a lot of variance among languages, but some of them
> have multiple standard and alternative forms, and some don't have single
> quotes (e.g. Persian).  I think we'd better keep the defaults and
> improve the documentation, and not have implement all the languages nor
> have to pick a subset.

If no one else thinks my suggestion is a significant improvement, I
won't insist.  (And of course, we don't need to implement the entire
Wikipedia list, I'm not even sure it's accurate.)

It could be enough to mention some of the possibilities in the doc
string, together with their cultural affiliations.

> Maybe we could leave setting these variables to the language environment
> if that's possible?

I think it's too early for that, we haven't yet figured out how to set
up language dependent settings.  One problem with the idea you raise
is that a user can reside in a certain locale, but use universal
settings commonly used in multilingual environments.

> Please direct me on how to proceed, and I'll update the patch as soon as
> I can

I would suggest to wait for a couple of days for more comments.  If no
one supports my suggestions about language-tagged alternatives, you
can disregard them, and only make the documentation changes already
mentioned.

Thanks.