[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#61014: closed (29.0.60; flymake-mode stderr warning is confusing whe

From: GNU bug Tracking System
Subject: bug#61014: closed (29.0.60; flymake-mode stderr warning is confusing when edit the init.el or eary-init.el)
Date: Sun, 12 Feb 2023 12:23:01 +0000

Your message dated Sun, 12 Feb 2023 14:22:17 +0200
with message-id <83ttzrgjk6.fsf@gnu.org>
and subject line Re: bug#61014: 29.0.60; flymake-mode stderr warning is 
confusing when edit the init.el or eary-init.el
has caused the debbugs.gnu.org bug report #61014,
regarding 29.0.60; flymake-mode stderr warning is confusing when edit the 
init.el or eary-init.el
to be marked as done.

(If you believe you have received this mail in error, please contact

61014: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=61014
GNU Bug Tracking System
Contact help-debbugs@gnu.org with problems
--- Begin Message --- Subject: 29.0.60; flymake-mode stderr warning is confusing when edit the init.el or eary-init.el Date: Mon, 23 Jan 2023 10:15:49 +0800
I found that when editing the init.el or eary-ini.el under
`user-emacs-directory`, flymake will report the warning as below:

Warning (initialization): Your `load-path' seems to contain
your `.emacs.d' directory: /Users/eason/.emacs.d/
This is likely to cause problems...
Consider using a subdirectory instead, e.g.: /Users/eason/.emacs.d/lisp

And this is because the variable `elisp-flymake-byte-compile-load-path`
has a defaut value `("./")`

so flymake adding the `.emacs.d` to the load-path and then also
complaining about it, it is confusing to users. May be we can improve

Steps to reproduce:

1. create a new .emacs.d folder in the HOME directory
2. create an empty init.e and eary-init.el file in the .emacs.d folder
3. Start Emacs and C-x, C-f open the init.el or early.el
4. M-x flymake-mode, add some blank lines in the init.el or early.el
5. C-x b, Switch to buffer:  *stderr of elisp-flymake-byte-compile*
Now you will see the warnings.

By the way, the message "Your `load-path' seems to contain
your `.emacs.d' directory" should use `user-emacs-directory` instead,
because some user will use `~/.config/emacs/` folder instead of

Eason Huang

In GNU Emacs 29.0.60 (build 1, x86_64-apple-darwin22.2.0, NS
 appkit-2299.30 Version 13.1 (Build 22C65), git sha1 846838dbab) of
 2023-01-22 built on macbook
Windowing system distributor 'Apple', version 10.3.2299
System Description:  macOS 13.1

Configured using:
 'configure --without-native-compilation --without-dbus
 'LDFLAGS=-L/opt/local/lib -Wl,-headerpad_max_install_names -Wl,-rpath
 -arch x86_64''

Configured features:

Important settings:
  locale-coding-system: utf-8-unix

Major mode: ELisp/l

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  line-number-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
None found.

(shadow sort mail-extr vc-git diff-mode easy-mmode vc-dispatcher
emacsbug message mailcap yank-media puny rfc822 mml mml-sec
password-cache epa derived epg rfc6068 epg-config gnus-util mm-decode
mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader
sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils
cl-extra noutline outline dired-aux dired dired-loaddefs time-date
subr-x checkdoc lisp-mnt help-mode cl-macs cl-seq flymake-proc flymake
project byte-opt gv bytecomp byte-compile compile text-property-search
comint ansi-osc ansi-color ring warnings icons thingatpt
emacs-git-version cl-loaddefs cl-lib rmc iso-transl tooltip cconv eldoc
paren electric uniquify ediff-hook vc-hooks lisp-float-type elisp-mode
mwheel term/ns-win ns-win ucs-normalize mule-util term/common-win
tool-bar dnd fontset image regexp-opt fringe tabulated-list replace
newcomment text-mode lisp-mode prog-mode register page tab-bar menu-bar
rfn-eshadow isearch easymenu timer select scroll-bar mouse jit-lock
font-lock syntax font-core term/tty-colors frame minibuffer nadvice seq
simple cl-generic indonesian philippine cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms
cp51932 hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese composite emoji-zwj charscript charprop case-table
epa-hook jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button
loaddefs theme-loaddefs faces cus-face macroexp files window
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget keymap hashtable-print-readable backquote threads kqueue
cocoa ns lcms2 multi-tty make-network-process emacs)

Memory information:
((conses 16 70613 13315)
 (symbols 48 8086 0)
 (strings 32 24199 1872)
 (string-bytes 1 729791)
 (vectors 16 16886)
 (vector-slots 8 227852 13364)
 (floats 8 38 127)
 (intervals 56 627 0)
 (buffers 984 18))

--- End Message ---
--- Begin Message --- Subject: Re: bug#61014: 29.0.60; flymake-mode stderr warning is confusing when edit the init.el or eary-init.el Date: Sun, 12 Feb 2023 14:22:17 +0200
> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: João Távora <joaotavora@gmail.com>,
>   aqua0210@foxmail.com,
>   61014@debbugs.gnu.org
> Date: Thu, 02 Feb 2023 11:01:20 -0500
> > How about disabling this warning in non-interactive sessions?  That
> > should be easy, and I don't see why we would want to emit such a
> > warning in non-interactive sessions anyway.
> Before making any change, I'd wait to see some explanation about why
> this message in a hidden " *stderr of elisp-flymake-byte-compile*" buffer
> is a problem.
> I think the choice of `load-path` in the subprocess is a concern (with
> no reliably right answer, sadly), and maybe it would make sense to
> avoid adding the CWD when we're in ~/.emacs.d (presumably using the
> same code used to decide whether to emit the warning under
> discussion :-), but there's no hurry for that.

No further comments, so I've now made that warning be emitted only in
interactive sessions, and I'm boldly marking this bug done.


--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]