Re: [emacs-humanities] electric-pair and non-breakable spaces

[l@tlo]

> On May 28, 2023, at 18:57, Juan Manuel Macías <maciaschain@posteo.net> wrote:
> 
> l@tlo writes:
> 
>>>> Right in the middle of finishing my MA thesis in org-mode, I'm trying
>>>> to fix the electric-pair mode default that inserts «» without the
>>>> required non-breakable spaces that we have in French.
>>> 
>>> I understand that you put the french guillemets and spaces directly in
>>> your Org document, right? I think it is best practice not to use
>>> 'typographical quotes' in Org. That is, use inside Org the expected
>>> quotes for plain text ("..."), and let the typographical conventions of
>>> each language be resolved in the export.
>> 
>> That's a very English centered option/process and I don't think that
>> should be considered the proper way for people to write a French
>> document in org-mode (or any text based format for that matter).
> 
> I understand your point of view, and I understand that you want to
> consistently apply French orthotypography in all your documents written
> in French.

Indeed. Just like I put spaces between words when I write in French, but not 
when I type in Japanese. And I don’t think an export system is supposed to have 
me not write the spaces in French to later add them at export.

> In Spanish, the correct first level quotation marks are also
> «», as in French, but without spaces. Each language has its
> orthotypographic rules. But, on the other hand, Org (like LaTeX) is a
> plain text based system. IMHO, Org language is also a
> 'typographic-agnostic' format, and that makes it more efficient against
> wysiwyg ways of working.

Typography is not exactly about WYSIWYG.

> Org is "what you see is what you mean".

I don’t think I agree with that. There are ways to add a presentation layer to 
org exports, but an org file in itself is nothing more than plain text with 
ascii based decorations and users should not have to rely on an export process 
to have basic typography done right.

> Although we work in utf-8, I think it is usually more efficient to focus
> on ASCII for a series of characters, and let the substitution (that is,
> the correct character according to the rules of each language) be done
> at the glyph level, in the typographical output, but not in the source
> document.

Please. I’ve struggled enough to have proper Japanese/French/English support in 
the early utf-8 days that I’m way past that level of discourse. We’re not in 
the ’90s anymore.

We have keyboards that are here to provide us with the proper characters, and 
Emacs to add the necessary level of automation for repetitive input. What you 
propose is hacks to solve issues that we had 25 years ago and that don’t exist 
(mostly) anymore.

> For that reason we often use '---' instead of the character EM
> DASH U+2014, or '--' instead of EN DASH U+2013.

No. You often use such hacks because your keyboard does not give easy access to 
such characters, or because you don’t see the difference visually and prefer to 
rely on visual hacks. - – — et voilà.

> Quotes would also fall
> into this group of replaceable characters. I think it's more convenient
> to do it like this than to explicitly add «...» with spaces.

Maybe that’s because Spanish has it close enough that you can be “lazy” and let 
the computer do the replacement. I’d rather have proper “locale” 
recognition/setting and have emacs type the thing for me, as it does with 
electric-pair.

> However, if you want to still see french guillemets in your org document
> (but keep the ascii quotes), you could add a layer of embellishment, for
> example via org-entities...

I don’t want to *see* them. I want emacs to help me type the thing the proper 
way.

>>> In org you can use the
>>> org-export-with-smart-quotes option (':t). A basic setup can be:
>> 
>> That option does not take into account the « and » that are in the text and 
>> thus does not produce the expected output.
> 
> org-export-with-smart-quotes only works if you use ascii quotes.

Then I don’t see the point using it.

>> It does not properly output secondary quotation marks either.
> 
> hmm, you're right. I think there is a bug in org-smart-quotes-alist. The
> french inner quotes should be “...”, I think without spaces. However,
> the current value is:
> 
> ("fr"
>  (primary-opening :utf-8 "« " :html "&laquo;&nbsp;" :latex "\\og " :texinfo 
> "@guillemetleft{}@tie{}")
>  (primary-closing :utf-8 " »" :html "&nbsp;&raquo;" :latex "\\fg{}" :texinfo 
> "@tie{}@guillemetright{}")
>  (secondary-opening :utf-8 "« " :html "&laquo;&nbsp;" :latex "\\og " :texinfo 
> "@guillemetleft{}@tie{}")
>  (secondary-closing :utf-8 " »" :html "&nbsp;&raquo;" :latex "\\fg{}" 
> :texinfo "@tie{}@guillemetright{}")
>  (apostrophe :utf-8 "’" :html "&rsquo;"))

Indeed. That’s a bug.

>> Also, if I set the document to Japanese, the export won't convert the "..." 
>> to the expected 「」.
> 
> org-smart-quotes-alist does not cover all languages. But patches can be
> sent to add support for more cases, like Japanese. As you can see from
> what I have put above, the syntax is pretty simple.

But that would mean, for languages that have different input systems, that they 
have to shift to ascii just to enter “ and move back to the original system. 
That’s not sustainable. That’s forcing an English centric (ascii-us) way of 
writing on non-English users. That’s totally backward.

Computers are supposed to help us, not to force us into weird practices because 
programmers think they know better than users. I’m fine with the fact that the 
export process can help with people who are being lazy. But expecting that an 
export process will solve your issues is going a bit too far.

-- 
Jean-Christophe Helary @jchelary@emacs.ch
https://traductaire-libre.org
https://mac4translators.blogspot.com
https://sr.ht/~brandelune/omegat-as-a-book/