bug#56870: company-dabbrev variable documentation

bug#56870: company-dabbrev variable documentation

[uzibalqa via Bug reports for GNU Emacs, the Swiss army knife of text editors]

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

I am setting company-dabbrev variables

(setq company-dabbrev-other-buffers 'all)
(setq company-dabbrev-ignore-case 'keep-prefix)

The documentation for the variables, says

If ‘all’, search all other buffers, except the ignored ones.

I find the documentation confusing because nowhere does it say that on should use 'all rather than all or "all".

[-- Attachment #2: Type: text/html, Size: 1367 bytes --]

bug#56870: company-dabbrev variable documentation

[Matt Armstrong]

uzibalqa <uzibalqa@proton.me> writes:

> I am setting company-dabbrev variables
>
> (setq company-dabbrev-other-buffers 'all)
> (setq company-dabbrev-ignore-case 'keep-prefix)
>
> The documentation for the variables,  says
>
> If ‘all’, search all other buffers, except the ignored ones.
>
> I find the documentation confusing because nowhere does it say that on
> should use 'all rather than all or "all".

I can understand your confusion.

When working at the level of Emacs Lisp, keep a few things in mind:

a) Generally, in Emacs Lisp help, if you see something like ‘all’ it
means a lisp level symbol.  This could be a function name, variable, or
some other symbol.  This is part of the project's conventions, described
here:
https://www.gnu.org/software/emacs/manual/html_node/elisp/Documentation-Tips.html

b) When lisp level interfaces expect strings they generally say so, and
the examples use quotes like "this".

c) A bare all (without any quotes at all), is just a word, and not
a Lisp level function or variable.

Hope that helps!

bug#56870: company-dabbrev variable documentation

[uzibalqa via Bug reports for GNU Emacs, the Swiss army knife of text editors]

------- Original Message -------
On Monday, August 1st, 2022 at 9:24 PM, Matt Armstrong <matt@rfc20.org> wrote:


> uzibalqa uzibalqa@proton.me writes:
>
> > I am setting company-dabbrev variables
> >
> > (setq company-dabbrev-other-buffers 'all)
> > (setq company-dabbrev-ignore-case 'keep-prefix)
> >
> > The documentation for the variables, says
> >
> > If ‘all’, search all other buffers, except the ignored ones.
> >
> > I find the documentation confusing because nowhere does it say that on
> > should use 'all rather than all or "all".
>
>
> I can understand your confusion.
>
> When working at the level of Emacs Lisp, keep a few things in mind:
>
> a) Generally, in Emacs Lisp help, if you see something like ‘all’ it
> means a lisp level symbol. This could be a function name, variable, or
> some other symbol. This is part of the project's conventions, described
> here:
> https://www.gnu.org/software/emacs/manual/html_node/elisp/Documentation-Tips.html
>
> b) When lisp level interfaces expect strings they generally say so, and
> the examples use quotes like "this".
>
> c) A bare all (without any quotes at all), is just a word, and not
> a Lisp level function or variable.
>
> Hope that helps!

It is a shame that documentation does not come with example.  It is what is much lacking.

bug#56870: company-dabbrev variable documentation

[Matt Armstrong]

uzibalqa <uzibalqa@proton.me> writes:

> On Monday, August 1st, 2022 at 9:24 PM, Matt Armstrong <matt@rfc20.org> wrote:
>> Hope that helps!
>
> It is a shame that documentation does not come with example.  It is
> what is much lacking.

I think the "friendly" way to customize Emacs is intended to be the
customization system:
https://www.gnu.org/software/emacs/manual/html_node/emacs/Easy-Customization.html
In most cases, the customize interface hides lisp level details from the
user.

There is project level goal that most of the useful customizations a
user can do in Emacs should be possible in the customize system, without
using lisp.  This is one reason the help text does not often describe
things with Lisp examples.  They would be of no use to the people using
the Customize interface, and possibly even confusing.

I still think your original point is a good one. I found the one piece
of documentation explaining how to write quoted things in Emacs
documentation, but I could not find a place explaining the conventions
for quoted things mean in Emacs help.  Perhaps another person can find
that, or suggest a way to explain it to new users.

bug#56870: company-dabbrev variable documentation

[uzibalqa via Bug reports for GNU Emacs, the Swiss army knife of text editors]

------- Original Message -------
On Monday, August 1st, 2022 at 9:32 PM, uzibalqa <uzibalqa@proton.me> wrote:


> ------- Original Message -------
> On Monday, August 1st, 2022 at 9:24 PM, Matt Armstrong matt@rfc20.org wrote:
>
>
>
> > uzibalqa uzibalqa@proton.me writes:
> >
> > > I am setting company-dabbrev variables
> > >
> > > (setq company-dabbrev-other-buffers 'all)
> > > (setq company-dabbrev-ignore-case 'keep-prefix)
> > >
> > > The documentation for the variables, says
> > >
> > > If ‘all’, search all other buffers, except the ignored ones.
> > >
> > > I find the documentation confusing because nowhere does it say that on
> > > should use 'all rather than all or "all".
> >
> > I can understand your confusion.
> >
> > When working at the level of Emacs Lisp, keep a few things in mind:
> >
> > a) Generally, in Emacs Lisp help, if you see something like ‘all’ it
> > means a lisp level symbol. This could be a function name, variable, or
> > some other symbol. This is part of the project's conventions, described
> > here:
> > https://www.gnu.org/software/emacs/manual/html_node/elisp/Documentation-Tips.html
> >
> > b) When lisp level interfaces expect strings they generally say so, and
> > the examples use quotes like "this".
> >
> > c) A bare all (without any quotes at all), is just a word, and not
> > a Lisp level function or variable.
> >
> > Hope that helps!
>
>
> It is a shame that documentation does not come with example. It is what is much lacking.

Am also having difficulty showing documentation for company-dabbrev-* and company-dabbrev-code-* using `C-h v'.

bug#56870: company-dabbrev variable documentation

[uzibalqa via Bug reports for GNU Emacs, the Swiss army knife of text editors]

------- Original Message -------
On Monday, August 1st, 2022 at 9:49 PM, Matt Armstrong <matt@rfc20.org> wrote:


> uzibalqa uzibalqa@proton.me writes:
>
> > On Monday, August 1st, 2022 at 9:24 PM, Matt Armstrong matt@rfc20.org wrote:
> >
> > > Hope that helps!
> >
> > It is a shame that documentation does not come with example. It is
> > what is much lacking.
>
>
> I think the "friendly" way to customize Emacs is intended to be the
> customization system:
> https://www.gnu.org/software/emacs/manual/html_node/emacs/Easy-Customization.html
> In most cases, the customize interface hides lisp level details from the
> user.
>
> There is project level goal that most of the useful customizations a
> user can do in Emacs should be possible in the customize system, without
> using lisp. This is one reason the help text does not often describe
> things with Lisp examples. They would be of no use to the people using
> the Customize interface, and possibly even confusing.

There can be a verbosity flag that can be used to show lisp usage following
the description.

> I still think your original point is a good one. I found the one piece
> of documentation explaining how to write quoted things in Emacs
> documentation, but I could not find a place explaining the conventions
> for quoted things mean in Emacs help. Perhaps another person can find
> that, or suggest a way to explain it to new users.

Such conventions should be described in the starting part of the documentation or in appendix.

bug#56870: company-dabbrev variable documentation

[Lars Ingebrigtsen]

Matt Armstrong <matt@rfc20.org> writes:

> b) When lisp level interfaces expect strings they generally say so, and
> the examples use quotes like "this".
>
> c) A bare all (without any quotes at all), is just a word, and not
> a Lisp level function or variable.

So I don't think there's anything to fix in Emacs here -- we sometimes
say "the symbol `all'" if there's an unusual amount of possible
confusion present -- and I'm therefore closing this bug report.

bug#56870: company-dabbrev variable documentation

[uzibalqa via Bug reports for GNU Emacs, the Swiss army knife of text editors]

------- Original Message -------
On Tuesday, August 2nd, 2022 at 10:20 AM, Lars Ingebrigtsen <larsi@gnus.org> wrote:


> Matt Armstrong matt@rfc20.org writes:
>
> > b) When lisp level interfaces expect strings they generally say so, and
> > the examples use quotes like "this".
> >
> > c) A bare all (without any quotes at all), is just a word, and not
> > a Lisp level function or variable.
>
>
> So I don't think there's anything to fix in Emacs here -- we sometimes
> say "the symbol `all'" if there's an unusual amount of possible
> confusion present -- and I'm therefore closing this bug report.

I still think you should be explicit as with "this", and present users with what they will actually use, 'this.

It is not good to expect a users to spend hours reading in the hope that he will eventually figure out that what is written in the documentation is not what you write in your code.  And then figure out how to solve it.

bug#56870: company-dabbrev variable documentation

[YE via Bug reports for GNU Emacs, the Swiss army knife of text editors]

> So I don't think there's anything to fix in Emacs here -- we sometimes
> say "the symbol `all'" if there's an unusual amount of possible
> confusion present -- and I'm therefore closing this bug report.

I'd still suggest considering documentation improvement in this regard.
Probably because I had the same confusion when started with Emacs, even
after having read the whole manual.

[Well, the info node `(elisp) Documentation Tips)' clarifies how to
document symbols :
>  When a documentation string refers to a Lisp symbol, write it as it
>      would be printed (which usually means in lower case), surrounding
>      it with curved single quotes (‘..’)
But Emacs beginner users don't seem to be the target auditory of this
page. And it still won't -- naturally -- explain how to _use_ such
symbols.]

One such possible place to adjust is the info node `(emacs) Examining'.
Maybe replace 'fill-column' example with the one that accepts a
documented symbol (f.i. 'default-justification', 'diff-refine',
'tab-always-complete') and use the symbol in the code below?

Another: info node `(emacs) Init Syntax' could probably state more
explicitly how to deal with the symbols.

Or mention symbols documentation/usage at the end of the info node
`(emacs) Variables', after the line "check the variable’s documentation
string to see what kind of value it expects".

WDYT?

bug#56870: company-dabbrev variable documentation

[Matt Armstrong]

YE <yet@ego.team> writes:

>> So I don't think there's anything to fix in Emacs here -- we sometimes
>> say "the symbol `all'" if there's an unusual amount of possible
>> confusion present -- and I'm therefore closing this bug report.
>
> I'd still suggest considering documentation improvement in this regard.
> Probably because I had the same confusion when started with Emacs, even
> after having read the whole manual.
>
> [Well, the info node `(elisp) Documentation Tips)' clarifies how to
> document symbols :
>>  When a documentation string refers to a Lisp symbol, write it as it
>>      would be printed (which usually means in lower case), surrounding
>>      it with curved single quotes (‘..’)
> But Emacs beginner users don't seem to be the target auditory of this
> page. And it still won't -- naturally -- explain how to _use_ such
> symbols.]
>
> One such possible place to adjust is the info node `(emacs) Examining'.
> Maybe replace 'fill-column' example with the one that accepts a
> documented symbol (f.i. 'default-justification', 'diff-refine',
> 'tab-always-complete') and use the symbol in the code below?
>
> Another: info node `(emacs) Init Syntax' could probably state more
> explicitly how to deal with the symbols.
>
> Or mention symbols documentation/usage at the end of the info node
> `(emacs) Variables', after the line "check the variable’s documentation
> string to see what kind of value it expects".
>
> WDYT?

People learn in different ways, so perhaps we should do all of those
things?

I think improving the various manuals is always a good idea.  The hard
part is finding and encouraging people to contribute the work!  :-)  I
think the maintainers are quite receptive to improvements like this.

Another thing to keep in mind: most of the common languages these days
do not have symbols, so the very concept might be unfamiliar to new
users.

Another place that might improve is "An Introduction to Programming in
Emacs Lisp"
(https://www.gnu.org/software/emacs/manual/html_mono/eintr.html).  In my
opinion, it could do a better job explaining what a symbol is, how to
express them in code, quote them, how they are often used as "magic
values", etc.  It talks about them in context with "atoms" but that is
fairly esoteric.

FWIW I find that the classic book "A Gentle Introduction to Symbolic
Computaton" does a great job explaining what a symbol is.  It introduces
the idea of a symbol as the second fundamental concept of the language,
in the first chapter, right after functions.

https://www.cs.cmu.edu/~dst/LispBook/book.pdf

Turning back to Emacs' help system, I wonder if it could be made more
clear that all of these quoted "things" in help text are intended to be
lisp symbols.  Wild idea: always turn them into links.  An arbitrary
`foo' that isn't a function or variable would link to a synthetic help
page explaining that it is a symbol, how it might appear in lisp code,
link to an appropriate manual, etc.  Perhaps this would be too noisy...

bug#56870: company-dabbrev variable documentation

[carlmarcos--- via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Aug 3, 2022, 18:41 by matt@rfc20.org:

> YE <yet@ego.team> writes:
>
>>> So I don't think there's anything to fix in Emacs here -- we sometimes
>>> say "the symbol `all'" if there's an unusual amount of possible
>>> confusion present -- and I'm therefore closing this bug report.
>>>
>>
>> I'd still suggest considering documentation improvement in this regard.
>> Probably because I had the same confusion when started with Emacs, even
>> after having read the whole manual.
>>
>> [Well, the info node `(elisp) Documentation Tips)' clarifies how to
>> document symbols :
>>
>>> When a documentation string refers to a Lisp symbol, write it as it
>>>  would be printed (which usually means in lower case), surrounding
>>>  it with curved single quotes (‘..’)
>>>
>> But Emacs beginner users don't seem to be the target auditory of this
>> page. And it still won't -- naturally -- explain how to _use_ such
>> symbols.]
>>
>> One such possible place to adjust is the info node `(emacs) Examining'.
>> Maybe replace 'fill-column' example with the one that accepts a
>> documented symbol (f.i. 'default-justification', 'diff-refine',
>> 'tab-always-complete') and use the symbol in the code below?
>>
>> Another: info node `(emacs) Init Syntax' could probably state more
>> explicitly how to deal with the symbols.
>>
>> Or mention symbols documentation/usage at the end of the info node
>> `(emacs) Variables', after the line "check the variable’s documentation
>> string to see what kind of value it expects".
>>
>> WDYT?
>>
>
> People learn in different ways, so perhaps we should do all of those
> things?
>
> I think improving the various manuals is always a good idea.  The hard
> part is finding and encouraging people to contribute the work!  :-)  I
> think the maintainers are quite receptive to improvements like this.
>

I completely disagree.  The experience with maintainers has shown how unreceptive
they often get towards improvements like this.  Lars thought there isn't anything to fix
in Emacs and decided to close this bug report.



> Another thing to keep in mind: most of the common languages these days
> do not have symbols, so the very concept might be unfamiliar to new
> users.
>
> Another place that might improve is "An Introduction to Programming in
> Emacs Lisp"
> (https://www.gnu.org/software/emacs/manual/html_mono/eintr.html).  In my
> opinion, it could do a better job explaining what a symbol is, how to
> express them in code, quote them, how they are often used as "magic
> values", etc.  It talks about them in context with "atoms" but that is
> fairly esoteric.
>
> FWIW I find that the classic book "A Gentle Introduction to Symbolic
> Computaton" does a great job explaining what a symbol is.  It introduces
> the idea of a symbol as the second fundamental concept of the language,
> in the first chapter, right after functions.
>
> https://www.cs.cmu.edu/~dst/LispBook/book.pdf
>
> Turning back to Emacs' help system, I wonder if it could be made more
> clear that all of these quoted "things" in help text are intended to be
> lisp symbols.  Wild idea: always turn them into links.  An arbitrary
> `foo' that isn't a function or variable would link to a synthetic help
> page explaining that it is a symbol, how it might appear in lisp code,
> link to an appropriate manual, etc.  Perhaps this would be too noisy...
>

bug#56870: [PATCH] Re: bug#56870: company-dabbrev variable documentation

[YE via Bug reports for GNU Emacs, the Swiss army knife of text editors]

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

My take on the 'Init File' docs improvement is attached.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Expand Init File docs --]
[-- Type: text/x-patch, Size: 2192 bytes --]

From d83fd0b706e60e321be695ab7d00ef7d1746258d Mon Sep 17 00:00:00 2001
From: YugaEgo <yet@ego.team>
Date: Thu, 4 Aug 2022 18:45:49 +0300
Subject: [PATCH] Expand Init File documentation in Emacs manual

* doc/emacs/custom.texi (Init Syntax):
Add 'Other Lisp symbols' item.  Expand 'True' and 'False' items docs.
Add indexes.
(Init Examples): Mention doc strings convention for symbols.  (Bug#56870)
---
 doc/emacs/custom.texi | 26 +++++++++++++++++++++++---
 1 file changed, 23 insertions(+), 3 deletions(-)

diff --git a/doc/emacs/custom.texi b/doc/emacs/custom.texi
index 6ed43bcb79..e9b65b66ce 100644
--- a/doc/emacs/custom.texi
+++ b/doc/emacs/custom.texi
@@ -2442,13 +2442,31 @@ Init Syntax
 keys which send non-@acronym{ASCII} characters.
 
 @item True:
-@code{t} stands for ``true''.
+@cindex @code{t}
+@cindex true
+@cindex boolean
+The special symbol @code{t} stands for ``true''.  @xref{Constant
+Variables,,, elisp, The Emacs Lisp Reference Manual}.
 
 @item False:
-@code{nil} stands for ``false''.
+@cindex @code{nil}
+@cindex false
+@cindex boolean
+The special symbol @code{nil} stands for ``false''.  @xref{Constant
+Variables,,, elisp, The Emacs Lisp Reference Manual}).
+
+@item Other Lisp symbols:
+@cindex Lisp symbol syntax
+@cindex symbol syntax
+Write a single-quote (@code{'}) followed by the symbol name
+(@pxref{Symbols,,, elisp, The Emacs Lisp Reference Manual}).  Note
+that documentation strings refer to symbols by their names only,
+without the single-quote (@pxref{Documentation Tips,,, elisp, The
+Emacs Lisp Reference Manual}).
 
 @item Other Lisp objects:
 @cindex Lisp object syntax
+@cindex object syntax
 Write a single-quote (@code{'}) followed by the Lisp object you want.
 @end table
 
@@ -2515,7 +2533,9 @@ Init Examples
 Note that @code{text-mode} is used because it is the command for
 entering Text mode.  The single-quote before it makes the symbol a
 constant; otherwise, @code{text-mode} would be treated as a variable
-name.
+name.  By convention, documentation strings refer to symbol arguments
+by their names, without the single-quote (@pxref{Documentation Tips,,,
+elisp, The Emacs Lisp Reference Manual}).
 
 @need 1500
 @item
-- 
2.34.1

bug#56870: [PATCH] Re: bug#56870: company-dabbrev variable documentation

[Eli Zaretskii]

> Cc: yet@ego.team, uzibalqa@proton.me, larsi@gnus.org, 56870@debbugs.gnu.org
> Date: Thu, 04 Aug 2022 19:06:36 +0300
> From:  YE via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> 
> My take on the 'Init File' docs improvement is attached.

Thanks.  However, this basically adds to the Emacs manual stuff whose
place is in the ELisp manual.  So I'm not sure we should start on this
slippery slope.  Users who need to write complex Lisp in their init
files need to read the ELisp manual anyway.

bug#56870: company-dabbrev variable documentation

[Matt Armstrong]

carlmarcos@tutanota.com writes:

> Aug 3, 2022, 18:41 by matt@rfc20.org:
>
>> I think the maintainers are quite receptive to improvements like
>> this.
>
> I completely disagree.  The experience with maintainers has shown how
> unreceptive they often get towards improvements like this.  Lars
> thought there isn't anything to fix in Emacs and decided to close this
> bug report.

I think reasonable people can disagree about what is and is not a
problem, is or is not an improvement, or even misunderstand eachother
entirely.  Sometimes patience and additional explanations are the way to
move forward.

In this case, I agree with Lars that the company-dabbrev docstring is
consistent with Emacs' usual way of writing docstrings.  I don't
actually see a clear way to improve the one docstring in isolation
without it becoming inconsistent with the rest of Emacs.  And so, I
would expect any improvement here to involve some discussion, since the
path forward isn't obvious.

bug#56870: [PATCH] Re: bug#56870: company-dabbrev variable documentation

[Matt Armstrong]

Eli Zaretskii <eliz@gnu.org> writes:

>> Cc: yet@ego.team, uzibalqa@proton.me, larsi@gnus.org, 56870@debbugs.gnu.org
>> Date: Thu, 04 Aug 2022 19:06:36 +0300
>> From:  YE via "Bug reports for GNU Emacs,
>>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
>> 
>> My take on the 'Init File' docs improvement is attached.
>
> Thanks.  However, this basically adds to the Emacs manual stuff whose
> place is in the ELisp manual.  So I'm not sure we should start on this
> slippery slope.  Users who need to write complex Lisp in their init
> files need to read the ELisp manual anyway.

Eli, perhaps a single link to the ELisp manual near the beginning of
"(emacs) Init Syntax" would be acceptable?  The section is describing a
small subset of lisp, so I think such a link would be useful there.
(Way back when I was first learning Emacs it took me quite a while
before I realized that the ELisp manual existed at all.)

I tend to agree with you that "(emacs) Init Syntax" isn't a great place
to describe how various lisp constructs appear in help text, since it
its focus is how to write lisp code.  I would think that belongs
somewhere under "(emacs) Help".

bug#56870: [PATCH] Re: bug#56870: company-dabbrev variable documentation

[Eli Zaretskii]

> From: Matt Armstrong <matt@rfc20.org>
> Cc: yet@ego.team, uzibalqa@proton.me, larsi@gnus.org, 56870@debbugs.gnu.org
> Date: Thu, 04 Aug 2022 10:48:47 -0700
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Cc: yet@ego.team, uzibalqa@proton.me, larsi@gnus.org, 56870@debbugs.gnu.org
> >> Date: Thu, 04 Aug 2022 19:06:36 +0300
> >> From:  YE via "Bug reports for GNU Emacs,
> >>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> >> 
> >> My take on the 'Init File' docs improvement is attached.
> >
> > Thanks.  However, this basically adds to the Emacs manual stuff whose
> > place is in the ELisp manual.  So I'm not sure we should start on this
> > slippery slope.  Users who need to write complex Lisp in their init
> > files need to read the ELisp manual anyway.
> 
> Eli, perhaps a single link to the ELisp manual near the beginning of
> "(emacs) Init Syntax" would be acceptable?

Yes, that's a better idea.

bug#56870: company-dabbrev variable documentation

[carlmarcos--- via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Aug 4, 2022, 17:09 by matt@rfc20.org:

> carlmarcos@tutanota.com writes:
>
>> Aug 3, 2022, 18:41 by matt@rfc20.org:
>>
>>> I think the maintainers are quite receptive to improvements like
>>> this.
>>>
>>
>> I completely disagree.  The experience with maintainers has shown how
>> unreceptive they often get towards improvements like this.  Lars
>> thought there isn't anything to fix in Emacs and decided to close this
>> bug report.
>>
>
> I think reasonable people can disagree about what is and is not a
> problem, is or is not an improvement, or even misunderstand eachother
> entirely.  Sometimes patience and additional explanations are the way to
> move forward.
>
> In this case, I agree with Lars that the company-dabbrev docstring is
> consistent with Emacs' usual way of writing docstrings.  I don't
> actually see a clear way to improve the one docstring in isolation
> without it becoming inconsistent with the rest of Emacs.  And so, I
> would expect any improvement here to involve some discussion, since the
> path forward isn't obvious.
>
Sure.  But I found too much eagerness to close the discussion.  Many are putting too much focus
on consistency, when the aim should really be on equipping users with what is actually required  
for them to write code that works.  Rather than rely on assumptions that old timers consider of minor
importance.  Because in the end it is code that works which counts.  The less one tortures people, the better.

bug#56870: [PATCH] Re: bug#56870: company-dabbrev variable documentation

[YE via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

>> My take on the 'Init File' docs improvement is attached.
>
> Thanks.  However, this basically adds to the Emacs manual stuff whose
> place is in the ELisp manual.

This patch clarifies _existing_ node of the Emacs manual:
1. Adds indexes.
2. Adds links to the ELisp manual for further reading.
3. Clarifies how to use _wide-spread_ symbols (extensively used by newbies).

Which part _exactly_ you don't find suitable for the Emacs manual?

Don't Symbols deserve the same attention as Numbers, Strings,
Characters described extensively in `(emacs) Init Syntax'?

Maybe, according to your point of view, this node should be removed from
the Emacs manual altogether, (linking to the ELisp manual)?

In my fresh memory, this part of the manual was one of the least helpful
and the most confusing. So my (vanishing) hope was to contribute a
little bit of improvement to it to help fellow beginner users, when one
of the issues with it was articulated.

Or should I submit a new bug report with the vague: `(emacs) Init File'
is confusing and isn't instructive enough for the newbies?

Many (if not most) of the beginners start tweaking Emacs via the init
file, not Customize interface. So well-written beginner instructions on
how to use init file is a _need_, not a whim.

> So I'm not sure we should start on this
> slippery slope.

We start on the slippery slope when the reported issues aren't resolved.

> Users who need to write complex Lisp in their init
> files need to read the ELisp manual anyway.

What part of the patch touches the "complex Lisp"?

bug#56870: [PATCH] Re: bug#56870: company-dabbrev variable documentation

[Eli Zaretskii]

> From: YE <yet@ego.team>
> Cc: yet@ego.team, matt@rfc20.org, uzibalqa@proton.me, larsi@gnus.org,
> 	56870@debbugs.gnu.org
> Date: Fri, 05 Aug 2022 12:10:33 +0300
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Thanks.  However, this basically adds to the Emacs manual stuff whose
> > place is in the ELisp manual.
> 
> This patch clarifies _existing_ node of the Emacs manual:
> 1. Adds indexes.
> 2. Adds links to the ELisp manual for further reading.
> 3. Clarifies how to use _wide-spread_ symbols (extensively used by newbies).
> 
> Which part _exactly_ you don't find suitable for the Emacs manual?

All of it.  You explain some basics of Emacs Lisp, which any user who
is serious about customizing his/her Emacs should already know about,
by reading the relevant parts of the ELisp manual.

It goes without saying that this node of the Emacs manual is
intentionally incomplete, but making it complete would mean we'd need
to repeat a significant portion of text that is already in the ELisp
manual, because the missing bits are about Emacs Lisp, not about
anything special to the init files.

> Don't Symbols deserve the same attention as Numbers, Strings,
> Characters described extensively in `(emacs) Init Syntax'?

No, I don't think so.  And this is a slippery slope anyway, because
there's more about Lisp objects than just telling what you suggest to
tell.

> Maybe, according to your point of view, this node should be removed from
> the Emacs manual altogether, (linking to the ELisp manual)?

That'd be too drastic, IMO.  Simple customizations don't need detailed
knowledge of Lisp, and the node attempts to strike a balance between
being useful to beginners and including too much of ELisp.

> Or should I submit a new bug report with the vague: `(emacs) Init File'
> is confusing and isn't instructive enough for the newbies?

If you explain clearly enough what is confusing in that node, we could
try making it less confusing and more instructive, yes.

> > So I'm not sure we should start on this
> > slippery slope.
> 
> We start on the slippery slope when the reported issues aren't resolved.

That's a different slippery slope.

And I disagree that issues aren't resolved.  You might think they
aren't, because your opinions aren't accepted, but we don't promise we
will accept any opinion without considering its advantages and
disadvantages.

> > Users who need to write complex Lisp in their init
> > files need to read the ELisp manual anyway.
> 
> What part of the patch touches the "complex Lisp"?

This one, for example:

  +@item Other Lisp symbols:
  +@cindex Lisp symbol syntax
  +@cindex symbol syntax
  +Write a single-quote (@code{'}) followed by the symbol name
  +(@pxref{Symbols,,, elisp, The Emacs Lisp Reference Manual}).  Note
  +that documentation strings refer to symbols by their names only,
  +without the single-quote (@pxref{Documentation Tips,,, elisp, The
  +Emacs Lisp Reference Manual}).

Why does this text have to talk about doc strings, and what does it
have to do with the syntax of the init file?  And the node to which
you refer is a large and complex node, which is too much for simple
customizations that Init Syntax intends to cover.

bug#56870: [PATCH] Re: bug#56870: company-dabbrev variable documentation

[carlmarcos--- via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Aug 5, 2022, 11:09 by eliz@gnu.org:

>> From: YE <yet@ego.team>
>> Cc: yet@ego.team, matt@rfc20.org, uzibalqa@proton.me, larsi@gnus.org,
>>  56870@debbugs.gnu.org
>> Date: Fri, 05 Aug 2022 12:10:33 +0300
>>
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>> > Thanks.  However, this basically adds to the Emacs manual stuff whose
>> > place is in the ELisp manual.
>>
>> This patch clarifies _existing_ node of the Emacs manual:
>> 1. Adds indexes.
>> 2. Adds links to the ELisp manual for further reading.
>> 3. Clarifies how to use _wide-spread_ symbols (extensively used by newbies).
>>
>> Which part _exactly_ you don't find suitable for the Emacs manual?
>>
>
> All of it.  You explain some basics of Emacs Lisp, which any user who
> is serious about customizing his/her Emacs should already know about,
> by reading the relevant parts of the ELisp manual.
>
> It goes without saying that this node of the Emacs manual is
> intentionally incomplete, but making it complete would mean we'd need
> to repeat a significant portion of text that is already in the ELisp
> manual, because the missing bits are about Emacs Lisp, not about
> anything special to the init files.
>
>> Don't Symbols deserve the same attention as Numbers, Strings,
>> Characters described extensively in `(emacs) Init Syntax'?
>>
>
> No, I don't think so.  And this is a slippery slope anyway, because
> there's more about Lisp objects than just telling what you suggest to
> tell.
>
The docstring should mention that variable settings use symbol arguments.  


>> Maybe, according to your point of view, this node should be removed from
>> the Emacs manual altogether, (linking to the ELisp manual)?
>>
>
> That'd be too drastic, IMO.  Simple customizations don't need detailed
> knowledge of Lisp, and the node attempts to strike a balance between
> being useful to beginners and including too much of ELisp.
>
>> Or should I submit a new bug report with the vague: `(emacs) Init File'
>> is confusing and isn't instructive enough for the newbies?
>>
>
> If you explain clearly enough what is confusing in that node, we could
> try making it less confusing and more instructive, yes.
>
>> > So I'm not sure we should start on this
>> > slippery slope.
>>
>> We start on the slippery slope when the reported issues aren't resolved.
>>
>
> That's a different slippery slope.
>
> And I disagree that issues aren't resolved.  You might think they
> aren't, because your opinions aren't accepted, but we don't promise we
> will accept any opinion without considering its advantages and
> disadvantages.
>
>> > Users who need to write complex Lisp in their init
>> > files need to read the ELisp manual anyway.
>>
>> What part of the patch touches the "complex Lisp"?
>>
>
> This one, for example:
>
>  +@item Other Lisp symbols:
>  +@cindex Lisp symbol syntax
>  +@cindex symbol syntax
>  +Write a single-quote (@code{'}) followed by the symbol name
>  +(@pxref{Symbols,,, elisp, The Emacs Lisp Reference Manual}).  Note
>  +that documentation strings refer to symbols by their names only,
>  +without the single-quote (@pxref{Documentation Tips,,, elisp, The
>  +Emacs Lisp Reference Manual}).
>
> Why does this text have to talk about doc strings, and what does it
> have to do with the syntax of the init file?  And the node to which
> you refer is a large and complex node, which is too much for simple
> customizations that Init Syntax intends to cover.
>

bug#56870: [PATCH] Re: bug#56870: company-dabbrev variable documentation

[YE via Bug reports for GNU Emacs, the Swiss army knife of text editors]

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

>> Eli Zaretskii:

>> From: YE
>> Which part _exactly_ you don't find suitable for the Emacs manual?
>
> All of it.  You explain some basics of Emacs Lisp, which any user who
> is serious about customizing his/her Emacs should already know about,
> by reading the relevant parts of the ELisp manual.

>> Don't Symbols deserve the same attention as Numbers, Strings,
>> Characters described extensively in `(emacs) Init Syntax'?
>
> No, I don't think so.  And this is a slippery slope anyway, because
> there's more about Lisp objects than just telling what you suggest to
> tell.

>> What part of the patch touches the "complex Lisp"?
>
> Why does this text have to talk about doc strings, and what does it
> have to do with the syntax of the init file?  And the node to which
> you refer is a large and complex node, which is too much for simple
> customizations that Init Syntax intends to cover.
>

Thank you for the detailed response.

>> From: Matt Armstrong
>> Eli, perhaps a single link to the ELisp manual near the beginning of
>> "(emacs) Init Syntax" would be acceptable?
>
> Yes, that's a better idea.

One more tiny patch is attached.
It links 'Init Syntax' to the ELisp manual Introduction node.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Link from Init Syntax to ELisp Introduction --]
[-- Type: text/x-patch, Size: 806 bytes --]

From 68a2732383e48096296da208215590c5afc62971 Mon Sep 17 00:00:00 2001
From: YugaEgo <yet@ego.team>
Date: Sat, 6 Aug 2022 15:20:09 +0300
Subject: [PATCH] Link from (emacs)Init Syntax to (elisp)Introduction

* doc/emacs/custom.texi (Init Syntax): Link to the ELisp manual (Bug#56870)
---
 doc/emacs/custom.texi | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/doc/emacs/custom.texi b/doc/emacs/custom.texi
index 6ed43bcb79..efaf0dfd38 100644
--- a/doc/emacs/custom.texi
+++ b/doc/emacs/custom.texi
@@ -2452,6 +2452,9 @@ Init Syntax
 Write a single-quote (@code{'}) followed by the Lisp object you want.
 @end table
 
+  For more information on the Emacs Lisp syntax, @pxref{Introduction,,,
+elisp, The Emacs Lisp Reference Manual}.
+
 @node Init Examples
 @subsection Init File Examples
 
-- 
2.34.1

bug#56870: [PATCH] Re: bug#56870: company-dabbrev variable documentation

[Eli Zaretskii]

> From: YE <yet@ego.team>
> Cc: yet@ego.team, matt@rfc20.org, uzibalqa@proton.me, larsi@gnus.org,
>  56870@debbugs.gnu.org
> Date: Sat, 06 Aug 2022 15:42:15 +0300
> 
> Thank you for the detailed response.
> 
> >> From: Matt Armstrong
> >> Eli, perhaps a single link to the ELisp manual near the beginning of
> >> "(emacs) Init Syntax" would be acceptable?
> >
> > Yes, that's a better idea.
> 
> One more tiny patch is attached.
> It links 'Init Syntax' to the ELisp manual Introduction node.

Thanks, installed on the release branch, and closing the bug.