Re: [Emacs-diffs] master b533552 2/5: Documentation fixes re quotes

[Dmitry Gutov <dgutov@yandex.ru>]

On 09/02/2015 04:05 AM, Paul Eggert wrote:

> More generally, though, I did not remove every single curved quote from
> the tutorial.  That is because it's fine if some programmers want to use
> curved quotes in docstrings and diagnostics.  These quotes have worked
> for many years, and they now work even a bit better than they did
> before, in the sense that they're now markup that is automatically
> converted to grave quotes for old-fashioned users who prefer the grave
> style.

They aren't markup, because you insist that they "stand for themselves", 
which is as far from the concept of markup as it could be.

> Using curved quotes in the source has technical advantages, as
> the programmer sees the same quotes that typical users will see in the
> next version of Emacs, which is a clear win.

Nothing clear about that. Programmers are used to even larger levels of 
abstraction than quote translation. Which is relatively trivial.

> or help buffers that quote `like this' in older Emacs versions, but
> overall in many cases the benefits exceed the costs and it is a win

[citation needed]

> As far as the Emacs source code goes, because the master for a while had
> an approach that required the use of curved quotes for proper markup,
> and because I was using Electric Quote mode where it's easier to type
> curved than straight quotes, I converted some diagnostics and
> documentation source to use curved quotes.

Even though you've been specifically asked not to.

> Most (though not all) of
> these curved quotes can now be converted back to grave quotes if someone
> who hates, Hates, HATES curved quotes wants to take the trouble to do
> that.

Well, that's nice. Thank you for that chunk of pointless work that I (or 
someone else) will have to do. I take it there are no other things you'd 
prefer me to spend time on instead.

> However, I doubt whether it's worth the effort, as the curved
> quotes work fine in practice in the source, and really, why not give
> them a try?  In practice they might not be as bad as all that.

The "work fine in practice" argument is weak. A vast number of 
approaches will work well enough if you don't care about increased 
complexity (something that Alan brought up), or further improvements 
that might be built on top of docstring markup.