From: Arthur Miller <arthur.miller@live.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 43255@debbugs.gnu.org, Andrea Corallo <akrl@sdf.org>
Subject: bug#43255: 28.0.50; feature/native-comp void-function subr-native-lambda-list
Date: Tue, 08 Sep 2020 12:38:13 +0200 [thread overview]
Message-ID: <VI1PR06MB4526130140FBFA882CE6A4AD96290@VI1PR06MB4526.eurprd06.prod.outlook.com> (raw)
In-Reply-To: <062E9DA2-B039-4AAD-802B-7333971F5B73@gnu.org> (Eli Zaretskii's message of "Tue, 08 Sep 2020 08:04:03 +0300")
Eli Zaretskii <eliz@gnu.org> writes:
> On September 8, 2020 7:26:12 AM GMT+03:00, Arthur Miller <arthur.miller@live.com> wrote:
>>Eli Zaretskii <eliz@gnu.org> writes:
>>
>>>> From: Andrea Corallo <akrl@sdf.org>
>>>> Cc: arthur.miller@live.com, 43255@debbugs.gnu.org
>>>> Date: Mon, 07 Sep 2020 19:24:17 +0000
>>>>
>>>> Eli Zaretskii <eliz@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 :).
prev parent reply other threads:[~2020-09-08 10:38 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-07 10:16 bug#43255: 28.0.50; feature/native-comp void-function subr-native-lambda-list arthur.miller
2020-09-07 12:39 ` Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-09-07 13:54 ` bug#43255: Sv: " arthur miller
2020-09-07 14:28 ` Arthur Miller
2020-09-07 16:34 ` Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-09-07 16:54 ` Eli Zaretskii
2020-09-07 17:19 ` Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-09-07 19:11 ` Eli Zaretskii
2020-09-07 19:24 ` Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-09-08 2:25 ` Eli Zaretskii
2020-09-08 4:26 ` Arthur Miller
2020-09-08 5:04 ` Eli Zaretskii
2020-09-08 7:47 ` Stefan Kangas
2020-09-08 14:27 ` Eli Zaretskii
2020-09-08 14:54 ` Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-09-08 15:25 ` Eli Zaretskii
2020-09-08 16:02 ` Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-09-08 16:21 ` Eli Zaretskii
2020-09-08 8:03 ` bug#43269: 28.0.50; [feature/native-comp] provide a user feedback on Emacs being native compiled Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-09-08 14:30 ` Eli Zaretskii
2020-09-09 3:45 ` Richard Stallman
2020-09-09 7:46 ` Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-09-09 14:23 ` Eli Zaretskii
2020-09-09 14:14 ` Eli Zaretskii
2020-09-09 15:19 ` Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-09-09 16:10 ` Eli Zaretskii
2020-09-09 16:32 ` Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-09-09 17:17 ` Eli Zaretskii
2020-09-09 18:15 ` Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-09-09 19:02 ` Eli Zaretskii
2020-09-09 21:51 ` Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-09-10 3:26 ` Eli Zaretskii
2020-10-17 6:35 ` Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-10-17 7:29 ` Lars Ingebrigtsen
2020-10-17 7:47 ` Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-10-17 8:00 ` Lars Ingebrigtsen
2020-10-17 8:18 ` Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-10-17 8:26 ` Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-10-17 9:09 ` Eli Zaretskii
2020-10-17 10:25 ` Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-10-17 11:17 ` Eli Zaretskii
2020-10-17 18:48 ` Arthur Miller
2020-10-17 18:54 ` Eli Zaretskii
2020-10-17 19:21 ` Arthur Miller
2020-10-17 19:34 ` Eli Zaretskii
2020-10-17 19:45 ` Arthur Miller
2020-10-17 19:02 ` Corwin Brust
2020-10-17 21:20 ` Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-09-10 12:16 ` Lars Ingebrigtsen
2020-09-09 16:48 ` Stefan Kangas
2022-04-28 10:32 ` Lars Ingebrigtsen
2020-09-08 10:38 ` Arthur Miller [this message]
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=VI1PR06MB4526130140FBFA882CE6A4AD96290@VI1PR06MB4526.eurprd06.prod.outlook.com \
--to=arthur.miller@live.com \
--cc=43255@debbugs.gnu.org \
--cc=akrl@sdf.org \
--cc=eliz@gnu.org \
/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).