bug#25083: 26.0.50; poor interaction between flymake and desktop-save-mode

bug#25083: 26.0.50; poor interaction between flymake and desktop-save-mode

[Sam Steingold]

When I start Emacs after editing a bunch of Python files,
desktop-save-mode restores them and flymake starts syntax checking
processes in each of them.

However, there is a snag: python virtual environments.
Basically, each python projects uses a separate virtual environments
which includes its own python packages, and, moreover, its own python
and pylint executables(!)

This means that flymake fails to find the epylint executable and
displays a GUI popup(!) for each(!) python file that I edited in the
previous session.  Note that this failure should _not_ be fatal (see PS
below).

You can imagine, I am sure, how frustrating it is to have to click on
"OK" (or even hit "esc") 30 times before Emacs actually starts.
The workaround is to customize `flymake-gui-warnings-enabled' to nil,
but this is only one part of the problem.

The necessary fixes would entail:

* flymake should only display GUI warnings in response to a manual
  action, not when desktop-save-mode restores a buffer.

* the initial failure in desktop-save-mode should "defer" flymake rather
  than "disable" it permanently.


PS. Fixing the following will probably require pyvenv-specific work and
is outside the core Emacs issues, but maybe you have suggestions:

This initial failure, apparently, makes flymake _disable_ itself in all
restored buffers, so I have to re-enable it manually (if & when I notice
that it is not running there).

When I select the Python virtual environment using the pyvenv-workon
command (I might also disable virtual environment altogether or switch
between them &c), the location of the epylint executable should change.



In GNU Emacs 26.0.50.2 (x86_64-apple-darwin16.1.0, NS appkit-1504.60 Version 10.12.1 (Build 16B2555))
 of 2016-12-01 built on clr-sds
Repository revision: bb8e38273e701ad5c65e747e8eda3bd8f3aa4adb
Windowing system distributor 'Apple', version 10.3.1504
Recent messages:
Running hg log -r . -l1 --template {i... ....OK = 0
Compiling /Users/sds/.emacs.el...done
Wrote /Users/sds/.emacs.elc
Mark set
Quit
Mark saved where search started
nil [2 times]
t
nil
Scanning for dabbrevs...done

Configured using:
 'configure --with-ns
 PKG_CONFIG_PATH=/usr/local/opt/libxml2/lib/pkgconfig:/usr/local/opt/imagemagick/lib/pkgconfig/'

Configured features:
IMAGEMAGICK NOTIFY ACL GNUTLS LIBXML2 ZLIB TOOLKIT_SCROLL_BARS NS

Important settings:
  value of $LANG: C
  locale-coding-system: utf-8-unix

Major mode: Emacs-Lisp

Minor modes in effect:
  pyvenv-mode: t
  diff-auto-refine-mode: t
  rcirc-track-minor-mode: t
  which-function-mode: t
  url-handler-mode: t
  show-paren-mode: t
  desktop-save-mode: t
  shell-dirtrack-mode: t
  tooltip-mode: t
  global-eldoc-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
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  column-number-mode: t
  line-number-mode: t
  abbrev-mode: t

Load-path shadows:
/Users/sds/.emacs.d/elpa/scala-mode-20160902.525/ob-scala hides /Users/sds/src/emacs/trunk/lisp/org/ob-scala

Features:
(shadow sort bbdb-message mailalias cookie1 mail-extr gnus-msg gnus-art
mm-uu mml2015 mm-view mml-smime smime dig mailcap gnus-sum gnus-group
gnus-undo gnus-start gnus-cloud nnimap nnmail mail-source tls gnutls
utf7 netrc nnoo parse-time gnus-spec gnus-int gnus-range gnus-win
dabbrev emacsbug sendmail skeleton cl-indent misearch multi-isearch
find-func apropos log-edit message puny rfc822 mml mml-sec epa epg
epg-config mm-decode mm-bodies mm-encode mail-parse rfc2231 gmm-utils
mailheader pcvs-util time-stamp smerge-mode pp vc-bzr vc-src vc-sccs
vc-svn vc-cvs vc-rcs add-log view dired-aux dired dired-loaddefs
company-oddmuse company-keywords company-etags company-gtags
company-dabbrev-code company-dabbrev company-files company-cmake
company-xcode company-clang company-eclim company-template company-css
company-nxml company-bbdb yasnippet flymake company help-fns radix-tree
elpy find-file-in-project ivy delsel ivy-overlay ffap pyvenv
elpy-refactor derived edmacro kmacro grep files-x etags xref project
cus-edit python tramp-sh json vc-dir ewoc vc vc-git diff-mode map
vc-dispatcher vc-hg flyspell ispell finder-inf info package warnings
midnight ein-loaddefs gnus nnheader subr-x gnus-util rmail
rmail-loaddefs rfc2047 rfc2045 ietf-drums mail-utils mm-util mail-prsvr
wid-edit bbdb-mua bbdb-com crm mailabbrev bbdb-loaddefs bbdb bbdb-site
timezone rcirc server which-func imenu url-handlers url-parse url-vars
paren help-at-pt desktop frameset cus-start cus-load ido seq ess-toolbar
ess-mouse mouseme thingatpt browse-url ess-menu ess-swv ess-noweb
ess-noweb-font-lock-mode ess-bugs-l essd-els ess-sas-d ess-sas-l
ess-sas-a ess-sta-d ess-sta-l cc-vars cc-defs make-regexp ess-sp6-d
ess-dde ess-sp3-d ess-julia ess-r-d ess-r-syntax ess-r-completion
ess-roxy essddr noutline outline easy-mmode hideshow ess-help
ess-r-package ess-s-l ess ess-inf ess-tracebug compile tramp
tramp-compat tramp-loaddefs trampver shell pcomplete comint ansi-color
ring format-spec advice auth-source cl-seq eieio byte-opt bytecomp
byte-compile cl-extra help-mode cconv eieio-core cl-macs eieio-loaddefs
password-cache ess-mode ess-noweb-mode ess-utils ess-generics ess-custom
executable easymenu ess-compat ess-site cl gv cl-loaddefs pcase cl-lib
time-date mule-util tooltip eldoc electric uniquify ediff-hook vc-hooks
lisp-float-type mwheel term/ns-win ns-win ucs-normalize term/common-win
tool-bar dnd fontset image regexp-opt fringe tabulated-list replace
newcomment text-mode elisp-mode lisp-mode prog-mode register page
menu-bar rfn-eshadow isearch timer select scroll-bar mouse jit-lock
font-lock syntax facemenu font-core term/tty-colors frame cl-generic
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 charscript
case-table epa-hook jka-cmpr-hook help simple abbrev obarray minibuffer
cl-preloaded nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote kqueue cocoa ns
multi-tty make-network-process emacs)

Memory information:
((conses 16 642163 39633)
 (symbols 48 46093 0)
 (miscs 40 7223 57)
 (strings 32 210073 19420)
 (string-bytes 1 5186064)
 (vectors 16 81486)
 (vector-slots 8 1396247 7356)
 (floats 8 1232 676)
 (intervals 56 10786 54)
 (buffers 976 58))

-- 
Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1504
http://steingoldpsychology.com http://www.childpsy.net
http://memri.org https://ffii.org http://thereligionofpeace.com
Those who value Life above Freedom are destined to lose both.

bug#25083: 26.0.50; poor interaction between flymake and desktop-save-mode

[Eli Zaretskii]

> From: Sam Steingold <sds@gnu.org>
> Date: Thu, 01 Dec 2016 14:13:20 -0500
> 
> When I start Emacs after editing a bunch of Python files,
> desktop-save-mode restores them and flymake starts syntax checking
> processes in each of them.
> 
> However, there is a snag: python virtual environments.
> Basically, each python projects uses a separate virtual environments
> which includes its own python packages, and, moreover, its own python
> and pylint executables(!)
> 
> This means that flymake fails to find the epylint executable and
> displays a GUI popup(!) for each(!) python file that I edited in the
> previous session.  Note that this failure should _not_ be fatal (see PS
> below).

Isn't there some variable(s) which you could instruct desktop.el to
save, in order to avoid these problems?  IOW, why doesn't desktop
restore whatever setup you had before shutting down Emacs, which
avoided the prompts at that time?

bug#25083: 26.0.50; poor interaction between flymake and desktop-save-mode

[Sam Steingold]

you are making a good point.
however, _I_ (the user) should not have to deal with this myself.
flymake should know how to work with desktop.

however, the problem here is that the check command is merely
"epylint" and it is found in the path which is modified by pyvenv.
I agree that elpy/pyvenv should, ideally, handle that (see
https://github.com/jorgenschaefer/elpy/issues/1035).
however, it is not obvious to me that there is nothing flymake can do
to alleviate my pain.

at the very least, the massive errors on re-start should not be
reported via GUI.


On Thu, Dec 1, 2016 at 2:41 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Sam Steingold <sds@gnu.org>
>> Date: Thu, 01 Dec 2016 14:13:20 -0500
>>
>> When I start Emacs after editing a bunch of Python files,
>> desktop-save-mode restores them and flymake starts syntax checking
>> processes in each of them.
>>
>> However, there is a snag: python virtual environments.
>> Basically, each python projects uses a separate virtual environments
>> which includes its own python packages, and, moreover, its own python
>> and pylint executables(!)
>>
>> This means that flymake fails to find the epylint executable and
>> displays a GUI popup(!) for each(!) python file that I edited in the
>> previous session.  Note that this failure should _not_ be fatal (see PS
>> below).
>
> Isn't there some variable(s) which you could instruct desktop.el to
> save, in order to avoid these problems?  IOW, why doesn't desktop
> restore whatever setup you had before shutting down Emacs, which
> avoided the prompts at that time?



-- 
Sam Steingold <http://sds.podval.org> <http://www.childpsy.net>
<http://steingoldpsychology.com>

bug#25083: 26.0.50; poor interaction between flymake and desktop-save-mode

[Eli Zaretskii]

> From: Sam Steingold <sds@gnu.org>
> Date: Thu, 1 Dec 2016 15:04:14 -0500
> Cc: 25083@debbugs.gnu.org
> 
> you are making a good point.
> however, _I_ (the user) should not have to deal with this myself.
> flymake should know how to work with desktop.

My intent was to suggest a way in which this could be solved, not to
imply that there's no problwm.  As seem to be familiar with flymake, I
hoped that you might be able to point to that variable, and we could
either included it by default, or at least discuss whether setting it
(assuming it exists) is a user-level issue.

Thanks.

bug#25083: 26.0.50; poor interaction between flymake and desktop-save-mode

[Sam Steingold]

the flymake command is "epylint" and it worked because exec-path was
modified by pyvenv-workon.
I am not sure exec-path should be saved by desktop.
thanks!

On Thu, Dec 1, 2016 at 2:41 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Sam Steingold <sds@gnu.org>
>> Date: Thu, 01 Dec 2016 14:13:20 -0500
>>
>> When I start Emacs after editing a bunch of Python files,
>> desktop-save-mode restores them and flymake starts syntax checking
>> processes in each of them.
>>
>> However, there is a snag: python virtual environments.
>> Basically, each python projects uses a separate virtual environments
>> which includes its own python packages, and, moreover, its own python
>> and pylint executables(!)
>>
>> This means that flymake fails to find the epylint executable and
>> displays a GUI popup(!) for each(!) python file that I edited in the
>> previous session.  Note that this failure should _not_ be fatal (see PS
>> below).
>
> Isn't there some variable(s) which you could instruct desktop.el to
> save, in order to avoid these problems?  IOW, why doesn't desktop
> restore whatever setup you had before shutting down Emacs, which
> avoided the prompts at that time?



-- 
Sam Steingold <http://sds.podval.org> <http://www.childpsy.net>
<http://steingoldpsychology.com>

bug#25083: 26.0.50; poor interaction between flymake and desktop-save-mode

[Glenn Morris]

Sam Steingold wrote:

> * flymake should only display GUI warnings in response to a manual
>   action, not when desktop-save-mode restores a buffer.

Fixed in 041afb2.

> * the initial failure in desktop-save-mode should "defer" flymake rather
>   than "disable" it permanently.

I don't know what this means.

> PS. Fixing the following will probably require pyvenv-specific work and
> is outside the core Emacs issues

Indeed, pyvenv should add the necessary items to the list of things that
desktop saves and restores.

bug#25083: 26.0.50; poor interaction between flymake and desktop-save-mode

[Stefan Kangas]

Glenn Morris <rgm@gnu.org> writes:

> Sam Steingold wrote:
>
>> * flymake should only display GUI warnings in response to a manual
>>   action, not when desktop-save-mode restores a buffer.
>
> Fixed in 041afb2.
>
>> * the initial failure in desktop-save-mode should "defer" flymake rather
>>   than "disable" it permanently.
>
> I don't know what this means.
>
>> PS. Fixing the following will probably require pyvenv-specific work and
>> is outside the core Emacs issues
>
> Indeed, pyvenv should add the necessary items to the list of things that
> desktop saves and restores.

Having read the discussion, it seems like this issue was fixed by Glenn
in the above commit.  The rest is discussing something which we don't
know what it means, and something which is outside Emacs development.

Since there seems to be nothing more to do here, I'm closing this bug
report.

If this conclusion is incorrect, please reply to this email (use "Reply
to all" in your email client) and we can reopen the bug report.  Thanks.

Best regards,
Stefan Kangas