In docstrings: `sym' and ‘sym’ are equivalent to mismatched `sym’ and ‘sym' (and ‘'sym’, nor `undefined' cannot be used)

In docstrings: `sym' and ‘sym’ are equivalent to mismatched `sym’ and ‘sym' (and ‘'sym’, nor `undefined' cannot be used)

[Garreau, Alexandre]

Take the following piece of code, directly taken from Gnus v5.13:

#+BEGIN_SRC emacs-lisp
(defcustom gnus-build-sparse-threads nil
  "*If non-nil, fill in the gaps in threads.
If `some', only fill in the gaps that are needed to tie loose threads
together.  If `more', fill in all leaf nodes that Gnus can find.  If
non-nil and non-`some', fill in all gaps that Gnus manages to guess."
  :group 'gnus-thread
  :type '(choice (const :tag "off" nil)
		 (const some)
		 (const more)
		 (sexp :menu-tag "all" t)))
#+END_SRC

Passing on the fact the second `more', as it is undefined, oddly acts
differently than the others, which are defined.

The following is equivalent (look at the quotes), and gives in the end
just the same curly quotes and highlighting, while it is mismatched (I
believe it shouldn’t, when mismatched):

#+BEGIN_SRC emacs-lisp
(defcustom gnus-build-sparse-threads nil
  "*If non-nil, fill in the gaps in threads.
If ‘some', only fill in the gaps that are needed to tie loose threads
together.  If `more', fill in all leaf nodes that Gnus can find.  If
non-nil and non-`some’, fill in all gaps that Gnus manages to guess."
  :group 'gnus-thread
  :type '(choice (const :tag "off" nil)
		 (const some)
		 (const more)
		 (sexp :menu-tag "all" t)))
#+END_SRC

I noticed it while trying this:

#+BEGIN_SRC emacs-lisp
(defcustom gnus-build-sparse-threads nil
  "*If non-nil, fill in the gaps in threads.
If “'some”, only fill in the gaps that are needed to tie loose threads
together.  If ‘'more’, fill in all leaf nodes that Gnus can find.  If
non-nil and non-‘some’, fill in all gaps that Gnus manages to guess."
  :group 'gnus-thread
  :type '(choice (const :tag "off" nil)
		 (const some)
		 (const more)
		 (sexp :menu-tag "all" t)))
#+END_SRC

Note how it is impossible to refer to anything quoted without getting
the (wrong) curly quote.  This joins the previous thread about odd
symbols and modifying the reader (should it be also used for quoting?
or should it be accepted to be impossible to correctly write a quote in
docstrings?)

Re: In docstrings: `sym' and ‘sym’ are equivalent to mismatched `sym’ and ‘sym' (and ‘'sym’, nor `undefined' cannot be used)

[Clément Pit-Claudel]

On 2018-10-18 10:07, Garreau, Alexandre wrote:
> (should it be also used for quoting?
> or should it be accepted to be impossible to correctly write a quote in
> docstrings?)

Try \\='

Re: In docstrings: `sym' and ‘sym’ are equivalent to mismatched `sym’ and ‘sym' (and ‘'sym’, nor `undefined' cannot be used)

[Garreau, Alexandre]

Le 18/10/2018 à 10h35, Clément Pit-Claudel a écrit :
> On 2018-10-18 10:07, Garreau, Alexandre wrote:
>> (should it be also used for quoting?
>> or should it be accepted to be impossible to correctly write a quote in
>> docstrings?)
>
> Try \\='

Interesting, thank you, it works for embedding quotes (see thereafter):

#+BEGIN_SRC emacs-lisp
(defcustom gnus-build-sparse-threads nil
  "*If non-nil, fill in the gaps in threads.
If \\='some, only fill in the gaps that are needed to tie loose threads
together.  If \\='more, fill in all leaf nodes that Gnus can find.  If
non-nil and non-\\='some, fill in all gaps that Gnus manages to guess."
  :group 'gnus-thread
  :type '(choice (const :tag "off" nil)
		 (const some)
		 (const more)
		 (sexp :menu-tag "all" t)))
#+END_SRC

(Note emacs-lisp-mode highlights it wrong.)

Yet it doesn’t work with quotes, I guess this is intentional, but even
in cases it is escaped (and thus is part of the symbol name as any
character) it doesn’t work:

#+BEGIN_SRC emacs-lisp
(defcustom gnus-build-sparse-threads nil
  "*If non-nil, fill in the gaps in threads.
If `\\\\='some', only fill in the gaps that are needed to tie loose threads
together.  If `\\\\='more', fill in all leaf nodes that Gnus can find.  If
non-nil and non-`\\\\='some', fill in all gaps that Gnus manages to guess."
  :group 'gnus-thread
  :type '(choice (const :tag "off" nil)
		 (const some)
		 (const more)
		 (sexp :menu-tag "all" t)))
#+END_SRC

Also I just discovered part of my questionnings were because this
docstring doesn’t respect the tip of putting the word “symbol” before
the ref, as says the elisp manual (info "(elisp) Documentation Tips").

It is still disturbing that any mismatcher “`” or “'” is translated, in
docstrings.  I’d understand for “'” maybe, if it was to follow unicode
statement that “’” is better for apostrophe, but sometimes it’s not,
afaik (in french I use it when the apostrophe is part of the word (like
“aujourd'hui”), or in languages where it is a letter, or part of a
letter (like in breton the letter “c'h”: like in “c'hwi”)).  Yet I can’t
understand why doing it for `: though it is true I don’t see any usage
for it in normal natural language text, I’m disturbed by a such
translation happening on mismatched stuff.

Re: In docstrings: `sym' and ‘sym’ are equivalent to mismatched `sym’ and ‘sym' (and ‘'sym’, nor `undefined' cannot be used)

[Paul Eggert]

On 10/18/18 7:07 AM, Garreau, Alexandre wrote:
> I noticed it while trying this:
>
> #+BEGIN_SRC emacs-lisp
> (defcustom gnus-build-sparse-threads nil
>    "*If non-nil, fill in the gaps in threads.
> If “'some”, only fill in the gaps that are needed to tie loose threads
> together.  If ‘'more’, fill in all leaf nodes that Gnus can find.  If
> non-nil and non-‘some’, fill in all gaps that Gnus manages to guess."

As Clément wrote, you could use `\\='more' if you want the curled 
version to look like ‘'more’. However, the curled version shouldn't look 
like that. It should look like ‘more’ without the apostrophe. Doc 
strings should talk about the values in question, not about code that 
would yield those values.

Re: In docstrings: `sym' and ‘sym’ are equivalent to mismatched `sym’ and ‘sym' (and ‘'sym’, nor `undefined' cannot be used)

[Garreau, Alexandre]

On 2018-10-18 at 08:01, Paul Eggert wrote:
> As Clément wrote, you could use `\\='more' if you want the curled
> version to look like ‘'more’. However, the curled version shouldn't
> look like that. It should look like ‘more’ without the apostrophe. Doc
> strings should talk about the values in question, not about code that
> would yield those values.

Yes, as I said, just found out that in the manual: the correct behavior
is prefixing that curly-quoted symbol with the word symbol it seems.