GNU bug report logs -
#77666
Question/discussion about `trusted-content'
Previous Next
Full log
Message #20 received at 77666 <at> debbugs.gnu.org (full text, mbox):
> From: Dominik Schrempf <dominik.schrempf <at> gmail.com>
> Cc: monnier <at> iro.umontreal.ca, 77666 <at> debbugs.gnu.org
> Date: Thu, 10 Apr 2025 04:33:46 +0200
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> >> 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.
Maybe, but it won't happen, even if it is better (which I'm not sure
it is). Too many higher levels expect "~/foo" to keep is
HOME-relative form in Emacs.
Sorry, it's too late to change this.
> In your opinion, what is the reason of why we can not change such names?
Because it works, and doesn't cause any problems, and because by now
there are gobs of Lisp code that assumes this to be true.
> 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?
(3) mostly, but also: this is done for a reason. Users are happier to
see ~/foo in their file names and prompts than /home/whatever/foo.
Emacs uses these abbreviated file names for that reason.
> (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!
Sure, so how about suggesting to the glibc developers that glibc
renames the corresponding APIs to use "true" instead of "real"?
This bug report was last modified 124 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.