Re: Not using DOC for ELisp files

[Stefan Monnier]

>> Seeing how I haven't heard any opposition to the idea, I fixed a few
>> loose ends, and I think it's now ready.  See below.
>> Any objection?
> This seems to do much more than just what you said, even if I include
> the obvious cleanups, like unnecessary variables and support code no
> longer required.  Are all the changes really necessary/derived, or did
> you take the chance to make some additional changes, which should
> perhaps be discussed separately?

I don't think this includes any unrelated change.  I know I have
a tendency to do that even without noticing it, but I tried to be
careful this time.

Some of the needed changes could be done differently (mostly the
changes that revolve around the use of relative file names), I guess,
but it's all either needed or subsequent obvious cleanup.

>>    When Emacs starts up, it sets up the value of @code{load-path}
>> -in several steps.  First, it initializes @code{load-path} using
>> -default locations set when Emacs was compiled.  Normally, this
>> -is a directory something like
>> +in several steps.  First, it initializes @code{lisp-directory} using
>> +default locations set when Emacs was compiled.
> You used for lisp-directory the same words as we used for load-path,
> but is that the correct description?

Good question.  I think it should (as in, any difference is likely
a sign of a bug), tho I haven't looked closely at the code to see if the
code matches this expectation.

> Looking at the code that computes the value of lisp-directory, I don't
> think so, I think you can say something much more accurate and
> explicit about lisp-directory.

Don't know what that would look like.

> Moreover, the text about load-path is now completely gone, and that is
> a net loss, I think.

I don't see it being gone.  But yes, I'm not super happy with the text
I have.  I already rewrote it three times before the version you saw.
I'd appreciate some help with it.

>> +@defvar lisp-directory
>> +Name of the directory holding Emacs's bundled Lisp files.
> This is not accurate enough, given that it could mean both the place
> where Emacs was built (the "bundled" part can be interpreted that
> way), the place where *.el and *.elc files are installed when the
> built Emacs is being installed, and the place where the *.eln files
> are installed.

Hmm.. not sure how to avoid those problems: mentioning what it is not
would seem to muddy the waters even further.

>> +Normally, this is a directory something like
>>  @example
>>  "/usr/local/share/emacs/@var{version}/lisp"
>>  @end example
> This should tell what does @var{version} stand for.

(apparently like the author of that chunk) I don't see why that
would be necessary.

> Likewise.  Actually, "files that come with GNU Emacs" is even worse in
> its ambiguity than "bundled".

Any suggestion for a better wording?

> And why isn't the main part of the change called out in NEWS?
> I think this is something we should announce.

AFAIK it's invisible to the end user, so I think it isn't worth
mentioning there.


        Stefan