bug#36828: 27.0.50; Uninstalled emacs shows installed documentation

[Štěpán Němec]

On Mon, 29 Jul 2019 19:57:55 +0300
Eli Zaretskii wrote:

> Once again, we are talking about the situation where there's both an
> installed NEWS file and an uninstalled one for the same Emacs
> version.  The situation where there's just one of them works exactly
> as you want.  Right?

Yes. [Although I wouldn't use the formulation "the same Emacs version"
myself, or at least would need to clarify its definition, i.e. typically
the source tree build would be newer than the installed version, but
would end up in the same installation directory, yes, so that's probably
not relevant here.]

>> Whether some version is more up-to-date or useful (whatever that means)
>> is besides the point. What I meant by "most relevant for the running
>> executable" and "obvious" above was simply what seems to me a case of
>> the principle of least surprise: if I run /usr/bin/emacs, I expect it to
>> use the same PREFIX for other things, i.e. /usr/share/emacs.... If I run
>> /usr/local/bin/emacs, I expect it to use /usr/local/share/emacs.... And
>> if I run src/emacs, I expect it to use the source tree.
>
> But that's not how Emacs works.  Emacs looks for its data-directory
> where it was configured to look for it.  At configure time, you can
> specify that place via the --datadir=DIR option.  The result (or the
> default, if you didn't specify --datadir=DIR) is recorded in
> src/epaths.h, and that's where Emacs will look for the data files.
>
> IOW, you are describing an Emacs that is very different from how the
> real Emacs works, has been working for decades.  Emacs does NOT
> determine all of the different directories relative to the directory
> where its binary executable lives.  It does it according to how it was
> configured.

I think you are mixing up two things. One way to put it would be the
(veteran) developer view vs. the user view. You keep saying things like
"that's not how Emacs works" (well, that much we can all agree upon at
least) or "I'm not sure we should rock that particular boat for an
unusual use case such as yours." and I can appreciate that.

But Óscar wrote:

  And is there a good reason for doing that? When Emacs is executed from
  the build directory, I expect that it works on the contents of that
  directory (and the correspondent source directory, for out-of-tree
  builds.)

And I described the same expectation in slightly greater detail and
asked you

  Does that really seem less reasonable than your "TRT"?

And also asked you to explain your "right thing" and why you think it is
right.

And I still haven't got your answer to that, only more description of
the status quo (which is helpful, too, though, and thank you for that).

I can live with "this is how it works, the code is hairy, let's just
keep this as a wishlist item" or something to that effect, but you
somehow seem to insist on the current behaviour not being wrong at all
or at least seem to have some kind of "the right thing" notion
apparently quite different from the expectation of myself, the OP and I
suspect most users, and at the same time you fail to explain what that
TRT is and why it is right or more right than our expectation.

Failing all that, if there is no prospect of change at all, would it be
possible to at least warn the user in cases like this? Something like
"The NEWS file you are accessing is not the one you probably think it
is"?