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

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

[Dmitry Gutov]

On 08/31/2015 09:12 AM, Paul Eggert wrote:

>      Prefer curved quotes in examples if users will typically see
>      curved quotes when the examples run.

Who said the source code examples should looks the same as a output? It 
source code, people won't expect every program to be a quine.

I'm obviously against this, because these encourage users to copy and 
paste the snippets containing curly quotes in their programs.

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

[Paul Eggert]

Dmitry Gutov wrote:
> Who said the source code examples should looks the same as a output?

It's better for beginners to have examples where (print "FOO") outputs FOO 
rather than some other string.

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

[Dmitry Gutov]

On 08/31/2015 09:39 AM, Paul Eggert wrote:

> It's better for beginners to have examples where (print "FOO") outputs
> FOO rather than some other string.

No, it isn't. That doesn't impact understanding of the snippet at all.

If anything, the sooner they encounter the convoluted results of your 
choices WRT quotes, the better.

Writing example docstrings with curly quotes for the stated reason 
doesn't hold water either.

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

[Paul Eggert]

Dmitry Gutov wrote:
> That doesn't impact understanding of the snippet at all.

Those snippets are not about quote translation; they are about other topics.  We 
shouldn't introduce the rather specialized topic of quote translation in the 
tutorial, as that's a topic needed only by advanced users and would be a 
distraction in tutorial examples.  We should simply use strings that users will 
normally see as themselves, as that's the most intuitive and won't get in the 
way of the real topics there.

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

[Dmitry Gutov]

On 08/31/2015 09:53 AM, Paul Eggert wrote:

> Those snippets are not about quote translation; they are about other
> topics.

Then the quote translation won't have any meaningful impact on the 
observed behavior one way or the other.

But if it's such a problem, don't use quotes in the examples.

>We should simply
> use strings that users will normally see as themselves, as that's the
> most intuitive and won't get in the way of the real topics there.

If you think the translation behavior is hard for a user to understand, 
why not revert the whole rigamarole? It doesn't add *that* much value.

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

[Paul Eggert]

Dmitry Gutov wrote:
> But if it's such a problem

It's not a problem.  Tutorial readers will see quotes that stand for themselves.

> If you think the translation behavior is hard for a user to understand

I don't.

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

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

I think this change is misconceived.

  > diff --git a/doc/lispintro/emacs-lisp-intro.texi b/doc/lispintro/emacs-lisp-intro.texi
  > index f1480a4..a27a969 100644
  > --- a/doc/lispintro/emacs-lisp-intro.texi
  > +++ b/doc/lispintro/emacs-lisp-intro.texi
  > @@ -3862,10 +3862,10 @@ tiger!} will be printed; otherwise, @code{nil} will be returned.
  >  @group
  >  (defun type-of-animal (characteristic)
  >    "Print message in echo area depending on CHARACTERISTIC.
  > -If the CHARACTERISTIC is the symbol `fierce',
  > +If the CHARACTERISTIC is the symbol ?fierce?,
  >  then warn of a tiger."
  >    (if (equal characteristic 'fierce)
  > -      (message "It's a tiger!")))
  > +      (message "It?s a tiger!")))
  >  @end group
  >  @end smallexample

This is not an example of what appears in a Help buffer.
It is an example of source code.  Doc strings should be written
with straight quotes, so the example should show straight quotes.

Likewise, the call to message should use a straight quote.
It will usually typically _output_ a curly quote if it uses 'format-message',
but this example shows the source code, not the output.

This change is correct:

  >  When you evaluate @code{(type-of-animal 'fierce)}, you will see the
  > -following message printed in the echo area: @code{"It's a tiger!"}; and
  > +following message printed in the echo area: @code{"It?s a tiger!"}; and

It's correct because it shows the output.  However, the text should
explain (without the full detail) the difference in quotes.  Perhaps

   On terminals that can display curly quotes, 'message' changes ASCII
quotes to curly ones.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

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

[Paul Eggert]

Richard Stallman wrote:

> Doc strings should be written
> with straight quotes, so the example should show straight quotes.

That example came very early in the tutorial, where it's inappropriate to be 
burdening the novice reader with low-priority detail like quoting, so I rewrote 
it to use neither curved nor grave quotes, thus sidestepping the issue in that 
example.

I also reverted the changes that curved the quotes in the the bulk of the 
examples, which were taken from Emacs 22, so they now quote `like this' as before.

> However, the text should
> explain (without the full detail) the difference in quotes.

I added text to do that as well.

All the above is in master commit afe1cf00713847c1d8f3a9d95d4980d705ec39f1.

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.  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.  Of 
course it also has technical disadvantages, for developers who have trouble 
dealing with non-ASCII characters or who want to have code that generates 
diagnostics 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, and it's OK 
for the Emacs documentation to cover this alternative.

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

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

[David Kastrup]

Paul Eggert <eggert@cs.ucla.edu> writes:

> Richard Stallman wrote:
>
>> Doc strings should be written
>> with straight quotes, so the example should show straight quotes.
>
> That example came very early in the tutorial, where it's inappropriate
> to be burdening the novice reader with low-priority detail like
> quoting,

It stops being a low-priority detail when it is not possible to write
basic Lisp expressions without employing \\= liberally.

In fact, in many DOC strings writing 'xxx as an isolated expression you
have instead substituted `xxx' instead.  Switching from a version the
Lisp interpreter will accept to a version that requires quoting by the
user is not a mere cosmetic change.

If we change Emacs to a system that treats "novice readers" with
contempt, not worth teaching correct code and documentation, that is a
solid step backwards from hacker ethics.

-- 
David Kastrup

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

[Paul Eggert]

David Kastrup wrote:
> In fact, in many DOC strings writing 'xxx as an isolated expression you
> have instead substituted `xxx' instead.

I did that only when the 'xxx appeared to be a not-properly-quoted value, not an 
isolated source-code expression.  In cases where it was an expression I escaped 
the apostrophe.  Admittedly there are some gray areas, and in areas where I 
misinterpreted please feel free to change it back.

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

[David Kastrup]

Paul Eggert <eggert@cs.ucla.edu> writes:

> David Kastrup wrote:
>> In fact, in many DOC strings writing 'xxx as an isolated expression you
>> have instead substituted `xxx' instead.
>
> I did that only when the 'xxx appeared to be a not-properly-quoted
> value, not an isolated source-code expression.

Are you seriously suggesting that people wrote things like 'safe for a
symbol value because they forgot a closing quote character?

Let's see a few examples from the most recent quote-changing diff:

 ID-FORMAT specifies the preferred format of attributes uid and gid (see
-below) - valid values are 'string and 'integer.  The latter is the
+below) - valid values are `string' and `integer'.  The latter is the
 default, but we plan to change that, so you should specify a non-nil value

     doc: /* List of potentially supported image types.
-Each element of the list is a symbol for an image type, like 'jpeg or 'png.
+Each element of the list is a symbol for an image type, like `jpeg' or `png'.
 To check whether it is really supported, use `image-type-available-p'.  */);

 DEFUN ("set-message-beep", Fset_message_beep, Sset_message_beep, 1, 1, 0,
        doc: /* Set the sound generated when the bell is rung.
-SOUND is 'asterisk, 'exclamation, 'hand, 'question, 'ok, or 'silent
-to use the corresponding system sound for the bell.  The 'silent sound
+SOUND is `asterisk', `exclamation', `hand', `question', `ok', or `silent'
+to use the corresponding system sound for the bell.  The `silent' sound
 prevents Emacs from making any sound at all.

> In cases where it was an expression I escaped the apostrophe.
> Admittedly there are some gray areas, and in areas where I
> misinterpreted please feel free to change it back.

How is one supposed to resolve anything in discussion when you
constantly and habitually spin the facts and play word games and play
dumb?

-- 
David Kastrup

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

[Paul Eggert]

David Kastrup wrote:
>   ID-FORMAT specifies the preferred format of attributes uid and gid (see
> -below) - valid values are 'string and 'integer.  The latter is the
> +below) - valid values are `string' and `integer'.  The latter is the

Yes, that's where the documentation was technically incorrect to write 
“'integer”.  The valid value is not ‘'integer’, i.e., ‘(quote integer)’; the 
valid value is just the symbol ‘integer’.  Similarly for the other examples you 
gave.  This is a minor technical documentation error that is not likely to 
confuse many people, but I figured I might as well get it right while fixing 
things in the neighborhood.

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

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  >  DEFUN ("set-message-beep", Fset_message_beep, Sset_message_beep, 1, 1, 0,
  >         doc: /* Set the sound generated when the bell is rung.
  > -SOUND is 'asterisk, 'exclamation, 'hand, 'question, 'ok, or 'silent
  > -to use the corresponding system sound for the bell.  The 'silent sound
  > +SOUND is `asterisk', `exclamation', `hand', `question', `ok', or `silent'
  > +to use the corresponding system sound for the bell.  The `silent' sound
  >  prevents Emacs from making any sound at all.

These changes are necessary in any case; the old text violates
Emacs documentation conventions.  It is incorrect to indicate
a symbol in text by writing a singlequote before it.
The correct way is to write quotes around  it (except for t and nil).

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

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

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>   >  DEFUN ("set-message-beep", Fset_message_beep, Sset_message_beep, 1, 1, 0,
>   >         doc: /* Set the sound generated when the bell is rung.
>   > -SOUND is 'asterisk, 'exclamation, 'hand, 'question, 'ok, or 'silent
>   > -to use the corresponding system sound for the bell.  The 'silent sound
>   > +SOUND is `asterisk', `exclamation', `hand', `question', `ok', or `silent'
>   > +to use the corresponding system sound for the bell.  The `silent' sound
>   >  prevents Emacs from making any sound at all.
>
> These changes are necessary in any case; the old text violates
> Emacs documentation conventions.  It is incorrect to indicate
> a symbol in text by writing a singlequote before it.
> The correct way is to write quotes around  it (except for t and nil).

Thanks.

My actual point of annoyance was the total inability to get any useful
feedback concerning such changes because of semantic gameplay.

-- 
David Kastrup

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

[Dmitry Gutov]

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.

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

[Paul Eggert]

Dmitry Gutov wrote:
> They aren't markup, because you insist that they "stand for themselves"

They’re both.  They’re markup that typically stand for themselves when 
generating text, and that’s a win over markup that doesn’t do that.  It’s like 
Markdown’s syntax for URLs: you just type http://example.com and it just works. 
  (Emacs docstrings would do well to support that idea too, but I’m digressing....)

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

[Dmitry Gutov]

On 09/03/2015 08:42 PM, Paul Eggert wrote:

> They’re both.  They’re markup that typically stand for themselves when

You can just as well call the letters of the alphabet "markup that 
stands for itself". Or, less contrivedly, programming language keywords 
or words with typos (which flyspell will highlight).

> generating text, and that’s a win over markup that doesn’t do that.

Not at all. It's more error prone:

If the programmer types `foo`, they can look at the output and see that 
the quotes were not recognized as a matching pair (don't render as 
expected).

If the programmer types ‘foo‘, they can easily miss the non-matching 
quotes if they expect the output to look the same as input. Everyone who 
configured Emacs to render quotes differently will bear the pain of that 
mistake, but not the author.

> It’s like Markdown’s syntax for URLs: you just type http://example.com
> and it just works.  (Emacs docstrings would do well to support that idea
> too, but I’m digressing....)

It's no syntax, just auto-linkification in the renderer. And it's 
notoriously error-prone; the types of URLs that get broken during 
auto-linkification change from program to program.

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

[Paul Eggert]

Dmitry Gutov wrote:
> It's more error prone:
>
> If the programmer types `foo`, they can look at the output and see that the
> quotes were not recognized as a matching pair (don't render as expected).
>
> If the programmer types ‘foo‘, they can easily miss the non-matching quotes

First, the two scenarios are the same in the typical text-quoting-style case, 
because the output looks like ‘foo‘ either way, and whatever method works for 
detecting input `foo` will work equally well for detecting input ‘foo‘.

Second and more important, it’s more efficient to detect and fix this issue 
immediately while typing, as the highlighting around the foo won’t be as 
expected and a programmer can see that easily right away and just backspace and 
fix the bad quote while it’s fresh. It’d be considerably more awkward and 
error-prone to detect the problem only when it’s rendered into a *Help* buffer.

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

[Dmitry Gutov]

On 09/04/2015 12:50 AM, Paul Eggert wrote:

>> If the programmer types ‘foo‘, they can easily miss the non-matching
>> quotes
>
> First, the two scenarios are the same in the typical text-quoting-style
> case, because the output looks like ‘foo‘ either way,

Not if the translation logic checks for pairing. This is not true of the 
current code (IIUC), but it was true not too long ago, and that's what 
Stefan's asking for as well.

> and whatever
> method works for detecting input `foo` will work equally well for
> detecting input ‘foo‘.

What method are you thinking of? Lint-like highlighting in red is only 
feasible if the syntax is strict.

> Second and more important, it’s more efficient to detect and fix this
> issue immediately while typing, as the highlighting around the foo won’t
> be as expected and a programmer can see that easily right away and just
> backspace and fix the bad quote while it’s fresh.

Checking highlighting is good, but it only works when we're quoting 
simple symbols. Not Lisp expressions, key sequences or anything else 
like that.

Also, please recall that highlighting is performed in Lisp. Since you've 
opted to do translation in C, font-lock cannot accurately handle the 
quoting syntax, with escapes and etc.

> It’d be considerably
> more awkward and error-prone to detect the problem only when it’s
> rendered into a *Help* buffer.

Checking that the output looks right is a natural urge either way.

My main point is, in general, non-translating "markup" invites typos.

Emacs is powerful enough to paper over many problems, but maybe one 
should take a hint earlier and spend effort where it really matters.

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

[Paul Eggert]

Dmitry Gutov wrote:
> On 09/04/2015 12:50 AM, Paul Eggert wrote:
>
>>> If the programmer types ‘foo‘, they can easily miss the non-matching
>>> quotes
>>
>> First, the two scenarios are the same in the typical text-quoting-style
>> case, because the output looks like ‘foo‘ either way,
>
> Not if the translation logic checks for pairing.

Ah, sorry, I thought the context was the current Emacs master, not Emacs after 
some further changes are applied to it.  In the current master most of the 
problems you mentioned are not a big deal in practice, as typically there's 
immediate visual feedback when one types the wrong quote.  It is true that in 
some more-complicated cases this breaks down, but this is a nearly inevitable 
consequence of any markup syntax that uses quotes to represent so many different 
concepts, regardless of whether the syntax uses ASCII or curved quotes.

You are correct in that if we came up with a different markup syntax that was 
more systematic and organized, many of these more-complicated cases would work 
better.

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

[Dmitry Gutov]

On 09/04/2015 01:47 AM, Paul Eggert wrote:

> Ah, sorry, I thought the context was the current Emacs master, not Emacs
> after some further changes are applied to it.

The context is what Emacs master had been not too long ago, as well as 
what it'll most likely be in the future.

> In the current master
> most of the problems you mentioned are not a big deal in practice, as
> typically there's immediate visual feedback when one types the wrong
> quote.

You keep saying "not a big deal in practice". The original problem 
(straight quotes) never was a "big deal in practice", yet you saw fit to 
introduce many changes to fix it. Fixing it while keeping many known 
(and new) shortcomings doesn't make sense.

> It is true that in some more-complicated cases this breaks down,
> but this is a nearly inevitable consequence of any markup syntax that
> uses quotes to represent so many different concepts, regardless of
> whether the syntax uses ASCII or curved quotes.

Not if the programmer looks at the output (a Help buffer, for example). 
The output will necessarily be "correct". However, like I wrote, if the 
output is the same as input by default, looking at the output won't help 
you find problems.

> You are correct in that if we came up with a different markup syntax
> that was more systematic and organized, many of these more-complicated
> cases would work better.

Doing everything better is not a necessary condition. Doing only some of 
the things better might suffice.

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

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

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

They can write anything they like in their own programs, but it's not "fine".
They are not supposed to do this in the Emacs sources.

The Lisp Intro should show recommended practice, not complicate
matters with other ways.  So please remove the curly quotes from the
Lisp Intro (and any other manuals).

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: [Emacs-diffs] master 9ffb6ce 5/5: Quoting fixes in lisp/international and lisp/leim

[Dmitry Gutov]

On 08/31/2015 09:12 AM, Paul Eggert wrote:

> -	   (insert "Don't output anything.\n"))
> +	   (insert "Don’t output anything.\n"))

I thought you were going to consider translating unpaired quotes, too?

Re: [Emacs-diffs] master 9ffb6ce 5/5: Quoting fixes in lisp/international and lisp/leim

[Paul Eggert]

Dmitry Gutov wrote:
> On 08/31/2015 09:12 AM, Paul Eggert wrote:
>
>> -       (insert "Don't output anything.\n"))
>> +       (insert "Don’t output anything.\n"))
>
> I thought you were going to consider translating unpaired quotes, too?

Yes, they're translated.  I just forgot to translate that one.  Fixed in master 
commit 6514fe88904e658c527deae5be9a3f6ac539653f.

Re: [Emacs-diffs] master 9ffb6ce 5/5: Quoting fixes in lisp/international and lisp/leim

[Stefan Monnier]

>> -	   (insert "Don't output anything.\n"))
>> +	   (insert "Don’t output anything.\n"))
> I thought you were going to consider translating unpaired quotes, too?

I'm not sure I'm following.  Can someone explain to me what's the issue
at play here?

And to give some background: I'm a bit worried about having too much
magic going on, so in general automatic conversion should be avoided
unless it's *really* often useful and *really* rarely problematic.


        Stefan

Re: [Emacs-diffs] master 9ffb6ce 5/5: Quoting fixes in lisp/international and lisp/leim

[Dmitry Gutov]

On 08/31/2015 08:34 PM, Stefan Monnier wrote:

> I'm not sure I'm following.  Can someone explain to me what's the issue
> at play here?

IIUC your question, the issue is whether (substitute-command-keys "'") 
returns "'" or "’". It does the latter now.

I'm fine with that, e.g. because it simplifies our ability to keep 
straight quotes (or some other markup) in the source code and show the 
curly quotes to the user.

But it seems to be too much to expect Paul to toe that line. The frog is 
pretty much boiled by now.

Re: [Emacs-diffs] master 9ffb6ce 5/5: Quoting fixes in lisp/international and lisp/leim

[Paul Eggert]

Stefan Monnier wrote:
>>> +	   (insert "Don’t output anything.\n"))
>> >I thought you were going to consider translating unpaired quotes, too?
> I'm not sure I'm following.  Can someone explain to me what's the issue
> at play here?

Currently, all apostrophes and right single quotation marks are translated in 
docstrings and diagnostics, even isolated ones such as the example above. 
Dmitry was wondering whether this is the case: it's something he suggested 
earlier and I implemented it that way, but I guess he wasn't sure whether I'd 
done it.

> I'm a bit worried about having too much
> magic going on, so in general automatic conversion should be avoided
> unless it's *really*  often useful and *really*  rarely problematic.

One alternative is to go with a system that normally has no translation, where 
Emacs source-code docstrings and diagnostics use curved quotes that merely stand 
for themselves, and where all curved quotes are displayed/searched-for/yanked as 
ASCII approximations for users who prefer the traditional style.  This would 
remove the need for format-message and/or substitute-command-keys doing any 
quote translation.  A downside is that source code docstrings and diagnostics 
would need to be converted to use curved quotes.

Re: [Emacs-diffs] master 9ffb6ce 5/5: Quoting fixes in lisp/international and lisp/leim

[David Kastrup]

Paul Eggert <eggert@cs.ucla.edu> writes:

> One alternative is to go with a system that normally has no
> translation, where Emacs source-code docstrings and diagnostics use
> curved quotes that merely stand for themselves, and where all curved
> quotes are displayed/searched-for/yanked as ASCII approximations for
> users who prefer the traditional style.  This would remove the need
> for format-message and/or substitute-command-keys doing any quote
> translation.  A downside is that source code docstrings and
> diagnostics would need to be converted to use curved quotes.

Well, it would save us from horribly wrong DOC strings like

quote is a special form in ‘C source code’.

(quote ARG)

Return the argument, without evaluating it.  ‘(quote x)’ yields ‘x’.
Warning: ‘quote’ does not construct its return value, but just returns
the value that was pre-constructed by the Lisp reader (see info node
‘(elisp)Printed Representation’).
This means that ’(a . b) is not identical to (cons ’a ’b): the former
does not cons.  Quoting should be reserved for constants that will
never be modified by side-effects, unless you like self-modifying code.
See the common pitfall in info node ‘(elisp)Rearrangement’ for an example
of unexpected results when a quoted object is modified.

[back]

Sometimes a quote is just a quote.

-- 
David Kastrup

Re: [Emacs-diffs] master 9ffb6ce 5/5: Quoting fixes in lisp/international and lisp/leim

[Stefan Monnier]

>> -	   (insert "Don't output anything.\n"))
>> +	   (insert "Don’t output anything.\n"))
> I thought you were going to consider translating unpaired quotes, too?

One more thing: while I think many people find "`foo'" is visually ugly,
the number of people who find "don't" ugly is probably much smaller.

So I don't see a strong need to go through extra efforts to convert
"don't" to "don’t".  I'm not even sure if "don’t" is typographically
better than "don't" (after all, last I checked the little thingy is
supposed to be an "apostrophe", not a "right single quotation mark").


        Stefan

Re: [Emacs-diffs] master 9ffb6ce 5/5: Quoting fixes in lisp/international and lisp/leim

[Paul Eggert]

Stefan Monnier wrote:
> I'm not even sure if "don’t" is typographically
> better than "don't" (after all, last I checked the little thingy is
> supposed to be an "apostrophe", not a "right single quotation mark").

Typographically it's not an issue: in non-typewriter English, U+2019 RIGHT 
SINGLE QUOTATION MARK is supposed to be use for elision (“don’t”), for closing a 
single quotation (“He said ‘no’.”) and for grammar (“Those are my sisters’ 
books.”).  It's the same character for all three.  See, for example, 
<http://www.languagegeek.com/typography/apostrophes.html>.

> I don't see a strong need to go through extra efforts to convert
> "don't" to "don’t".

Me neither, but most of the "don't"s are converted automatically anyway, and I 
figured it's not hard to convert the few odd stragglers if only to avoid 
complaints from typography obsessives down the road....

Re: [Emacs-diffs] master 9ffb6ce 5/5: Quoting fixes in lisp/international and lisp/leim

[Stephen J. Turnbull]

Paul Eggert writes:

 > Me neither, but most of the "don't"s are converted automatically
 > anyway, and I figured it's not hard to convert the few odd
 > stragglers if only to avoid complaints from typography obsessives
 > down the road....

At the cost of turning emacs-devel into a torrent of complaints from
typography obsessives now....

Re: [Emacs-diffs] master 9ffb6ce 5/5: Quoting fixes in lisp/international and lisp/leim

[Stefan Monnier]

>> I'm not even sure if "don’t" is typographically
>> better than "don't" (after all, last I checked the little thingy is
>> supposed to be an "apostrophe", not a "right single quotation mark").
> Typographically it's not an issue: in non-typewriter English, U+2019 RIGHT
> SINGLE QUOTATION MARK is supposed to be use for elision (“don’t”), for
> closing a single quotation (“He said ‘no’.”) and for grammar (“Those are my
> sisters’ books.”).  It's the same character for all three.  See, for
> example, <http://www.languagegeek.com/typography/apostrophes.html>.

I think in the context of Emacs, if we have to choose between ' and ’
and there's not a strong reason to prefer the non-ASCII char, we
should stick with the ASCII char.

The only thing we're trying to fix here is the ugly `...' quoting.
I don't see any need to change anything else at this stage.


        Stefan

Re: [Emacs-diffs] master 9ffb6ce 5/5: Quoting fixes in lisp/international and lisp/leim

[Paul Eggert]

Stefan Monnier wrote:
> if we have to choose between ' and ’
> and there's not a strong reason to prefer the non-ASCII char, we
> should stick with the ASCII char.

The reason is that it's simpler for ‘message’ etc. to transliterate every 
apostrophe than to employ more-complicated heuristics that are typically wrong 
anyway, typographically speaking.  But I take your point that I should stop 
worrying about messages that merely say “Don't”.

Re: [Emacs-diffs] master 9ffb6ce 5/5: Quoting fixes in lisp/international and lisp/leim

[Oleh Krehel]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> I'm not even sure if "don’t" is typographically
>>> better than "don't" (after all, last I checked the little thingy is
>>> supposed to be an "apostrophe", not a "right single quotation mark").
>> Typographically it's not an issue: in non-typewriter English, U+2019 RIGHT
>> SINGLE QUOTATION MARK is supposed to be use for elision (“don’t”), for
>> closing a single quotation (“He said ‘no’.”) and for grammar (“Those are my
>> sisters’ books.”).  It's the same character for all three.  See, for
>> example, <http://www.languagegeek.com/typography/apostrophes.html>.
>
> I think in the context of Emacs, if we have to choose between ' and ’
> and there's not a strong reason to prefer the non-ASCII char, we
> should stick with the ASCII char.
>
> The only thing we're trying to fix here is the ugly `...' quoting.
> I don't see any need to change anything else at this stage.

I'd like to present a data point: there are 32725 occurrences of "don't"
in the Emacs git repository, and only 10 occurrences of "don’t".

And to restate my opinion on the matter, since I haven't participated in
this discussion for a few months: Elisp code should be treated as
markup. Markup should be easy to view and enter: and since Emacs' main
language is English, the markup should be easy to enter in the most
common English keyboard layout and be easy to read in the most common
English locale.

If it were up to me, I'd revert everything until there wasn't a single
curly in the code part. Having markup that translates to curlies is
absolutely fine with me. But even that should be configurable, and I
would configure my Emacs to go without the option because I hate to see
curlies.

Also one of the most popular markup formats - Markdown
(http://daringfireball.net/projects/markdown/syntax) uses plain ASCII
for markup. One of the reasons for the change in Emacs was something
about texinfo having curlies. Well, Markdown is a competing format that
is way more popular than texinfo. And while a Markdown renderer can
translate "don't" into "don’t", and I'm pretty sure it does so by
default, the markup itself still remains ASCII and is easy to enter,
modify and view.

It's just a matter of convenience, which is one of Emacs' strengths:

- Entering "'" with a single key on my pinky is convenient.
- Entering "’" with "C-x 8" isn't.
- Grepping for "don't.*foo" is convenient.
- Grepping for "\(don’t\)\|\(don't\).*foo" isn't convenient.

Oleh

Re: [Emacs-diffs] master 9ffb6ce 5/5: Quoting fixes in lisp/international and lisp/leim

[Andreas Schwab]

Oleh Krehel <ohwoeowho@gmail.com> writes:

> - Grepping for "\(don’t\)\|\(don't\).*foo" isn't convenient.

It's also wrong. "don['’]t.*foo"

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: [Emacs-diffs] master 9ffb6ce 5/5: Quoting fixes in lisp/international and lisp/leim

[David Kastrup]

Oleh Krehel <ohwoeowho@gmail.com> writes:

> And to restate my opinion on the matter, since I haven't participated in
> this discussion for a few months: Elisp code should be treated as
> markup. Markup should be easy to view and enter: and since Emacs' main
> language is English, the markup should be easy to enter in the most
> common English keyboard layout and be easy to read in the most common
> English locale.

DOC strings are only marginally cooked and contain code examples.  Code
examples obviously contains ' and ` in their Lisp meaning.  Code
examples are copied&pasted into actual code.

So if ` and ' are supposed to be "markup" for ‘ and ’, we obviously need
a markup variant for either code passages or unmolested ` and '.

Has anything like that been proposed?  I repeat the documentation help
from the `quote' macro:

    quote is a special form in ‘C source code’.

    (quote ARG)

    Return the argument, without evaluating it.  ‘(quote x)’ yields ‘x’.
    Warning: ‘quote’ does not construct its return value, but just returns
    the value that was pre-constructed by the Lisp reader (see info node
    ‘(elisp)Printed Representation’).
    This means that ’(a . b) is not identical to (cons ’a ’b): the former
    does not cons.  Quoting should be reserved for constants that will
    never be modified by side-effects, unless you like self-modifying code.
    See the common pitfall in info node ‘(elisp)Rearrangement’ for an example
    of unexpected results when a quoted object is modified.

It contains both quote marks as well as Lisp quote characters.
Executing the given examples yields "void variable ’"&"Trailing garbage
following expression" and "void variable ’a" respectively.

Info does not have this problem because Texinfo markup marks code
passages separately, and for those, ` and ' are not substituted.

So this just can't work in DOC strings until we have decided on separate
markup for either ` and ' or code in general.

-- 
David Kastrup

Re: [Emacs-diffs] master 9ffb6ce 5/5: Quoting fixes in lisp/international and lisp/leim

[Oleh Krehel]

David Kastrup <dak@gnu.org> writes:

> Has anything like that been proposed?  I repeat the documentation help
> from the `quote' macro:
>
>     quote is a special form in ‘C source code’.
>
>     (quote ARG)
>
>     Return the argument, without evaluating it.  ‘(quote x)’ yields ‘x’.
>     Warning: ‘quote’ does not construct its return value, but just returns
>     the value that was pre-constructed by the Lisp reader (see info node
>     ‘(elisp)Printed Representation’).
>     This means that ’(a . b) is not identical to (cons ’a ’b): the former
>     does not cons.  Quoting should be reserved for constants that will
>     never be modified by side-effects, unless you like self-modifying code.
>     See the common pitfall in info node ‘(elisp)Rearrangement’ for an example
>     of unexpected results when a quoted object is modified.
>
> It contains both quote marks as well as Lisp quote characters.
> Executing the given examples yields "void variable ’"&"Trailing garbage
> following expression" and "void variable ’a" respectively.
>
> Info does not have this problem because Texinfo markup marks code
> passages separately, and for those, ` and ' are not substituted.
>
> So this just can't work in DOC strings until we have decided on separate
> markup for either ` and ' or code in general.

This could be solved in a variety of ways while keeping to ASCII.  For
instance, either "''" or "\'" could translate into "'" unconditionally.

I would prefer the way Markdown does it: `(cons 'a 'b)` translates into
<code>(cons 'a 'b)</code>. I've been using a similar style for org-mode,
only with different escape chars:

- =(cons 'a 'b)= to denote code
- ~C-a C-k~ to denote keyboard sequences

Re: [Emacs-diffs] master 9ffb6ce 5/5: Quoting fixes in lisp/international and lisp/leim

[Dmitry Gutov]

On 09/01/2015 02:22 PM, David Kastrup wrote:

> So if ` and ' are supposed to be "markup" for ‘ and ’, we obviously need
> a markup variant for either code passages or unmolested ` and '.
>
> Has anything like that been proposed?

We have \\= escaping syntax, see `substitute-command-keys'.

Re: [Emacs-diffs] master 9ffb6ce 5/5: Quoting fixes in lisp/international and lisp/leim

[David Kastrup]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 09/01/2015 02:22 PM, David Kastrup wrote:
>
>> So if ` and ' are supposed to be "markup" for ‘ and ’, we obviously need
>> a markup variant for either code passages or unmolested ` and '.
>>
>> Has anything like that been proposed?
>
> We have \\= escaping syntax, see `substitute-command-keys'.

Spells more or less death for cut&paste from some help buffer into the
_source_ of a DOC string, doesn't it?  Sure, backslashes already have
that effect, but at least this is due to string syntax rather than some
obscure markup processor.

-- 
David Kastrup

Re: [Emacs-diffs] master 9ffb6ce 5/5: Quoting fixes in lisp/international and lisp/leim

[Dmitry Gutov]

On 09/01/2015 03:06 PM, David Kastrup wrote:

>> We have \\= escaping syntax, see `substitute-command-keys'.
>
> Spells more or less death for cut&paste from some help buffer into the
> _source_ of a DOC string, doesn't it?  Sure, backslashes already have
> that effect, but at least this is due to string syntax rather than some
> obscure markup processor.

Like you said, any escaping syntax spells death for cut&paste.

Due to how Elisp reader works, we simply can't use backslashes in the 
docstrings. Or we'll need a lot of them.

Re: [Emacs-diffs] master 9ffb6ce 5/5: Quoting fixes in lisp/international and lisp/leim

[Oleh Krehel]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 09/01/2015 03:06 PM, David Kastrup wrote:
>
>>> We have \\= escaping syntax, see `substitute-command-keys'.
>>
>> Spells more or less death for cut&paste from some help buffer into the
>> _source_ of a DOC string, doesn't it?  Sure, backslashes already have
>> that effect, but at least this is due to string syntax rather than some
>> obscure markup processor.
>
> Like you said, any escaping syntax spells death for cut&paste.

Cut and paste can still work: just add a `quote-last-yank' command and/or
`quote-region' command. I've been using similar commands for posting
copy-pasted code to Stack websites. Here's a snippet I use for quoting
pasted code in Markdown:

    (defun ora-markdown-stack-block (beg end)
      (interactive "r")
      (let ((str (buffer-substring-no-properties beg end)))
        (delete-region beg end)
        (insert
         "<!-- language: lang-cl -->\n\n    "
         (mapconcat
          #'identity
          (split-string str "\n" t)
          "\n    "))))

An issue that I have with \\= escaping syntax is that it's ugly.  One
reason for success of Markdown (also Org-mode) is that it looks good
enough even in source form, i.e. not exported or rendered. Therefore, I
propose we move from this:

    (defcustom auto-insert 'not-modified
    ...
    This variable is used when the function `auto-insert' is called, e.g.
    when you do (add-hook \\='find-file-hook \\='auto-insert).

to this:

    This variable is used when the function `auto-insert' is called, e.g.
    when you do ``(add-hook 'find-file-hook 'auto-insert)''.

Note how ``(add-hook 'find-file-hook 'auto-insert)'' looks good enough
even in plain text form, with no extra highlighting. Much better than
(add-hook \\='find-file-hook \\='auto-insert). And it's easy to copy
paste and quote with a simple command that just adds 4 chars around a
region.

Also, it would be very easy to modify font-lock to add extra
highlighting for ``...'' blocks, since they're so easy to parse.

In the unlikely case when someone wants a code block with two
consecutive apostrophes, the old \\=' approach can be used. The quoting
function could even do this automatically, i.e. quote any apostrophes in
the region appropriately.

For code blocks, we could use an empty line followed by 4 spaces indent.

I think there's value in having asymmetric delimiters, since that eases
the job of font-lock by a lot. The current `markdown-mode' breaks
highlighting very often because of symmetric delimiters.

Oleh

Re: [Emacs-diffs] master 9ffb6ce 5/5: Quoting fixes in lisp/international and lisp/leim

[Dmitry Gutov]

On 09/03/2015 01:16 PM, Oleh Krehel wrote:

>> Like you said, any escaping syntax spells death for cut&paste.
>
> Cut and paste can still work: just add a `quote-last-yank' command and/or
> `quote-region' command.

But it's not always that you'll want to quote the pasted string, is it?

> An issue that I have with \\= escaping syntax is that it's ugly.

It looks a bit odd, but we're unlikely to get rid of it, since it's been 
supported for ages.

>      This variable is used when the function `auto-insert' is called, e.g.
>      when you do ``(add-hook 'find-file-hook 'auto-insert)''.

Looks fine to me.

> Note how ``(add-hook 'find-file-hook 'auto-insert)'' looks good enough
> even in plain text form, with no extra highlighting. Much better than
> (add-hook \\='find-file-hook \\='auto-insert).

I think both options looks readable enough, but let's have two syntaxes 
if people find it that easier.

> For code blocks, we could use an empty line followed by 4 spaces indent.

Yup. Although we might catch some false positives that way.

> I think there's value in having asymmetric delimiters, since that eases
> the job of font-lock by a lot.

Either way, it would be weird to quote symbol references with ` ', but 
use `` `` for code expressions.

Re: [Emacs-diffs] master 9ffb6ce 5/5: Quoting fixes in lisp/international and lisp/leim

[Stefan Monnier]

>> Cut and paste can still work: just add a `quote-last-yank' command and/or
>> `quote-region' command.
> But it's not always that you'll want to quote the pasted string, is it?

That's why he's recommending a command.  You'd first yank and then (if
you needed) run the quote command, which quotes what you just yanked.
That's would be kind of like a "postfix argument".

>> An issue that I have with \\= escaping syntax is that it's ugly.
> It looks a bit odd, but we're unlikely to get rid of it, since it's been
> supported for ages.

It's been supported for ages, yes, but until recently it was *very*
rarely needed.  IOW the need to write

   (add-hook \\='find-file-hook \\='auto-insert)

is brand new in Emacs-25, and it sucks.

I don't intend to get rid of the \= escaping syntax (tho I do find it
hideous), but I don't want to have to use it, except for those very
limited use cases that are as old as the \= syntax itself.

>> This variable is used when the function `auto-insert' is called, e.g.
>> when you do ``(add-hook 'find-file-hook 'auto-insert)''.
> Looks fine to me.

Yes, I could live with it (and I could accept the use of "'\\='" for
those very rare cases where we need to have "''" inside the "...").

BTW, re-using existing quoting syntaxes from other systems (e.g.
markdown/org) is a good idea, when applicable.  E.g. it would be
desirable to be able to take a docstring and easily convert it to
a valid org/markdown document.  Of course, that needs to be balanced
with the needs specific to docstrings (among other things, to
accommodate pre-existing practice).

> Either way, it would be weird to quote symbol references with ` ', but use
> `` `` for code expressions.

I don't see why.


        Stefan

Re: [Emacs-diffs] master 9ffb6ce 5/5: Quoting fixes in lisp/international and lisp/leim

[Dmitry Gutov]

On 09/03/2015 05:50 PM, Stefan Monnier wrote:

> That's why he's recommending a command.  You'd first yank and then (if
> you needed) run the quote command, which quotes what you just yanked.
> That's would be kind of like a "postfix argument".

Ok.

> It's been supported for ages, yes, but until recently it was *very*
> rarely needed.  IOW the need to write
>
>     (add-hook \\='find-file-hook \\='auto-insert)
>
> is brand new in Emacs-25, and it sucks.

Note that you also wouldn't need it here if quote-matching code uses 
sorward-sexp.

> BTW, re-using existing quoting syntaxes from other systems (e.g.
> markdown/org) is a good idea, when applicable.  E.g. it would be
> desirable to be able to take a docstring and easily convert it to
> a valid org/markdown document.

True.

> > Either way, it would be weird to quote symbol references with ` ', 
but use
>> `` `` for code expressions.
>
> I don't see why.

For consistency, I'd say. Otherwise we probably risk more typos. 
Admittedly, I'm just guessing, but `` '' also looks a bit nicer to me.

Re: [Emacs-diffs] master 9ffb6ce 5/5: Quoting fixes in lisp/international and lisp/leim

[Paul Eggert]

David Kastrup wrote:
> I repeat the documentation help
> from the `quote' macro:

That was a typo, which I fixed in master commit 
a3c31adea4970b8a7fc7f495e6a6a6d4a93e69ce by escaping the apostrophe.  Thanks for 
reporting it.

Re: [Emacs-diffs] master 9ffb6ce 5/5: Quoting fixes in lisp/international and lisp/leim

[David Kastrup]

Paul Eggert <eggert@cs.ucla.edu> writes:

> David Kastrup wrote:
>> I repeat the documentation help
>> from the `quote' macro:
>
> That was a typo, which I fixed in master commit
> a3c31adea4970b8a7fc7f495e6a6a6d4a93e69ce by escaping the apostrophe.
> Thanks for reporting it.

Not as much a typo as an oversight.  That commit fixes 48 such
oversights and I think that everybody should read the accompanying diff
and ask himself whether he likes the results.

The respective necessary changes are a nuisance to read and a nuisance
to write.

I think this would be a better sell if the DOC strings got some general
markup for code/example that would then be output in an (unmolested)
typewriter font, with the source code inside of that markup again being
unmolested.  It would also be nicer in case people wanted to convert DOC
strings into Texinfo or HTML or other output formats where offsetting
code is a good possibility.

I very much should think that people would be more amenable to offset
code passages in some manner rather than mangle every quote character.

It's also a better sell to teach people to properly offset code passages
in mailing lists/discussion groups "for best results" rather than teach
the quote mangling.

That means coming up with a nice form of entering code, both inline and
as block, and then walk through all the doc strings (naturally, this
concerns even material not containing any quote characters).

It's probably a larger task than what has been done so far.  But I think
that the end result would be much more satisfactory and offer
_independent_ benefits.  And of course it would still allow selective
turning off all quote treatment reasonably easily.

-- 
David Kastrup

Re: [Emacs-diffs] master 9ffb6ce 5/5: Quoting fixes in lisp/international and lisp/leim

[Stefan Monnier]

> And to restate my opinion on the matter, since I haven't participated in
> this discussion for a few months: Elisp code should be treated as
> markup.  Markup should be easy to view and enter: and since Emacs' main
> language is English, the markup should be easy to enter in the most
> common English keyboard layout and be easy to read in the most common
> English locale.

I generally agree.  And to restate what I said earlier in more details,
what I'd like to see fixed is:
- `...' quoting is ugly.  This should be fixed in "end user display"
  mostly, tho I don't mind if it's also fixed in the source code.
- The `...' markup (and it is markup) is ambiguous.

So I thought we were going to replace the `...' markup with ‘...’ markup
(which fixes both points at the same time if we assume that we keep
sticking to ASCII quotes for the rest, tho at the cost of using
non-ASCII markup).

But if we start using curly quotes everywhere, then we're back with the
ambiguity, so that's not a good solution.

So maybe a better option is to refine the `...' markup to get rid of
the ambiguity.  E.g.:
- `...' is only considered valid markup if ... doesn't contain any
  whitespace (or some such restriction: it should be a simple rule that
  still accepts most existing uses, especially those where we want to
  place a hyperlink).
- All other occurrences of ` and ' are treated a standalone ASCII chars
  rather than as part of some markup.
  So `C-x C-f' is not valid markup any more (and won't be prettified).
- Introduce some other markup for the more general case.  Maybe this
  should be specific to docstrings, so it can be "somewhat verbose" and
  fairly rich/extensible.

At that point we could imagine rendering docstrings in more refined way
(e.g. using faces rather than curly quotes).


        Stefan

Re: [Emacs-diffs] master 9ffb6ce 5/5: Quoting fixes in lisp/international and lisp/leim

[Alan Mackenzie]

Hello, Stefan.

On Tue, Sep 01, 2015 at 11:39:53AM -0400, Stefan Monnier wrote:
> > And to restate my opinion on the matter, since I haven't participated in
> > this discussion for a few months: Elisp code should be treated as
> > markup.  Markup should be easy to view and enter: and since Emacs' main
> > language is English, the markup should be easy to enter in the most
> > common English keyboard layout and be easy to read in the most common
> > English locale.

> I generally agree.  And to restate what I said earlier in more details,
> what I'd like to see fixed is:
> - `...' quoting is ugly.  This should be fixed in "end user display"
>   mostly, tho I don't mind if it's also fixed in the source code.

Just to emphasize that `...' quoting is not at all ugly on my terminal -
in fact, it's rather elegant.  However, using curly quotes is
problematic.  I run on a Linux virtual terminal.

So, PLEASE can we have adequate configurability, so that the user can
decide for herself what's ugly, and whether it needs "fixing".

> - The `...' markup (and it is markup) is ambiguous.

> So I thought we were going to replace the `...' markup with ‘...’ markup
> (which fixes both points at the same time if we assume that we keep
> sticking to ASCII quotes for the rest, tho at the cost of using
> non-ASCII markup).

Yet again, can we please have any such transformations user
configurable?

[ .... ]

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [Emacs-diffs] master 9ffb6ce 5/5: Quoting fixes in lisp/international and lisp/leim

[Stefan Monnier]

> Just to emphasize that `...' quoting is not at all ugly on my terminal -
> in fact, it's rather elegant.

Indeed, the font I see in my Linux console renders them OK
(pre-XFree86-4 style), but I think you're sadly in a minority.

> However, using curly quotes is problematic.  I run on a Linux
> virtual terminal.

Curly quotes render just fine in my Linux console.  So it looks like
you're in an even smaller minority.

> So, PLEASE can we have adequate configurability, so that the user can
> decide for herself what's ugly, and whether it needs "fixing".

My request here is to figure out what *kind* of configurability is best.
Not whether configurability is desired.  But you're not very forthcoming
with information about the concrete problems you see with curly quotes,
so we're likely not going to be able to provide the best kind of
customizability for you.


        Stefan

Re: [Emacs-diffs] master 9ffb6ce 5/5: Quoting fixes in lisp/international and lisp/leim

[David Kastrup]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> Just to emphasize that `...' quoting is not at all ugly on my terminal -
>> in fact, it's rather elegant.
>
> Indeed, the font I see in my Linux console renders them OK
> (pre-XFree86-4 style), but I think you're sadly in a minority.
>
>> However, using curly quotes is problematic.  I run on a Linux
>> virtual terminal.
>
> Curly quotes render just fine in my Linux console.  So it looks like
> you're in an even smaller minority.

When assuming that the world only consists of Alan and Stefan, the word
"minority" does not make a lot of sense.  Assuming that "$x works for
Stefan's setup and $y doesn't" means that "$x doesn't work for $u but $y
does." is impossible for all values of u is a bit self-centric.

-- 
David Kastrup

Re: [Emacs-diffs] master 9ffb6ce 5/5: Quoting fixes in lisp/international and lisp/leim

[Alan Mackenzie]

Hello, Stefan.

On Wed, Sep 02, 2015 at 12:07:03AM -0400, Stefan Monnier wrote:
> > Just to emphasize that `...' quoting is not at all ugly on my terminal -
> > in fact, it's rather elegant.

> Indeed, the font I see in my Linux console renders them OK
> (pre-XFree86-4 style), but I think you're sadly in a minority.

There's nothing sad about being in a minority.  Anybody who runs Emacs
with her own .emacs is in a minority of one.  Anybody who runs Emacs on
a platform that isn't GNU/Linux or Microsoft Windows or an Apple Mac is
also in a minority.  For that matter, anybody running Emacs at all is in
a minority.

> > However, using curly quotes is problematic.  I run on a Linux
> > virtual terminal.

> Curly quotes render just fine in my Linux console.  So it looks like
> you're in an even smaller minority.

Using my  standard font, lat1-16, the curly quotes use the same glyphs as
` and ', hence are visibly indistinguishable from them.  I tried
creating my own glyphs for the curlies, and put them into a font,
discarding two French-language glyphs to make room.  They're ugly, but
more importantly, my eye can't reliably distinguish a standard quote
glyph from one of my new curly ones unless there's already a known quote
on the screen to compare it with.

But the ordinary user of a console is not going to have the time or
inclination to go mucking around with fonts.

> > So, PLEASE can we have adequate configurability, so that the user can
> > decide for herself what's ugly, and whether it needs "fixing".

> My request here is to figure out what *kind* of configurability is best.
> Not whether configurability is desired.  But you're not very forthcoming
> with information about the concrete problems you see with curly quotes,
> so we're likely not going to be able to provide the best kind of
> customizability for you.

All of what I write above I've written before.  In addition, the
necessity to type a C-x 8 combination to type a curly quote is a serious
impediment.  (For me, remapping ` and ' to things which aren't
self-insert-command (or an electric command) is so inelegant as not to
come into consideration).

The sort of customisability I'm asking for is that in which the user
decides whether ASCII or curly quoting characters are used in *Help*,
messages, etc.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [Emacs-diffs] master 9ffb6ce 5/5: Quoting fixes in lisp/international and lisp/leim

[Dmitry Gutov]

Hi Alan,

On 09/02/2015 01:02 PM, Alan Mackenzie wrote:

> All of what I write above I've written before.  In addition, the
> necessity to type a C-x 8 combination to type a curly quote is a serious
> impediment.  (For me, remapping ` and ' to things which aren't
> self-insert-command (or an electric command) is so inelegant as not to
> come into consideration).

Is that a real problem?

As long as curly quotes are relegated to displayed messages and Help 
buffers, you'll never need to type them as input for external tools.

And as for isearch, in the rare cases where looking for a beginning of a 
symbol reference is important, you could input \_< or \_> instead.

That may be a bit worse than just typing `, but if we do highlighting 
with faces (which I think is a good idea to transition to), searching 
for ` won't work either.

Re: [Emacs-diffs] master 9ffb6ce 5/5: Quoting fixes in lisp/international and lisp/leim

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > As long as curly quotes are relegated to displayed messages and Help 
  > buffers, you'll never need to type them as input for external tools.

  > And as for isearch, in the rare cases where looking for a beginning of a 
  > symbol reference is important, you could input \_< or \_> instead.

I think you're right -- but that's not how it seems things are.
We were informed today that there are over
900 curly quotes in the Emacs sources now.
Why are they in the sources?
-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: [Emacs-diffs] master 9ffb6ce 5/5: Quoting fixes in lisp/international and lisp/leim

[Dmitry Gutov]

On 09/02/2015 06:41 PM, Richard Stallman wrote:

> I think you're right -- but that's not how it seems things are.
> We were informed today that there are over
> 900 curly quotes in the Emacs sources now.
> Why are they in the sources?

Because Paul put them there, even though objections were raised.

Re: [Emacs-diffs] master 9ffb6ce 5/5: Quoting fixes in lisp/international and lisp/leim

[Paul Eggert]

Richard Stallman wrote:
> Why are they in the sources?

I discussed this in my email to you (cc: emacs-devel@gnu.org) dated yesterday 
with subject line "Re: [Emacs-diffs] master b533552 2/5: Documentation fixes re 
quotes".  It's archived here:

http://lists.gnu.org/archive/html/emacs-devel/2015-09/msg00072.html

Re: [Emacs-diffs] master 9ffb6ce 5/5: Quoting fixes in lisp/international and lisp/leim

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > Why are they in the sources?

  > I discussed this in my email to you (cc: emacs-devel@gnu.org) dated yesterday 
  > with subject line "Re: [Emacs-diffs] master b533552 2/5: Documentation fixes re

There were quite a few messages with precisely that subject,
but I eventually found yours.

Are you saying that curly quotes are current present only in those
.texi files?

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: [Emacs-diffs] master 9ffb6ce 5/5: Quoting fixes in lisp/international and lisp/leim

[Paul Eggert]

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

Richard Stallman wrote:
> Are you saying that curly quotes are current present only in those
> .texi files?

I do not know which .texi files you are referring to, but no, I am not saying 
that.  Curved single quotes are present in .texi files, in .el files, .c files, 
an .h file, ChangeLog files, etc/NEWS, etc/PROBLEMS, a tutorial file, and an 
HTML file.  You can list source files containing curved quotes by running the 
following shell command:

grep -l '[‘’]' $(git ls-files | sort)

[-- Attachment #2: files-with-curved-single-quotes.txt --]
[-- Type: text/plain, Size: 5962 bytes --]

ChangeLog.1
ChangeLog.2
admin/unidata/copyright.html
admin/unidata/unidata-gen.el
doc/emacs/basic.texi
doc/emacs/modes.texi
doc/emacs/mule.texi
doc/emacs/text.texi
doc/lispintro/emacs-lisp-intro.texi
doc/lispref/ChangeLog.1
doc/lispref/control.texi
doc/lispref/functions.texi
doc/lispref/help.texi
doc/lispref/modes.texi
doc/lispref/os.texi
doc/lispref/processes.texi
doc/lispref/strings.texi
doc/lispref/text.texi
doc/lispref/tips.texi
doc/misc/ede.texi
doc/misc/efaq.texi
doc/misc/eieio.texi
doc/misc/gnus-faq.texi
doc/misc/gnus.texi
doc/misc/rcirc.texi
etc/NEWS
etc/PROBLEMS
etc/tutorials/TUTORIAL.nl
lisp/ChangeLog.17
lisp/abbrev.el
lisp/align.el
lisp/allout-widgets.el
lisp/allout.el
lisp/apropos.el
lisp/bookmark.el
lisp/bs.el
lisp/button.el
lisp/calc/calc-aent.el
lisp/calc/calc-embed.el
lisp/calc/calc-ext.el
lisp/calc/calc-graph.el
lisp/calc/calc-help.el
lisp/calc/calc-lang.el
lisp/calc/calc-misc.el
lisp/calc/calc-mode.el
lisp/calc/calc-prog.el
lisp/calc/calc-store.el
lisp/calc/calc-units.el
lisp/calc/calc-vec.el
lisp/calc/calc-yank.el
lisp/calc/calc.el
lisp/calendar/appt.el
lisp/calendar/cal-bahai.el
lisp/calendar/diary-lib.el
lisp/calendar/icalendar.el
lisp/calendar/time-date.el
lisp/calendar/timeclock.el
lisp/calendar/todo-mode.el
lisp/cedet/cedet-global.el
lisp/cedet/ede/pmake.el
lisp/cedet/mode-local.el
lisp/cedet/semantic/complete.el
lisp/cedet/semantic/java.el
lisp/cedet/srecode/srt-mode.el
lisp/cedet/srecode/texi.el
lisp/character-fold.el
lisp/cus-start.el
lisp/cus-theme.el
lisp/custom.el
lisp/descr-text.el
lisp/dired-x.el
lisp/dired.el
lisp/electric.el
lisp/emacs-lisp/advice.el
lisp/emacs-lisp/byte-opt.el
lisp/emacs-lisp/byte-run.el
lisp/emacs-lisp/bytecomp.el
lisp/emacs-lisp/cconv.el
lisp/emacs-lisp/chart.el
lisp/emacs-lisp/check-declare.el
lisp/emacs-lisp/checkdoc.el
lisp/emacs-lisp/cl-extra.el
lisp/emacs-lisp/cl-generic.el
lisp/emacs-lisp/cl-macs.el
lisp/emacs-lisp/cl.el
lisp/emacs-lisp/copyright.el
lisp/emacs-lisp/derived.el
lisp/emacs-lisp/edebug.el
lisp/emacs-lisp/eieio-base.el
lisp/emacs-lisp/eieio-core.el
lisp/emacs-lisp/eieio-opt.el
lisp/emacs-lisp/eieio-speedbar.el
lisp/emacs-lisp/eieio.el
lisp/emacs-lisp/elint.el
lisp/emacs-lisp/ert.el
lisp/emacs-lisp/find-func.el
lisp/emacs-lisp/generator.el
lisp/emacs-lisp/gv.el
lisp/emacs-lisp/lisp-mnt.el
lisp/emacs-lisp/lisp-mode.el
lisp/emacs-lisp/macroexp.el
lisp/emacs-lisp/map-ynp.el
lisp/emacs-lisp/nadvice.el
lisp/emacs-lisp/package-x.el
lisp/emacs-lisp/package.el
lisp/emacs-lisp/pcase.el
lisp/emacs-lisp/re-builder.el
lisp/emacs-lisp/ring.el
lisp/emacs-lisp/rx.el
lisp/emacs-lisp/smie.el
lisp/emacs-lisp/subr-x.el
lisp/emacs-lisp/tabulated-list.el
lisp/emacs-lisp/testcover.el
lisp/emacs-lisp/timer.el
lisp/emulation/viper-cmd.el
lisp/emulation/viper-init.el
lisp/emulation/viper-macs.el
lisp/env.el
lisp/erc/erc-button.el
lisp/erc/erc-dcc.el
lisp/erc/erc.el
lisp/eshell/em-dirs.el
lisp/eshell/em-glob.el
lisp/eshell/em-pred.el
lisp/eshell/em-script.el
lisp/eshell/esh-opt.el
lisp/eshell/esh-var.el
lisp/facemenu.el
lisp/faces.el
lisp/files-x.el
lisp/files.el
lisp/filesets.el
lisp/find-cmd.el
lisp/finder.el
lisp/font-lock.el
lisp/format.el
lisp/frame.el
lisp/fringe.el
lisp/gnus/gnus-art.el
lisp/gnus/nnmairix.el
lisp/help-fns.el
lisp/help-mode.el
lisp/help.el
lisp/htmlfontify.el
lisp/ibuffer.el
lisp/ido.el
lisp/image.el
lisp/info-look.el
lisp/info.el
lisp/international/ccl.el
lisp/international/fontset.el
lisp/international/iso-transl.el
lisp/international/latin1-disp.el
lisp/international/mule-cmds.el
lisp/international/mule-conf.el
lisp/international/mule-diag.el
lisp/json.el
lisp/kermit.el
lisp/ldefs-boot.el
lisp/leim/quail/cyrillic.el
lisp/leim/quail/greek.el
lisp/leim/quail/hebrew.el
lisp/leim/quail/latin-ltx.el
lisp/leim/quail/rfc1345.el
lisp/leim/quail/sgml-input.el
lisp/leim/quail/symbol-ksc.el
lisp/leim/quail/thai.el
lisp/leim/quail/tibetan.el
lisp/mail/feedmail.el
lisp/mail/rfc2368.el
lisp/mh-e/mh-comp.el
lisp/mh-e/mh-e.el
lisp/mh-e/mh-seq.el
lisp/mh-e/mh-utils.el
lisp/mouse.el
lisp/mpc.el
lisp/msb.el
lisp/net/ange-ftp.el
lisp/net/imap.el
lisp/net/mairix.el
lisp/net/newst-backend.el
lisp/net/newst-treeview.el
lisp/net/rcirc.el
lisp/net/rlogin.el
lisp/obsolete/iso-acc.el
lisp/obsolete/iswitchb.el
lisp/obsolete/landmark.el
lisp/obsolete/otodo-mode.el
lisp/obsolete/pgg-gpg.el
lisp/obsolete/pgg-pgp.el
lisp/obsolete/pgg-pgp5.el
lisp/obsolete/tpu-edt.el
lisp/obsolete/vi.el
lisp/org/ChangeLog.1
lisp/org/ob-core.el
lisp/org/ob-fortran.el
lisp/org/ob-python.el
lisp/org/ob-ref.el
lisp/org/ob-scheme.el
lisp/org/org-agenda.el
lisp/org/org-bibtex.el
lisp/org/org-clock.el
lisp/org/org-compat.el
lisp/org/org-ctags.el
lisp/org/org-entities.el
lisp/org/org-feed.el
lisp/org/org-habit.el
lisp/org/org-irc.el
lisp/org/org-mouse.el
lisp/org/org-plot.el
lisp/org/org-table.el
lisp/org/org.el
lisp/org/ox.el
lisp/pcmpl-cvs.el
lisp/play/bubbles.el
lisp/play/dunnet.el
lisp/play/gomoku.el
lisp/proced.el
lisp/progmodes/ada-mode.el
lisp/progmodes/ada-prj.el
lisp/progmodes/ada-xref.el
lisp/progmodes/ebrowse.el
lisp/progmodes/elisp-mode.el
lisp/progmodes/etags.el
lisp/progmodes/flymake.el
lisp/progmodes/idlw-shell.el
lisp/progmodes/idlwave.el
lisp/progmodes/make-mode.el
lisp/progmodes/python.el
lisp/progmodes/sql.el
lisp/progmodes/verilog-mode.el
lisp/progmodes/vhdl-mode.el
lisp/recentf.el
lisp/replace.el
lisp/scroll-bar.el
lisp/server.el
lisp/simple.el
lisp/startup.el
lisp/subr.el
lisp/term/common-win.el
lisp/term/x-win.el
lisp/textmodes/paragraphs.el
lisp/textmodes/reftex-ref.el
lisp/textmodes/reftex-toc.el
lisp/textmodes/table.el
lisp/textmodes/tex-mode.el
lisp/textmodes/texnfo-upd.el
lisp/textmodes/two-column.el
lisp/tutorial.el
lisp/type-break.el
lisp/vc/ediff-help.el
lisp/wdired.el
lisp/whitespace.el
lisp/wid-edit.el
lisp/woman.el
src/doc.c
src/doprnt.c
src/editfns.c
src/keyboard.c
src/lisp.h
test/automated/elisp-mode-tests.el
test/automated/ert-x-tests.el
test/automated/package-test.el
test/automated/textprop-tests.el

Re: [Emacs-diffs] master 9ffb6ce 5/5: Quoting fixes in lisp/international and lisp/leim

[Paul Eggert]

Alan Mackenzie wrote:
> Using my  standard font, lat1-16, the curly quotes use the same glyphs as
> ` and ', hence are visibly indistinguishable from them.

That's no longer true as of yesterday's master commit 
1a3518e7c361a9ceaa017c1334a83d14e0651a4e.  On a terminal that cannot display 
curved quotes, Emacs master now uses different glyphs for the quotes’ ASCII 
replacements, because the replacements are shadowed.  The shadowed glyphs are 
easily distinguishable on my Linux console.  Users shouldn’t need to configure 
Emacs specially, or their Linux console specially, to get this behavior.  So 
this objection no longer applies.

Re: [Emacs-diffs] master 9ffb6ce 5/5: Quoting fixes in lisp/international and lisp/leim

[Alan Mackenzie]

Hello, Paul.

On Wed, Sep 02, 2015 at 09:32:42AM -0700, Paul Eggert wrote:
> Alan Mackenzie wrote:
> > Using my  standard font, lat1-16, the curly quotes use the same glyphs as
> > ` and ', hence are visibly indistinguishable from them.

> That's no longer true as of yesterday's master commit 
> 1a3518e7c361a9ceaa017c1334a83d14e0651a4e.

I'm afraid it is still true.  After doing a C-h f c-mode, apparent
quotes were in the buffer.  Checking them with C-u C-x =, they were
indeed curly quotes, but were displayed the same as ASCII quotes.

> On a terminal that cannot display curved quotes, ...

Currently, my terminal is not such a one.  It _can_ display curly
quotes, but only identically to ASCII quotes.  `char-displayable-p'
returns 'unicode for them.

The issue is not so much whether a terminal can display curly quotes,
rather it's whether a user wants them to be used or not.

> .... Emacs master now uses different glyphs for the quotes’ ASCII
> replacements, because the replacements are shadowed.  The shadowed
> glyphs are easily distinguishable on my Linux console.  Users
> shouldn’t need to configure Emacs specially, or their Linux console
> specially, to get this behavior.  So this objection no longer applies.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [Emacs-diffs] master 9ffb6ce 5/5: Quoting fixes in lisp/international and lisp/leim

[David Kastrup]

Alan Mackenzie <acm@muc.de> writes:

> Hello, Paul.
>
> On Wed, Sep 02, 2015 at 09:32:42AM -0700, Paul Eggert wrote:
>> Alan Mackenzie wrote:
>> > Using my  standard font, lat1-16, the curly quotes use the same glyphs as
>> > ` and ', hence are visibly indistinguishable from them.
>
>> That's no longer true as of yesterday's master commit 
>> 1a3518e7c361a9ceaa017c1334a83d14e0651a4e.
>
> I'm afraid it is still true.  After doing a C-h f c-mode, apparent
> quotes were in the buffer.  Checking them with C-u C-x =, they were
> indeed curly quotes, but were displayed the same as ASCII quotes.

Man, this is like a renaissance of the Emacs 18 backspace/C-h
controversy.  "your terminal should"/"no, it doesn't"/"any sane terminal
described by termcap/terminfo/ADM3A compatibility"/"no, it doesn't".

This change is _not_ going to buy us any new users.  Reliability wins
over aesthetics (which can be ameliorated by font choices if you are
bothered) hands down, every time.

By the way, ' is an _apostrophe_.  Changing it to an open single quote
mark in words like "don't" is utterly wrong, having to write \\=' for
every word with an apostrophe is not a reasonable option.  Telling
apostrophes from right single quote marks is reasonably easy by looking
at the surrounding characters, but "reasonably easy" does not make for
an idiot-proof and idiot-rememberable rule.  So we are buying into some
"do what I mean" territory here, and advanced word processor users will
love to tell you how much they love "autocorrecting" quotes.

I really don't see any sane way around defining some satisfactorily
natural markup sequences for quoting literal material inline and in
blocks.

-- 
David Kastrup

Re: [Emacs-diffs] master 9ffb6ce 5/5: Quoting fixes in lisp/international and lisp/leim

[Paul Eggert]

On 09/02/2015 10:43 AM, David Kastrup wrote:
> ' is an_apostrophe_.  Changing it to an open single quote
> mark in words like "don't" is utterly wrong

I assume you meant “close single quote” not “open single quote”. (It 
would indeed be utterly wrong to transliterate apostrophe to open single 
quote, but Emacs doesn’t do that.)

The initial version of the quote-tranformation code behaved as you 
suggested, and left isolated apostrophes alone.  But Dmitry pointed out 
that apostrophe in English is represented by right single quotation mark 
as standard typographic practice in fonts with directed quotes, so I 
changed Emacs to translate all non-escaped apostrophes.  In practice 
most isolated apostrophes in docstrings and diagnostics are intended to 
be English apostrophes, so it seemed appropriate to transliterate them 
as in English, of course with an escape hatch for those intended to be 
Elisp apostrophes.

For more about common practice with apostrophes in natural-language 
text, please see <http://www.languagegeek.com/typography/apostrophes.html>.

Re: [Emacs-diffs] master 9ffb6ce 5/5: Quoting fixes in lisp/international and lisp/leim

[David Kastrup]

Paul Eggert <eggert@cs.ucla.edu> writes:

> On 09/02/2015 10:43 AM, David Kastrup wrote:
>> ' is an_apostrophe_.  Changing it to an open single quote
>> mark in words like "don't" is utterly wrong
>
> I assume you meant “close single quote” not “open single quote”. (It
> would indeed be utterly wrong to transliterate apostrophe to open
> single quote, but Emacs doesn’t do that.)
>
> The initial version of the quote-tranformation code behaved as you
> suggested, and left isolated apostrophes alone.  But Dmitry pointed
> out that apostrophe in English is represented by right single
> quotation mark as standard typographic practice in fonts with directed
> quotes, so I changed Emacs to translate all non-escaped apostrophes.
> In practice most isolated apostrophes in docstrings and diagnostics
> are intended to be English apostrophes, so it seemed appropriate to
> transliterate them as in English, of course with an escape hatch for
> those intended to be Elisp apostrophes.
>
> For more about common practice with apostrophes in natural-language
> text, please see
> <http://www.languagegeek.com/typography/apostrophes.html>.

Hardly a reputable source, and they mix up encoding with representation
awfully.

Looking up what the Unicode Consortium itself has to say about the issue
<URL:http://www.unicode.org/versions/Unicode8.0.0/ch06.pdf> tells us on
page 274:

    Punctuation Apostrophe. U+2019 right single quotation mark is
    preferred where the character is to represent a punctuation mark, as
    for contractions: \u201cWe\u2019ve been here before.\u201d In this
    latter case, U+2019 is also referred to as a punctuation apostrophe.

(by the way: is there any way to make Emacs stop this \u201c pasting
abomination when using C-y on an X Window selection?).  Well, the whole
world appears to have gone mad.  Why would they prefer a character
_explicitly_ called a right quote to a character called apostrophe when
writing an apostrophe?

But with regard to text processing (such as Word for Windows would do),
you clearly have the character set authorities on your side.  With most
of my (monospaced) work fonts, that is a clearly inferior choice since
the glyph disrupts the flow of words.

-- 
David Kastrup

Re: [Emacs-diffs] master 9ffb6ce 5/5: Quoting fixes in lisp/international and lisp/leim

[Andreas Schwab]

David Kastrup <dak@gnu.org> writes:

> (by the way: is there any way to make Emacs stop this \u201c pasting
> abomination when using C-y on an X Window selection?).

Worksforme.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: [Emacs-diffs] master 9ffb6ce 5/5: Quoting fixes in lisp/international and lisp/leim

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Date: Thu, 03 Sep 2015 12:48:47 +0200
> Cc: Alan Mackenzie <acm@muc.de>, Dmitry Gutov <dgutov@yandex.ru>,
> 	Oleh Krehel <ohwoeowho@gmail.com>,
> 	Stefan Monnier <monnier@iro.umontreal.ca>, emacs-devel@gnu.org
> 
> (by the way: is there any way to make Emacs stop this \u201c pasting
> abomination when using C-y on an X Window selection?).

Is this in a GUI session?  If so, I think last time this came up,
there was some setting or software outside Emacs that caused that.

Re: [Emacs-diffs] master 9ffb6ce 5/5: Quoting fixes in lisp/international and lisp/leim

[Paul Eggert]

On 09/02/2015 10:23 AM, Alan Mackenzie wrote:
> Checking them with C-u C-x =, they were
> indeed curly quotes, but were displayed the same as ASCII quotes.

After fooling around with it on my Linux console, I came up with a 
scenario that had the behavior you describe.  In this scenario I set the 
LC_ALL environment variable to en_US.UTF-8 even though the Linux console 
could display only a few non-ASCII characters (so in some sense this is 
a misconfiguration).  And I put (setq text-quoting-style 'grave) into my 
~/.emacs file, indicating that I wanted traditional ASCII quoting.  
Emacs didn't look at the text-quoting-style setting when configuring the 
display table at startup, which seems wrong, so I patched master to fix 
that.  Please do a git pull and give it a try.  If it still doesn't work 
for you, please send the output of the shell command ‘locale’ just 
before invoking Emacs, and the output of the command ‘echo $TERM’, and a 
copy of the Lisp code that sets text-quoting-style in your ~/.emacs 
file.  Thanks.

Re: [Emacs-diffs] master 9ffb6ce 5/5: Quoting fixes in lisp/international and lisp/leim

[Alan Mackenzie]

Hello, Paul.

On Wed, Sep 02, 2015 at 03:13:49PM -0700, Paul Eggert wrote:
> On 09/02/2015 10:23 AM, Alan Mackenzie wrote:
> > Checking them with C-u C-x =, they were
> > indeed curly quotes, but were displayed the same as ASCII quotes.

> After fooling around with it on my Linux console, I came up with a 
> scenario that had the behavior you describe.  In this scenario I set the 
> LC_ALL environment variable to en_US.UTF-8 even though the Linux console 
> could display only a few non-ASCII characters (so in some sense this is 
> a misconfiguration).  And I put (setq text-quoting-style 'grave) into my 
> ~/.emacs file, indicating that I wanted traditional ASCII quoting.  
> Emacs didn't look at the text-quoting-style setting when configuring the 
> display table at startup, which seems wrong, so I patched master to fix 
> that.  Please do a git pull and give it a try.  If it still doesn't work 
> for you, please send the output of the shell command ‘locale’ just 
> before invoking Emacs, and the output of the command ‘echo $TERM’, and a 
> copy of the Lisp code that sets text-quoting-style in your ~/.emacs 
> file.  Thanks.

You've cut so much context, left so many dangling prepositions, you've
left me confused as to what we're discussing.  I suspect you've become
confused, too - the original scenario had nothing to do with
`text-quoting-style'.

Maybe later today, I'll try and reassemble the context and answer you.
But it really would be helpful if you would be less obfuscatory.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [Emacs-diffs] master 9ffb6ce 5/5: Quoting fixes in lisp/international and lisp/leim

[Paul Eggert]

Alan Mackenzie wrote:
> the original scenario had nothing to do with
> `text-quoting-style'.

There seemed little point to having two variables to control text quoting 
behavior, one for initial inference of display quoting and one for translation 
of help strings and diagnostics.  So I used the same variable for all three.

> You've cut so much context

To help move things forward, here's a complete copy of the message I replied to, 
along with a copy of my reply inserted at the appropriate spot, so that you can 
see the complete context.

> Alan Mackenzie wrote:
>> Hello, Paul.
>>
>> On Wed, Sep 02, 2015 at 09:32:42AM -0700, Paul Eggert wrote:
>>> Alan Mackenzie wrote:
>>>> Using my  standard font, lat1-16, the curly quotes use the same glyphs as
>>>> ` and ', hence are visibly indistinguishable from them.
>>
>>> That's no longer true as of yesterday's master commit
>>> 1a3518e7c361a9ceaa017c1334a83d14e0651a4e.
>>
>> I'm afraid it is still true.  After doing a C-h f c-mode, apparent
>> quotes were in the buffer.  Checking them with C-u C-x =, they were
>> indeed curly quotes, but were displayed the same as ASCII quotes.

> After fooling around with it on my Linux console, I came up with a scenario that had the behavior you describe.  In this scenario I set the LC_ALL environment variable to en_US.UTF-8 even though the Linux console could display only a few non-ASCII characters (so in some sense this is a misconfiguration).  And I put (setq text-quoting-style 'grave) into my ~/.emacs file, indicating that I wanted traditional ASCII quoting.  Emacs didn't look at the text-quoting-style setting when configuring the display table at startup, which seems wrong, so I patched master to fix that.  Please do a git pull and give it a try.  If it still doesn't work for you, please send the output of the shell command ‘locale’ just before invoking Emacs, and the output of the command ‘echo $TERM’, and a copy of the Lisp code that sets text-quoting-style in your ~/.emacs file.  Thanks.

>>> On a terminal that cannot display curved quotes, ...
>>
>> Currently, my terminal is not such a one.  It _can_ display curly
>> quotes, but only identically to ASCII quotes.  `char-displayable-p'
>> returns 'unicode for them.
>>
>> The issue is not so much whether a terminal can display curly quotes,
>> rather it's whether a user wants them to be used or not.
>>
>>> .... Emacs master now uses different glyphs for the quotes’ ASCII
>>> replacements, because the replacements are shadowed.  The shadowed
>>> glyphs are easily distinguishable on my Linux console.  Users
>>> shouldn’t need to configure Emacs specially, or their Linux console
>>> specially, to get this behavior.  So this objection no longer applies.
>>

Re: [Emacs-diffs] master 9ffb6ce 5/5: Quoting fixes in lisp/international and lisp/leim

[Alan Mackenzie]

Hello, Paul.

On Thu, Sep 03, 2015 at 07:56:05AM -0700, Paul Eggert wrote:
> Alan Mackenzie wrote:
> > the original scenario had nothing to do with
> > `text-quoting-style'.

> There seemed little point to having two variables to control text quoting 
> behavior, one for initial inference of display quoting and one for translation 
> of help strings and diagnostics.  So I used the same variable for all three.

At the initial setup, there aren't yet configuration variables, are
there?  .emacs hasn't yet been read.

> > You've cut so much context

> To help move things forward, here's a complete copy of the message I replied to, 
> along with a copy of my reply inserted at the appropriate spot, so that you can 
> see the complete context.

Thanks for that.  Yesterday wasn't a good day.

> > Alan Mackenzie wrote:

> >> On Wed, Sep 02, 2015 at 09:32:42AM -0700, Paul Eggert wrote:
> >>> Alan Mackenzie wrote:
> >>>> Using my  standard font, lat1-16, the curly quotes use the same glyphs as
> >>>> ` and ', hence are visibly indistinguishable from them.

> >>> That's no longer true as of yesterday's master commit
> >>> 1a3518e7c361a9ceaa017c1334a83d14e0651a4e.

> >> I'm afraid it is still true.  After doing a C-h f c-mode, apparent
> >> quotes were in the buffer.  Checking them with C-u C-x =, they were
> >> indeed curly quotes, but were displayed the same as ASCII quotes.

I've just updated my git-master Emacs again, and the situation still
holds: With emacs -Q, C-h f c-mode displays a buffer containing curly
quotes, these curly quotes being visibly indistinguishable from ASCII
quotes.

In particular, I've not seen any shadowed quotes on my screen no matter
what I've done.

> > After fooling around with it on my Linux console, I came up with a
> > scenario that had the behavior you describe.  In this scenario I set
> > the LC_ALL environment variable to en_US.UTF-8 even though the Linux
> > console could display only a few non-ASCII characters (so in some
> > sense this is a misconfiguration).  And I put (setq
> > text-quoting-style 'grave) into my ~/.emacs file, indicating that I
> > wanted traditional ASCII quoting.

After I execute M-: (setq text-quoting-style 'grave), my next C-h f does
indeed use ASCII quotes.

> > Emacs didn't look at the text-quoting-style setting when configuring
> > the display table at startup, which seems wrong, so I patched master
> > to fix that.  Please do a git pull and give it a try.

Done.  See above.  But isn't startup done before processing .emacs?

> > If it still doesn't work for you, please send the output of the shell
> > command ‘locale’ just before invoking Emacs, and the output of the
> > command ‘echo $TERM’, and a copy of the Lisp code that sets
> > text-quoting-style in your ~/.emacs file.  Thanks.

Just for completeness's sake, I have $TERM=linux, no LC_.. variable is
set, and I don't yet have `text-quoting-style' in my .emacs, but will
probably write (setq text-quoting-style 'grave) into it at some stage.

> >>> On a terminal that cannot display curved quotes, ...

Incidentally, I just tried running Emacs under X Windows, and there I
found the two curly quotes visibly indistinguishable from each other,
except with a lot of effort, and they were both indistinguishable from
the ASCII apostrophe, unless there was one nearby on the screen to
compare with.

> >> Currently, my terminal is not such a one.  It _can_ display curly
> >> quotes, but only identically to ASCII quotes.  `char-displayable-p'
> >> returns 'unicode for them.

`char-displayable-p' isn't very useful here.  It does not check whether a
glyph is assigned to a character code, and I don't even think Linux
offers a suitable interface for this.

> >> The issue is not so much whether a terminal can display curly quotes,
> >> rather it's whether a user wants them to be used or not.

> >>> .... Emacs master now uses different glyphs for the quotes’ ASCII
> >>> replacements, because the replacements are shadowed.  The shadowed
> >>> glyphs are easily distinguishable on my Linux console.  Users
> >>> shouldn’t need to configure Emacs specially, or their Linux console
> >>> specially, to get this behavior.  So this objection no longer applies.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [Emacs-diffs] master 9ffb6ce 5/5: Quoting fixes in lisp/international and lisp/leim

[Stefan Monnier]

> Using my  standard font, lat1-16, the curly quotes use the same glyphs as
> ` and ', hence are visibly indistinguishable from them.

So they're just as pretty.  Looks like a non-issue, then.

> All of what I write above I've written before.  In addition, the
> necessity to type a C-x 8 combination to type a curly quote is a serious
> impediment.

So you don't want to type them.  I don't either, so we're in agreement.

Any other issue?


        Stefan

Re: [Emacs-diffs] master 9ffb6ce 5/5: Quoting fixes in lisp/international and lisp/leim

[Paul Eggert]

On 09/01/2015 08:39 AM, Stefan Monnier wrote:
> - The `...' markup (and it is markup) is ambiguous.
It certainly is (and always has been, alas), but before jumping into 
improving it, could you explain what ambiguities you'd like to resolve 
with an improved markup?

Currently `...' markup in docstrings is used for:

   * Symbols, e.g., `load-file'

   * Info nodes, e.g., `(emacs)Lisp Libraries'.

   * URLs, e.g., `http://bama.ua.edu/cgi-bin/man-cgi?lp'

   * Characters, e.g., `&', ` '.

   * Key sequences, e.g., `C-x ESC O P'.

   * Strings, e.g., `69'.

   * Regular expressions, e.g., `\\(_P\\|_PROTO\\)'.

   * English phrases, e.g., `close in spirit', `things'.

   * Lisp patterns, e.g., `(ATOM . ELLIPSIS)'.

   * Lisp code, e.g., `(thai nil nil (mark))'.

   * Non-Lisp code, e.g., `ls -lR'.

   * Probably some other stuff I’ve missed.

Most of these items are sometimes put in block quotations rather than in 
quote symbols, if they are long enough.

So, when removing ambiguity, how many categories would you like to put 
the above examples in?  And how should the different categories be 
rendered on plain-text consoles and on graphical displays?  I sort of 
have the impression that by “markup” you mean “things that should turn 
into links”, but maybe you mean “things that should be rendered in 
fixed-width font if we have a nice display”, or maybe there are two or 
even more kinds of markup that you have in mind.

Re: [Emacs-diffs] master 9ffb6ce 5/5: Quoting fixes in lisp/international and lisp/leim

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

     > * English phrases, e.g., `close in spirit', `things'.

English quotations should use doublequotes.
We use singlequotes only to present strings of example text
to be processed in a program somehow.  In the case of Emacs,
they are for text that gets manipulated inside Emacs.

     > * Key sequences, e.g., `C-x ESC O P'.

Key sequences (which only go through the keyboard) shouldn't be
quoted with singlequotes, or any kind of quotes.

   * Lisp patterns, e.g., `(ATOM . ELLIPSIS)'.

   * Lisp code, e.g., `(thai nil nil (mark))'.

These two cases (which are really the same case, since you can put a
metasyntactic variable into anything) are not supposed to be quoted
with singlequotes.

The following cases do get quoted with singlequotes:

   * Symbols, e.g., `load-file'

   * Info nodes, e.g., `(emacs)Lisp Libraries'.

   * URLs, e.g., `http://bama.ua.edu/cgi-bin/man-cgi?lp'

   * Characters, e.g., `&', ` '.

   * Strings, e.g., `69'.

   * Regular expressions, e.g., `\\(_P\\|_PROTO\\)'.

   * Non-Lisp code, e.g., `ls -lR'.

It could conceivably be useful to use multiple kinds of quotation to
distinguish among these cases.  But we can't have enough kinds of
quotation marks to give each of these its own kind.  One would
need to use quoting style A for some of then, style B for some others,
style C for some others, etc.

It would take careful thought to figure out how to distribute (say)
three styles of showing quotes among those different uses.

I am not sure it is worth doing anything about.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: [Emacs-diffs] master 9ffb6ce 5/5: Quoting fixes in lisp/international and lisp/leim

[Dmitry Gutov]

On 09/01/2015 06:39 PM, Stefan Monnier wrote:

> So I thought we were going to replace the `...' markup with ‘...’ markup
> (which fixes both points at the same time if we assume that we keep
> sticking to ASCII quotes for the rest, tho at the cost of using
> non-ASCII markup).

That would undermine another stated goal (by Paul): improve the 
typography in Emacs.

> But if we start using curly quotes everywhere, then we're back with the
> ambiguity, so that's not a good solution.

So what's the exact ambiguity that you have in mind? Code references or 
snippets vs. everything else like key sequences?

Then I definitely misunderstood you a while back.

> So maybe a better option is to refine the `...' markup to get rid of
> the ambiguity.  E.g.:
> - `...' is only considered valid markup if ... doesn't contain any
>    whitespace (or some such restriction: it should be a simple rule that
>    still accepts most existing uses, especially those where we want to
>    place a hyperlink).

We might also want to support code snippets like `(progn (foo bar 
foo))'. At least, elisp-completion-at-point relies on snippets being 
quoted that way now. We can detect these using paired parens.

> - All other occurrences of ` and ' are treated a standalone ASCII chars
>    rather than as part of some markup.
>    So `C-x C-f' is not valid markup any more (and won't be prettified).

If you like (though I'd rather keep prettifying them until we introduce 
a better way to emphasize them as key sequences: there's no apparent 
value in not making them pretty).

Re: [Emacs-diffs] master 9ffb6ce 5/5: Quoting fixes in lisp/international and lisp/leim

[Stefan Monnier]

> That would undermine another stated goal (by Paul): improve the typography
> in Emacs.

I think this goal should have very low priority.

>> But if we start using curly quotes everywhere, then we're back with the
>> ambiguity, so that's not a good solution.
> So what's the exact ambiguity that you have in mind? Code references or
> snippets vs. everything else like key sequences?
> Then I definitely misunderstood you a while back.

W.r.t ambiguity, the main problem I see is that we currently can never
be sure that when we see a ` followed by a ' the two actually form a pair.
A human usually can tell, but a program can't get it right 100% of the time.

> We might also want to support code snippets like `(progn (foo bar foo))'. 
> At least, elisp-completion-at-point relies on snippets being quoted
> that way now.  We can detect these using paired parens.

Not sure I want to go down that road.  What about `(foo 'a 'b)' ?
AFAIK it's not very common (yet?) to quote code that way, and I'm not
sure we want to get into the habit of quoting it that way.  I could see
the need/advantage of quoting code reliably, but I don't think `...' is
a good way to do it.


        Stefan

Re: [Emacs-diffs] master 9ffb6ce 5/5: Quoting fixes in lisp/international and lisp/leim

[David Kastrup]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> That would undermine another stated goal (by Paul): improve the typography
>> in Emacs.
>
> I think this goal should have very low priority.
>
>>> But if we start using curly quotes everywhere, then we're back with the
>>> ambiguity, so that's not a good solution.
>> So what's the exact ambiguity that you have in mind? Code references or
>> snippets vs. everything else like key sequences?
>> Then I definitely misunderstood you a while back.
>
> W.r.t ambiguity, the main problem I see is that we currently can never
> be sure that when we see a ` followed by a ' the two actually form a pair.
> A human usually can tell, but a program can't get it right 100% of the time.
>
>> We might also want to support code snippets like `(progn (foo bar foo))'. 
>> At least, elisp-completion-at-point relies on snippets being quoted
>> that way now.  We can detect these using paired parens.
>
> Not sure I want to go down that road.  What about `(foo 'a 'b)' ?

Appears to work fine using paired parens when parsed from the start.

-- 
David Kastrup

Re: [Emacs-diffs] master 9ffb6ce 5/5: Quoting fixes in lisp/international and lisp/leim

[Dmitry Gutov]

On 09/02/2015 05:34 AM, Stefan Monnier wrote:

> W.r.t ambiguity, the main problem I see is that we currently can never
> be sure that when we see a ` followed by a ' the two actually form a pair.
> A human usually can tell, but a program can't get it right 100% of the time.

Okay. But then, there's no problem in using the same quoting for key 
sequences, aside from the quote-matching algorithm.

>> We might also want to support code snippets like `(progn (foo bar foo))'.
>> At least, elisp-completion-at-point relies on snippets being quoted
>> that way now.  We can detect these using paired parens.
>
> Not sure I want to go down that road.  What about `(foo 'a 'b)' ?

That, too. At least if this quote-matching logic is implemented in 
Elisp, forward-sexp can take care of skipping the spaces.

> AFAIK it's not very common (yet?) to quote code that way, and I'm not
> sure we want to get into the habit of quoting it that way.  I could see
> the need/advantage of quoting code reliably, but I don't think `...' is
> a good way to do it.

If we take after Markdown (because why not?), it has two methods of 
quoting code: one for inline code (also used for references), and one 
for code blocks (on separate lines).

It might be a good idea to also have just one quoting method for inline 
code. But if you have a better idea for quoting code, that's fine, too.

Quoting yank/diff prefixes (was: [Emacs-diffs] master 9ffb6ce 5/5: Quoting fixes in lisp/international and lisp/leim)

[David Kastrup]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 09/02/2015 05:34 AM, Stefan Monnier wrote:
>
>> W.r.t ambiguity, the main problem I see is that we currently can never
>> be sure that when we see a ` followed by a ' the two actually form a pair.
>> A human usually can tell, but a program can't get it right 100% of the time.
>
> Okay. But then, there's no problem in using the same quoting for key
> sequences, aside from the quote-matching algorithm.

Moving passages into some sort of string container or else needing some
sort of specific quotation style in order to preserve literal content
seems like a frequent problem.

How about defining some prefix to be used right before C-w or C-y and
related commands that will then strip/interpret the respective suspected
quote sequences going into the kill buffer, and add them when going out?

It would likely need some well-defined mode-specific hooks providing the
string-packing and unpacking, defaulting to something working reasonably
sanely with the union of C and Elisp strings but hopefully taken up by
most mode providers eventually.

Having a standardized mode-specific view into stringizing and
unstringifying passages (prefix arg for specifying the particular quote
style defaulting to " (2) in most modes?  Something like an input method
selector for that?) might be useful for other generic functionality and
keybindings.  But at the very least a standard for "-quoted strings
seems like a good idea.

-- 
David Kastrup

Re: [Emacs-diffs] master 9ffb6ce 5/5: Quoting fixes in lisp/international and lisp/leim

[Stefan Monnier]

>> W.r.t ambiguity, the main problem I see is that we currently can never
>> be sure that when we see a ` followed by a ' the two actually form a pair.
>> A human usually can tell, but a program can't get it right 100% of the time.
> Okay.  But then, there's no problem in using the same quoting for key
> sequences, aside from the quote-matching algorithm.

I'm not fundamentally opposed to it, but I'd like the rule to be *simple*.

If we try and accommodate key sequences, I'm afraid the rule will become
too complex, and we'll bump into corner cases like how to
quote key sequences like C-x ' or M-`.  In most cases, there shouldn't
be key sequences in docstrings anyway since we should use \\[...]
instead, so there's no strong need to accommodate quoting of key sequences.

>> Not sure I want to go down that road.  What about `(foo 'a 'b)' ?
> That, too.  At least if this quote-matching logic is implemented in Elisp,
> forward-sexp can take care of skipping the spaces.

Yes, again it can be made to work.  But what it boils down to is this:
- `...' can't handle all cases without breaking existing uses, so we'll
  need another quoting mechanism anyway.
- in most cases, I don't see a strong need to quote code like (foo a b).
  Maybe at some point we'll start doing things like "prettifying" the
  code in docstrings, at which point we'll need it to be quoted, but
  until that happens, the cost/benefit tradeoff is in favor of keeping
  the code unquoted.
- so I don't see a strong need to accommodate quoting like `(foo a b)'.
  If the simple rule we devise happens to allow it, that's fine,
  of course.


        Stefan

Re: [Emacs-diffs] master 9ffb6ce 5/5: Quoting fixes in lisp/international and lisp/leim

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > And to restate my opinion on the matter, since I haven't participated in
  > this discussion for a few months: Elisp code should be treated as
  > markup.

That's a very clear expression of what I too think.

  > If it were up to me, I'd revert everything until there wasn't a single
  > curly in the code part. Having markup that translates to curlies is
  > absolutely fine with me.

Indeed.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: [Emacs-diffs] master 9ffb6ce 5/5: Quoting fixes in lisp/international and lisp/leim

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > -	   (insert "Don't output anything.\n"))
  > > +	   (insert "Don’t output anything.\n"))

I think that is erroneous because it makes the curly quote unconditional.
That should be conditional.

However, since ccl-dump is meant for debugging, there is no reason to
bother with curly quotes there.




-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: [Emacs-diffs] master 9ffb6ce 5/5: Quoting fixes in lisp/international and lisp/leim

[Paul Eggert]

Richard Stallman wrote:

> That should be conditional.

Yes, this was fixed by making it conditional in master commit 
6514fe88904e658c527deae5be9a3f6ac539653f.