unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#72433: 29.4; Inconsistent "Loading" message suppression for batch mode
@ 2024-08-03  1:05 Derek Upham via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2024-08-03  6:04 ` Eli Zaretskii
  0 siblings, 1 reply; 4+ messages in thread
From: Derek Upham via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-08-03  1:05 UTC (permalink / raw)
  To: 72433


The relevant function is "load" (a.k.a "Fload").

The relevant file is "src/lread.c".

This exists in the current emacs-30 branch HEAD commit 94fe5894d99.

The function "load" has two code blocks that display progress messages
when loading files.  First:

  if (NILP (nomessage) || force_load_messages)
    {
      if (is_module)
        message_with_string ("Loading %s (module)...", file, 1);
      else if (is_native_elisp)
        message_with_string ("Loading %s (native compiled elisp)...", file, 1);
      else if (!compiled)
	message_with_string ("Loading %s (source)...", file, 1);
      else if (newer)
	message_with_string ("Loading %s (compiled; note, source file is newer)...",
		 file, 1);
      else /* The typical case; compiled file newer than source file.  */
	message_with_string ("Loading %s...", file, 1);
    }

Second:

  if (!noninteractive && (NILP (nomessage) || force_load_messages))
    {
      if (is_module)
        message_with_string ("Loading %s (module)...done", file, 1);
      else if (is_native_elisp)
	message_with_string ("Loading %s (native compiled elisp)...done", file, 1);
      else if (!compiled)
	message_with_string ("Loading %s (source)...done", file, 1);
      else if (newer)
	message_with_string ("Loading %s (compiled; note, source file is newer)...done",
		 file, 1);
      else /* The typical case; compiled file newer than source file.  */
	message_with_string ("Loading %s...done", file, 1);
    }

This pair follows the standard Emacs practice of an initial progress
message, a long activity, and then then the same message with "done" on
the end.

The second block's test skips the body if the "noninteractive" flag is
set.  (The "-batch" command line argument sets that flag, in "main()".)
But the first block's test does not take "noninteractive" into account.
That means that batch mode produces loading "half-messages".

  Loading /etc/emacs/site-start.d/00debian.el (source)...
  Loading /etc/emacs/site-start.d/50autoconf.el (source)...
  Loading /etc/emacs/site-start.d/50bbdb3.el (source)...

We probably want consistent non-display in batch mode, which we can get
by adding a similar "!noninteractive" test to the first progress block.




In GNU Emacs 29.4 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.42,
 cairo version 1.18.0) of 2024-06-29, modified by Debian built on sbuild
Windowing system distributor 'The X.Org Foundation', version 11.0.12101011
System Description: Debian GNU/Linux trixie/sid

Configured using:
 'configure --build x86_64-linux-gnu --prefix=/usr
 --sharedstatedir=/var/lib --libexecdir=/usr/libexec
 --localstatedir=/var/lib --infodir=/usr/share/info
 --mandir=/usr/share/man --with-libsystemd --with-pop=yes
 --enable-locallisppath=/etc/emacs:/usr/local/share/emacs/29.4/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/29.4/site-lisp:/usr/share/emacs/site-lisp
 --with-sound=alsa --without-gconf --with-mailutils
 --with-native-compilation --build x86_64-linux-gnu --prefix=/usr
 --sharedstatedir=/var/lib --libexecdir=/usr/libexec
 --localstatedir=/var/lib --infodir=/usr/share/info
 --mandir=/usr/share/man --with-libsystemd --with-pop=yes
 --enable-locallisppath=/etc/emacs:/usr/local/share/emacs/29.4/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/29.4/site-lisp:/usr/share/emacs/site-lisp
 --with-sound=alsa --without-gconf --with-mailutils
 --with-native-compilation --with-cairo --with-x=yes
 --with-x-toolkit=gtk3 --with-toolkit-scroll-bars 'CFLAGS=-g -O2
 -Werror=implicit-function-declaration
 -ffile-prefix-map=/build/reproducible-path/emacs-29.4+1=. -fstack-protector-strong
 -fstack-clash-protection -Wformat -Werror=format-security
 -fcf-protection -Wall' 'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2'
 LDFLAGS=-Wl,-z,relro'

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
JSON LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES
NATIVE_COMP NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP SOUND SQLITE3
THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER WEBP X11 XDBE XIM XINPUT2
XPM GTK3 ZLIB

-- 
Derek Upham
derek_upham@mailfence.com





^ permalink raw reply	[flat|nested] 4+ messages in thread

* bug#72433: 29.4; Inconsistent "Loading" message suppression for batch mode
  2024-08-03  1:05 bug#72433: 29.4; Inconsistent "Loading" message suppression for batch mode Derek Upham via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-08-03  6:04 ` Eli Zaretskii
  2024-08-03 16:08   ` Derek Upham via Bug reports for GNU Emacs, the Swiss army knife of text editors
  0 siblings, 1 reply; 4+ messages in thread
From: Eli Zaretskii @ 2024-08-03  6:04 UTC (permalink / raw)
  To: Derek Upham; +Cc: 72433

tags 72433 notabug wontfix
thanks

> Date: Fri, 02 Aug 2024 18:05:59 -0700
> From:  Derek Upham via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> 
> 
> The second block's test skips the body if the "noninteractive" flag is
> set.  (The "-batch" command line argument sets that flag, in "main()".)
> But the first block's test does not take "noninteractive" into account.
> That means that batch mode produces loading "half-messages".
> 
>   Loading /etc/emacs/site-start.d/00debian.el (source)...
>   Loading /etc/emacs/site-start.d/50autoconf.el (source)...
>   Loading /etc/emacs/site-start.d/50bbdb3.el (source)...

Yes, and this is done on purpose: in batch mode the second line is
redundant because all the lines remain visible on the screen, whereas
in the interactive case the user can only see the last message (in the
echo area), and thus leaving the "Loading..." message there could be
misinterpreted as if the load is still in progress.

> We probably want consistent non-display in batch mode, which we can get
> by adding a similar "!noninteractive" test to the first progress block.

No, we don't want consistency in this case, at least not this kind of
consistency.

This is not a bug.





^ permalink raw reply	[flat|nested] 4+ messages in thread

* bug#72433: 29.4; Inconsistent "Loading" message suppression for batch mode
  2024-08-03  6:04 ` Eli Zaretskii
@ 2024-08-03 16:08   ` Derek Upham via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2024-08-04  8:58     ` Eli Zaretskii
  0 siblings, 1 reply; 4+ messages in thread
From: Derek Upham via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-08-03 16:08 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 72433

[-- Attachment #1: Type: text/plain, Size: 652 bytes --]


On Aug 2, 2024 at 11:04 PM, Eli Zaretskii <eliz@gnu.org> wrote:Yes, and this is done on purpose: in batch mode the second line is
redundant because all the lines remain visible on the screen, whereas
in the interactive case the user can only see the last message (in the
echo area), and thus leaving the "Loading..." message there could be
misinterpreted as if the load is still in progress.
Got it.  Is it worth turning this into a code comment, before that second block?

/* Support interactive users with extra progress messages,
   following minibuffer conventions. */

-- 
Sent with https://mailfence.com
Secure and private email

[-- Attachment #2: Type: text/html, Size: 968 bytes --]

^ permalink raw reply	[flat|nested] 4+ messages in thread

* bug#72433: 29.4; Inconsistent "Loading" message suppression for batch mode
  2024-08-03 16:08   ` Derek Upham via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-08-04  8:58     ` Eli Zaretskii
  0 siblings, 0 replies; 4+ messages in thread
From: Eli Zaretskii @ 2024-08-04  8:58 UTC (permalink / raw)
  To: Derek Upham; +Cc: 72433-done

> Date: Sat, 3 Aug 2024 18:08:02 +0200 (CEST)
> From: Derek Upham <derek_upham@mailfence.com>
> Cc: 72433@debbugs.gnu.org
> 
> Got it.  Is it worth turning this into a code comment, before that second block?
> 
> /* Support interactive users with extra progress messages,
>    following minibuffer conventions. */

Done, and closing the bug.





^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2024-08-04  8:58 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-08-03  1:05 bug#72433: 29.4; Inconsistent "Loading" message suppression for batch mode Derek Upham via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-08-03  6:04 ` Eli Zaretskii
2024-08-03 16:08   ` Derek Upham via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-08-04  8:58     ` Eli Zaretskii

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).