RE: [External] : Re: master ff4de1b: Fix quoting style in Lisp comments

[Drew Adams <drew.adams@oracle.com>]

> > > > it is useful to have distinct characters to
> > > > represent opening and closing quote.
> > > 
> > > The usefulness is that it resolves some ambiguities.
> > > But those can resolved in other ways (e.g. by
> > > disallowing newlines between the opening and closing
> > > quote).
> >
> > Why would we want to impose such a restriction?
> 
> E.g. because multiline constructs are fundamentally
> harder to handle in many cases, such as in font-lock?

Sure, font-locking such things (but not only such
things) isn't 100% perfect.

Having distinct open and close delimiters makes
things easier not only for fontifying but also
for users.

> Or because of things like
>     ;; foo `bar
>     ;; baz' toto

Looks like a pretty concocted example.  Ever seen
that in the wild?

We don't currently font-lock even `...' with space
chars in the ..., in Lisp comments.  (I mentioned
earlier that we could.)

I do that in Info, for example (but emacs -Q
doesn't).

In the Emacs and Elisp manuals there are plenty of
occurrences of '...' where the ... contains space
chars - instances ranging from shell commands, such
as 'cp -r', to key bindings, such as 'a +', to font
names, such as 'song ti', to programming constructs,
such as 'else if', to VC commands, such as
'svn switch', to key sequences, such as 'M-x diary'
and '100 C-f', to key bindings, such as 'C-c C-c',
to patterns, such as 'C-x v r BRANCH-NAME <RET>'
and 'MONTHNAME DAY', to file extensions, such as
'.elc', to menu items, such as 'Other calendars'.

(Those are all from the Emacs manual, and there
are zillions more.)

But sure, it's more problematic to allow for
newline chars.  In my code (`info+.el') that's
optional, and not on by default (except for "...").
But it can by useful, to cover things like these:

'C-x
<RET>' 

'MONTHNAME DAY,
YEAR'

'ls
-l'

'xdvi
OUTPUT-FILE-NAME'

"newline
characters"

All of those occurrences, and many such more,
are in the Emacs manual, and they all fontify
nicely.  (And of course the same was true with
`...', before the change to curly quotes.)

I haven't done the same for `...' in Elisp
comments - only symbol constituents are
fontified there still.  But more could be done.

> where the opener is not in the same comment
> as the closer.

Yes, that would be a minor hiccup.  Fontifying
would need to disregard the comment-starts.
But as I say, that's a pretty uncommon case.

Font-locking need not aim to be perfect, even
in the default case.  But best is to make it
easy for users to switch among different
degrees of font-locking such things.

By default, `info+.el' fontifies all such
quotations.  For all except "..." (strings),
it does so only if the pattern is all on the
same line.  (By default, <...> text is also
fontified.)  Change the value of an option to
get multiline fontifying of all such.

You can also fontify isolated backquote and
quote chars, which is helpful for Lisp code
snippets (including in strings: "the `foo'").

It's easy to change such behavior on the fly.