GNU bug report logs - #43255
28.0.50; feature/native-comp void-function subr-native-lambda-list

Previous Next

Full log

Message #46 received at 43255 <at> debbugs.gnu.org (full text, mbox):

From: Arthur Miller <arthur.miller <at> live.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 43255 <at> debbugs.gnu.org, Andrea Corallo <akrl <at> sdf.org>
Subject: Re: bug#43255: 28.0.50; feature/native-comp void-function
 subr-native-lambda-list
Date: Tue, 08 Sep 2020 12:38:13 +0200

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

> On September 8, 2020 7:26:12 AM GMT+03:00, Arthur Miller <arthur.miller <at> live.com> wrote:
>>Eli Zaretskii <eliz <at> gnu.org> writes:
>>
>>>> From: Andrea Corallo <akrl <at> sdf.org>
>>>> Cc: arthur.miller <at> live.com, 43255 <at> debbugs.gnu.org
>>>> Date: Mon, 07 Sep 2020 19:24:17 +0000
>>>> 
>>>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>>> 
>>> Why is it important for the user to know about the native compiler?
>>> E.g., how is it different from the C compiler switches used to build
>>> Emacs?
>>Just as important as x86_64 or linux-gnu :-).
>>
>>Currently when I press C-h C-a, I get this info (amongst other):
>>
>>GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.23,
>>cairo version 1.17.3)
>> of 2020-09-07
>>
>>I think it would be handy if there was a bit more info on that page.
>>I would prefer x64-native GNU/Linux. Why is it less important to know
>>about non-gui features? For me who has turned off most of gui stuff,
>>GTK
>>and Cairo versions are not really what I care about. I have them just
>>to
>>get better font rendering, but now I can maybe compile without at least
>>Gtk? I mean I don't need to know that it is compiled for GNU/Linux; I
>>know I am running on a GNU/Linux OS, or that it is a 64-bit OS, yet
>>info
>>is there.
>>
>>In my case I would have seen that I didn't compile with native compiler
>>support even though I intended (since the configure script failed
>>wihout
>>me noticing).
>>
>>I also wouldn't mind more info about compiler switches used to build
>>the
>>version as well as features/packages built-in. I don't know what is
>>essential more and I don't have any philosophical argument, more than
>>it
>>is sometimes useful.
>
> That's a different issue. The original question was about the splash screen and
> specifically about emacs-version.
Sorry; wasn't careful. Personally I don't care much about at all for
splash-screen, I don't even see it. I do use "about emacs-version".
Since I run Emacs directly from it's source folder, I usually do C-h C-a
to confirm it compiled

> I see no reason whatsoever to show information
> about the native compilation there, as it's a minor feature that moreover has no
> effect at all until some Lisp files are compiled with it. Besides, the splash
> screen is already too crowded.
I have no opinion for splash-screen whatsoever; mine is disabled anyway
:-).

> If you are saying that the "About Emacs" display should be redesigned (to make
> it look differently from the splash screen), I might agree, but then (a) please
> show a more detailed proposal, and (b) such a display doesn't need the change to
> be in emacs-version, it can use the other variables which divulge the details of
> the build and its configuration.
Ok. I'll think about, but I don't promise.

> Btw, in line with the recent "let's be like other apps" trend, I suggest to look
> at what other apps do in their "About" display: I have the impression that this
> fashion is on its way out.
I agree; I never look at those screens myself; so it is not so much
about "being like other apps". To me it is usefull to quickly see
compilation date of Emacs after the compile. I don't longer install
Emacs in system dir (no make install); I configured my system to run Emacs
directly from the "src" folder, so for me it is informational to see I
have restarted newly compiled version.

> Bottom line: you've effectively changed the subject, so I suggest to
> do that explicitly, and start a new thread/issue.
Yes sorry about that. If I get to make a proposal for new looks; I will
make a suggestion thread. For the now, you can let it die :).

Previous Next

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