GNU bug report logs - #77666
Question/discussion about `trusted-content'

Previous Next

Full log

View this message in rfc822 format

From: Dominik Schrempf <dominik.schrempf <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 77666 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
Subject: bug#77666: Question/discussion about `trusted-content'
Date: Thu, 10 Apr 2025 04:33:46 +0200

Thank you for taking your time to answer my questions!

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Dominik Schrempf <dominik.schrempf <at> gmail.com>
>> Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>,  77666 <at> debbugs.gnu.org
>> Date: Wed, 09 Apr 2025 16:22:58 +0200
>>
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>
>> >>     Use abbreviated file names.  For example, an entry "~/mycode/" means
>> >>     that Emacs will trust all the files in your directory "mycode".
>> >>
>> >> Why is this second requirement in place?
>> >
>> > For speed, I believe.  (But Stefan will correct me if I'm wrong.)
>>
>> Do you mean comparing "/home/user/mycode" is slower than comparing
>> "~/mycode/"?
>
> No, but comparing "~/mycode" with "/home/user/mycode" is slower, if we
> want them to compare equal.

I think this problem would not arise if Emacs treated all filenames as
"completely"/"truly (:-))" (no pun intended) absolute. In my opinion,
and without knowing many details about the interior design of Emacs,
this would probably also be the ideal situation.

>
>> > HOME-relative file names are considered absolute file names in Emacs:
>> >
>> >   (file-name-absolute-p "~/.emacs.d/")
>> >    => t
>>
>> Thank you, I didn't know that. Does this make sense? The file will be
>> different for two different users, which is not the case for absolute
>> file names in the classical sense.
>
> There's only one user in a given Emacs session.
>
> Outside of Emacs, these will be different file names, but since Emacs
> always records the abbreviated name, it will become ~/something only
> for the user of the current Emacs session; file names relative to HOME
> of other users will remain in their absolute form.
>
>> > Emacs always abbreviates HOME-relative file names, so adhering to that
>> > convention means we can compare file names as strings, instead of
>> > using file-truename (which hits the disk) and similar APIs to
>> > "normalize" the file names before comparing.
>>
>> Thanks for your explanation.
>>
>> I believe that by now, we are having a discussion about two different
>> but somewhat related concepts: "absolute" vs "relative" filenames and
>> the "true" vs "real" filenames.
>>
>> I still wanted to state that the term "true filename" confused me and is
>> still confusing me. I think it should be "real", at least to me this
>> seems more of a Linux/Unix? standard.
>
> Emacs predates realpath and friends, so we had this terminology first,
> and we cannot change it now, since it's so old.

Good to know, thank you.

In your opinion, what is the reason of why we can not change such names?
Is this because (1) we do not have enough resources to change such
discrepancies in nomenclature, or (2) because we are not willing to
change nomenclature, or (3) we must ensure backwards compatibility?

(I just grepped for "truename" in the Emacs repository and got 942 hits).

Independently of what we can change or not, I think it is important to
reduce discrepancies in nomenclature. Thanks for hearing me out!

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.