From: "Štěpán Němec" <stepnem@gmail.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 36828@debbugs.gnu.org, ofv@wanadoo.es
Subject: bug#36828: 27.0.50; Uninstalled emacs shows installed documentation
Date: Mon, 29 Jul 2019 19:44:25 +0200 [thread overview]
Message-ID: <87wog0pwg6.fsf@gmail.com> (raw)
In-Reply-To: <83k1c0kcbw.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 29 Jul 2019 19:57:55 +0300")
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"?
next prev parent reply other threads:[~2019-07-29 17:44 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-28 15:07 bug#36828: 27.0.50; Uninstalled emacs shows installed documentation Óscar Fuentes
2019-07-28 15:30 ` Eli Zaretskii
2019-07-28 15:56 ` Óscar Fuentes
2019-07-28 16:50 ` Eli Zaretskii
2019-07-29 0:36 ` Óscar Fuentes
2019-07-29 12:13 ` Štěpán Němec
2019-07-29 14:25 ` Óscar Fuentes
2019-07-29 14:41 ` Štěpán Němec
2019-07-29 14:38 ` Eli Zaretskii
2019-07-29 14:47 ` Štěpán Němec
2019-07-29 15:11 ` Eli Zaretskii
2019-07-29 15:20 ` Eli Zaretskii
2019-07-29 16:08 ` Štěpán Němec
2019-07-29 16:57 ` Eli Zaretskii
2019-07-29 17:44 ` Štěpán Němec [this message]
2019-07-29 18:13 ` Eli Zaretskii
2019-07-29 18:33 ` Štěpán Němec
2019-07-29 18:48 ` Eli Zaretskii
2019-07-29 19:20 ` Štěpán Němec
2019-07-29 19:31 ` Eli Zaretskii
2019-07-29 18:42 ` Óscar Fuentes
2019-07-29 19:26 ` Eli Zaretskii
2019-07-29 21:09 ` Óscar Fuentes
2019-07-30 15:08 ` Eli Zaretskii
2019-08-07 14:25 ` Eli Zaretskii
2019-08-07 15:00 ` Óscar Fuentes
2019-08-07 15:03 ` Eli Zaretskii
2019-10-26 3:16 ` Óscar Fuentes
2019-10-26 8:51 ` Eli Zaretskii
2019-10-26 11:55 ` Óscar Fuentes
2019-10-26 12:29 ` Eli Zaretskii
2019-10-26 13:27 ` Óscar Fuentes
2019-10-26 13:45 ` Eli Zaretskii
2019-10-26 20:05 ` Óscar Fuentes
2019-10-26 20:21 ` Eli Zaretskii
2019-10-26 20:40 ` Óscar Fuentes
2019-10-27 5:13 ` Eli Zaretskii
2019-10-27 23:50 ` Óscar Fuentes
2019-10-28 15:58 ` Eli Zaretskii
2019-10-28 19:40 ` Óscar Fuentes
2019-10-28 20:03 ` Eli Zaretskii
2019-10-28 20:21 ` Óscar Fuentes
2019-10-28 20:38 ` Eli Zaretskii
2019-10-28 21:45 ` Óscar Fuentes
2019-10-29 11:56 ` Eli Zaretskii
2019-11-02 17:08 ` Óscar Fuentes
2019-10-29 3:09 ` Richard Stallman
2019-10-26 3:33 ` Óscar Fuentes
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87wog0pwg6.fsf@gmail.com \
--to=stepnem@gmail.com \
--cc=36828@debbugs.gnu.org \
--cc=eliz@gnu.org \
--cc=ofv@wanadoo.es \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).