bug#50187: 28.0.50; tramp is called from calendar

bug#50187: 28.0.50; tramp is called from calendar

[Steingold]

I get this trace:

--8<---------------cut here---------------start------------->8---
  tramp-file-name-handler(file-readable-p "/scp:remote:/path/Contents/Resources/site-lisp/cal-move.so")
  calendar-cursor-to-visible-date((8 24 2021))
  calendar-generate-window(8 2021)
  calendar-basic-setup(nil)
  calendar()
  run-hooks(midnight-hook)
  apply(run-hooks midnight-hook)
  timer-event-handler([t 24869 56416 388128 86400 run-hooks (midnight-hook) nil 0])
--8<---------------cut here---------------end--------------->8---

I do have a file "/scp:remote:/path/foo/bar/baz.py" open.
"remote" is not accessible because the VPN is down.
"/scp:remote:/path/" is the location of the .git directory for baz.py.
"remote" is linux, localhost is mac. of course there is no
Contents/Resources/site-lisp/cal-move.so on "remote".
How come "calendar" calls "tramp"?
when I click on the function name in *Backtrace* to get to the source
code, tramp is called and I get an infinite loop of
"Tramp: Opening connection nil for remote using scp...failed"
I have to C-g and M-x tramp-cleanup-all-connections to get back to editing.


In GNU Emacs 28.0.50 (build 5, x86_64-apple-darwin19.6.0, NS appkit-1894.60 Version 10.15.7 (Build 19H1323))
 of 2021-08-23 built on 3c22fb11fdab.ant.amazon.com
Repository revision: 00edc8329a6277f2e5b5204efbe503e2b7957006
Repository branch: master
Windowing system distributor 'Apple', version 10.3.1894
System Description:  Mac OS X 10.15.7

Configured using:
 'configure --with-imagemagick --with-mailutils --with-ns
 PKG_CONFIG_PATH=/usr/local/opt/libxml2/lib/pkgconfig:/usr/local/opt/imagemagick/lib/pkgconfig:/usr/local/opt/gnutls/lib/pkgconfig:/usr/local/opt/jansson/lib/pkgconfig:/usr/local/opt/libtiff/lib/pkgconfig:/usr/local/opt/libpng/lib/pkgconfig:/usr/local/opt/libjpeg/lib/pkgconfig:/usr/local/opt/freetype/lib/pkgconfig'

Configured features:
ACL GMP GNUTLS IMAGEMAGICK JPEG JSON LCMS2 LIBXML2 MODULES NOTIFY KQUEUE
NS PDUMPER PNG THREADS TIFF TOOLKIT_SCROLL_BARS ZLIB

Important settings:
  value of $LC_ALL: en_US.UTF-8
  value of $LANG: C
  locale-coding-system: utf-8-unix

Major mode: VC dir

Minor modes in effect:
  pyvenv-mode: t
  shell-dirtrack-mode: t
  global-edit-server-edit-mode: t
  winner-mode: t
  which-function-mode: t
  url-handler-mode: t
  show-paren-mode: t
  desktop-save-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tab-bar-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
  buffer-read-only: t
  column-number-mode: t
  line-number-mode: t

Load-path shadows:
Error during checking
Features:
(tramp-cmds smiley gnus-cite qp gnus-async gnus-bcklg gnus-dup gnus-ml
hl-line disp-table spam spam-stat gnus-uu yenc nndraft nnmh gnus-agent
gnus-srvr gnus-score score-mode nnvirtual utf-7 gnus-cache bbdb-gnus
nntp smtpmail shadow sort bbdb-message mailalias cookie1 mail-extr
gnus-msg emacsbug sendmail vc-mtn vc-src vc-sccs vc-svn vc-cvs vc-rcs
vc-dir ewoc cl-print debug backtrace dabbrev skeleton misearch
multi-isearch rx color autoload lisp-mnt mm-archive gnutls
network-stream url-http url-gw nsm url-cache url-auth finder-inf package
add-log vc-hg vc-bzr tramp-cache remember vc cc-mode cc-fonts cc-guess
cc-menus cc-cmds cc-styles cc-align cc-engine cc-vars cc-defs
bug-reference conf-mode company-oddmuse company-keywords company-etags
company-gtags company-dabbrev-code company-dabbrev company-files
company-clang company-template company-cmake company-bbdb
yasnippet-snippets yasnippet flymake-proc flymake company-capf company
pcase help-fns radix-tree elpy edmacro kmacro elpy-rpc pyvenv eshell
esh-cmd esh-ext esh-opt esh-proc esh-io esh-arg esh-module esh-groups
esh-util elpy-shell elpy-profile elpy-django s elpy-refactor ido grep
compile etags fileloop xref project cus-edit pp cus-start python
tramp-sh tramp tramp-loaddefs trampver tramp-integration files-x
tramp-compat shell ls-lisp flyspell ispell org-element avl-tree
generator ol-eww eww xdg url-queue thingatpt mm-url ol-rmail ol-mhe
ol-irc ol-info ol-gnus nnselect gnus-search eieio-opt cl-extra help-mode
speedbar ezimage dframe gnus-art mm-uu mml2015 mm-view mml-smime smime
dig gnus-sum shr kinsoku svg dom browse-url url url-proxy url-privacy
url-expand url-methods url-history url-cookie url-domsuf url-util
mailcap gnus-group gnus-undo gnus-start gnus-dbus dbus xml gnus-cloud
nnimap nnmail mail-source utf7 netrc nnoo parse-time gnus-spec gnus-int
gnus-range message rmc puny rfc822 mml mml-sec epa derived epg
epg-config mm-decode mm-bodies mm-encode mail-parse rfc2231 gmm-utils
mailheader gnus-win ol-docview doc-view jka-compr image-mode exif
ol-bibtex bibtex iso8601 ol-bbdb ol-w3m org ob ob-tangle ob-ref ob-lob
ob-table ob-exp org-macro org-footnote org-src ob-comint org-pcomplete
pcomplete comint ansi-color org-list org-faces org-entities noutline
outline org-version ob-emacs-lisp ob-core ob-eval org-table ol org-keys
org-compat org-macs org-loaddefs format-spec find-func cal-x view
cal-china cal-bahai cal-islam holidays hol-loaddefs bbdb-anniv cal-iso
cal-hebrew lunar cal-julian solar cal-dst vc-git diff-mode easy-mmode
vc-dispatcher appt diary-lib diary-loaddefs cal-menu calendar
cal-loaddefs dired-aux dired dired-loaddefs midnight warnings gnus
nnheader gnus-util rmail rmail-loaddefs rfc2047 rfc2045 ietf-drums
text-property-search time-date mail-utils mm-util mail-prsvr wid-edit
bbdb-mua bbdb-com crm mailabbrev bbdb bbdb-site timezone edit-server
advice server winner ring which-func imenu url-handlers url-parse
auth-source cl-seq eieio eieio-core cl-macs eieio-loaddefs
password-cache json subr-x map seq byte-opt gv bytecomp byte-compile
cconv url-vars paren help-at-pt desktop frameset cl-loaddefs cl-lib
cus-load info iso-transl tooltip eldoc electric uniquify ediff-hook
vc-hooks lisp-float-type 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 elisp-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 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 charprop case-table epa-hook
jka-cmpr-hook help simple abbrev obarray cl-preloaded nadvice button
loaddefs faces cus-face macroexp files window text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote threads kqueue cocoa ns lcms2
multi-tty make-network-process emacs)

Memory information:
((conses 16 1907075 184330)
 (symbols 48 42376 26)
 (strings 32 404355 48896)
 (string-bytes 1 11953164)
 (vectors 16 124222)
 (vector-slots 8 2158656 320801)
 (floats 8 1033 615)
 (intervals 56 173673 4887)
 (buffers 992 62))

-- 
Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1894
http://childpsy.net http://calmchildstories.com http://steingoldpsychology.com
https://jij.org https://www.dhimmitude.org https://www.peaceandtolerance.org/
Genius is immortal, but morons live longer.

bug#50187: 28.0.50; tramp is called from calendar

[Lars Ingebrigtsen]

Steingold <sds@gnu.org> writes:

> I get this trace:
>
>   tramp-file-name-handler(file-readable-p "/scp:remote:/path/Contents/Resources/site-lisp/cal-move.so")
>   calendar-cursor-to-visible-date((8 24 2021))
>   calendar-generate-window(8 2021)
>   calendar-basic-setup(nil)
>   calendar()
>   run-hooks(midnight-hook)
>   apply(run-hooks midnight-hook)
>   timer-event-handler([t 24869 56416 388128 86400 run-hooks (midnight-hook) nil 0])

(I'm going through old bug reports that unfortunately weren't resolved
at the time.)

calendar-cursor-to-visible-date is an autoloaded function, so what's
happening is that Emacs is trying to load the cal-move file -- and
looking into "/scp:remote:/path/Contents/Resources/site-lisp/".

Can something have put that in your load-path by any chance?

bug#50187: 28.0.50; tramp is called from calendar

[Sam Steingold]

> * Lars Ingebrigtsen <ynefv@tahf.bet> [2022-08-22 16:28:38 +0200]:
>
> Steingold <sds@gnu.org> writes:
>
>> I get this trace:
>>
>>   tramp-file-name-handler(file-readable-p "/scp:remote:/path/Contents/Resources/site-lisp/cal-move.so")
>>   calendar-cursor-to-visible-date((8 24 2021))
>>   calendar-generate-window(8 2021)
>>   calendar-basic-setup(nil)
>>   calendar()
>>   run-hooks(midnight-hook)
>>   apply(run-hooks midnight-hook)
>>   timer-event-handler([t 24869 56416 388128 86400 run-hooks (midnight-hook) nil 0])
>
> (I'm going through old bug reports that unfortunately weren't resolved
> at the time.)

Very nice of you, but, alas, I have no way to reliably reproduce it now.

> calendar-cursor-to-visible-date is an autoloaded function, so what's
> happening is that Emacs is trying to load the cal-move file -- and
> looking into "/scp:remote:/path/Contents/Resources/site-lisp/".
>
> Can something have put that in your load-path by any chance?

I don't think so.

I suspect that this is a part of the pattern I still observe when tramp
paths seep into `default-directory' in irrelevant buffers.

Basically, if I create a non-file buffer `*NFB*' (e.g., by calling
`list-packages' or `gnus') while inside a tramp buffer, the buffer `*NFB*'
inherits `default-directory' from the tramp buffer (unless a special
action is taken, like by `gnus'!) so when a future action involving disk
access is initiated from `*NFB*' (e.g., when `midnight-hook' autoloads
something), the file system local to `*NFB*' is checked first (because
`.' is a part of `load-path' so it is resolved against the tramp
`default-directory').

Maybe a solution is to _never_ inherit `default-directory' unless
there is a _reason_ for that.  E.g., `*vc-diff*' should not inherit
`default-directory' from `*vc*' implicitly, but by an explicit action.
However, this will break so much existing code that you wouldn't even
consider that.
On the other hand, "explicitly non-file" modes (like, e.g., `*Custom*'
or `*Help*') should probably reset `default-directory'.

I now evaluate this

--8<---------------cut here---------------start------------->8---
(dolist (b (buffer-list))
  (with-current-buffer b
    (when (and (null buffer-file-name)
               (not (eq major-mode 'dired-mode))
               (not (string-match " ?\\*.*\\(tramp\\|vc\\|diff\\)" (buffer-name)))
               (tramp-tramp-file-p default-directory))
      (message "Reset 'default-directory' in %s(%s) from %s"
               b (or buffer-file-name list-buffers-directory) default-directory)
      (setq default-directory (default-value 'default-directory))
      )))
--8<---------------cut here---------------end--------------->8---

whenever I have any trouble with tramp, and, e.g., today I saw

--8<---------------cut here---------------start------------->8---
Reset ’default-directory’ in  *Minibuf-1*(nil) from /scp:remote:/home/sds/
Reset ’default-directory’ in *Custom Themes*(nil) from /scp:remote:/home/sds/
Reset ’default-directory’ in  *eldoc for line-move-visual*(nil) from /scp:remote:/home/sds/
--8<---------------cut here---------------end--------------->8---

Thank you very much for your attention.

-- 
Sam Steingold (https://aphar.dreamwidth.org/) on darwin Ns 10.3.2113
https://lastingimpactpsychology.com https://steingoldpsychology.com
https://ffii.org https://thereligionofpeace.com http://think-israel.org
Please express your antipathy in the suicidal form.

bug#50187: 28.0.50; tramp is called from calendar

[Michael Heerdegen]

Sam Steingold <sds@gnu.org> writes:

> > calendar-cursor-to-visible-date is an autoloaded function, so what's
> > happening is that Emacs is trying to load the cal-move file -- and
> > looking into "/scp:remote:/path/Contents/Resources/site-lisp/".
> >
> > Can something have put that in your load-path by any chance?
>
> I don't think so.
>
> I suspect that this is a part of the pattern I still observe when tramp
> paths seep into `default-directory' in irrelevant buffers.

If you had `nil' in your `load-path' - that stands for the
`default-directory'.

Michael.

bug#50187: 28.0.50; tramp is called from calendar

[Michael Heerdegen]

Sam Steingold <sds@gnu.org> writes:

> (because `.' is a part of `load-path'

Ok, but it's not there by default, right?

> so it is resolved against the tramp `default-directory').
>
> Maybe a solution is to _never_ inherit `default-directory' unless
> there is a _reason_ for that.  E.g., `*vc-diff*' should not inherit
> `default-directory' from `*vc*' implicitly, but by an explicit action.
> However, this will break so much existing code that you wouldn't even
> consider that.
> On the other hand, "explicitly non-file" modes (like, e.g., `*Custom*'
> or `*Help*') should probably reset `default-directory'.

What you suggest would at least partly reverse the effect of having
default-directory in load-path.  Maybe you should just remove it?

Michael.

bug#50187: 28.0.50; tramp is called from calendar

[Sam Steingold]

> * Michael Heerdegen <zvpunry_urreqrtra@jro.qr> [2022-08-23 04:18:23 +0200]:
>
>
> Sam Steingold <sds@gnu.org> writes:
>
>> (because `.' is a part of `load-path'
>
> Ok, but it's not there by default, right?

I have no idea why it was there (it is not there now!)
I am not even sure if it was there then.
My only point is that disk access triggered from a buffer with a tramp
`default-directory' results in tramp being activated and trying to
touch the remote.
Dunno why.
My theory was `load-path', looks like I was wrong.


-- 
Sam Steingold (https://aphar.dreamwidth.org) on Pop 22.04 (jammy) X 11.0.12101003
http://childpsy.net http://calmchildstories.com http://steingoldpsychology.com
https://www.memritv.org https://www.peaceandtolerance.org/
I haven't lost my mind -- it's backed up on tape somewhere.

bug#50187: 28.0.50; tramp is called from calendar

[Michael Heerdegen]

Sam Steingold <sds@gnu.org> writes:

> >> (because `.' is a part of `load-path'
> >
> > Ok, but it's not there by default, right?
>
> I have no idea why it was there (it is not there now!)
> I am not even sure if it was there then.
> My only point is that disk access triggered from a buffer with a tramp
> `default-directory' results in tramp being activated and trying to
> touch the remote.
> Dunno why.
> My theory was `load-path', looks like I was wrong.

Not really: your backtrace very much looks like the function
`calendar-cursor-to-visible-date' was autoloaded.  Autoloads don't
contain complete paths, they only contain relative file names.  So the
`load-path' is searched, and if "." or nil is at the beginning, the
default-directory is searched first.  Else the standard file would have
been found before default-directory is touched.  Quite plausible that
this is what you saw.

Michael.

bug#50187: 28.0.50; tramp is called from calendar

[Sam Steingold]

At any rate, I never add either "." or nil to `load-path`.

On Mon, 22 Aug 2022 at 23:25, Michael Heerdegen
<michael_heerdegen@web.de> wrote:
> Not really: your backtrace very much looks like the function
> `calendar-cursor-to-visible-date' was autoloaded.  Autoloads don't
> contain complete paths, they only contain relative file names.  So the
> `load-path' is searched, and if "." or nil is at the beginning, the
> default-directory is searched first.  Else the standard file would have
> been found before default-directory is touched.  Quite plausible that
> this is what you saw.

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

bug#50187: 28.0.50; tramp is called from calendar

[Michael Heerdegen]

Sam Steingold <sds@gnu.org> writes:

> At any rate, I never add either "." or nil to `load-path`.

There are multiple ways why such an entry could have been added there -
it must not even have been you.

But if the load-path theory is wrong, I have no clue what was going on
without a reproducer.  The backtrace seems to clearly hint at
autoloading going on.

Michael.

bug#50187: 28.0.50; tramp is called from calendar

[Michael Albinus]

Lars Ingebrigtsen <larsi@gnus.org> writes:

Hi Lars,

>> I get this trace:
>>
>>   tramp-file-name-handler(file-readable-p "/scp:remote:/path/Contents/Resources/site-lisp/cal-move.so")
>>   calendar-cursor-to-visible-date((8 24 2021))
>>   calendar-generate-window(8 2021)
>>   calendar-basic-setup(nil)
>>   calendar()
>>   run-hooks(midnight-hook)
>>   apply(run-hooks midnight-hook)
>>   timer-event-handler([t 24869 56416 388128 86400 run-hooks (midnight-hook) nil 0])
>
> (I'm going through old bug reports that unfortunately weren't resolved
> at the time.)
>
> calendar-cursor-to-visible-date is an autoloaded function, so what's
> happening is that Emacs is trying to load the cal-move file -- and
> looking into "/scp:remote:/path/Contents/Resources/site-lisp/".
>
> Can something have put that in your load-path by any chance?

I don't believe it is a load-path issue. calendar-cursor-to-visible-date
is declared in cal-loaddefs.el (it has the ;;;###cal-autoload cookie),
and this loaddefs file is loaded when loading calendar.el.

That has been finished already, when calendar-basic-setup is applied.

The question is rather: what is cal-move.so, and how and why is it
checked for readability? In the directory emacs/lisp/calendar I cannot
find any use of this file.

Best regards, Michael.

bug#50187: 28.0.50; tramp is called from calendar

[Lars Ingebrigtsen]

Michael Albinus <michael.albinus@gmx.de> writes:

> I don't believe it is a load-path issue. calendar-cursor-to-visible-date
> is declared in cal-loaddefs.el (it has the ;;;###cal-autoload cookie),
> and this loaddefs file is loaded when loading calendar.el.
>
> That has been finished already, when calendar-basic-setup is applied.

Yes, cal-loaddefs had been loaded.  

> The question is rather: what is cal-move.so, and how and why is it
> checked for readability? In the directory emacs/lisp/calendar I cannot
> find any use of this file.

The backtrace shows that Emacs was trying to load cal-move.so, and
that's presumably something that Emacs tries to do when resolving the
`autoload' definition of `calendar-cursor-to-visible-date', I think?
(If I remember correctly, Emacs looks for all of so/elc/el, if Emacs is
built with module support, when doing a `require'/`autoload' lookup.)

bug#50187: 28.0.50; tramp is called from calendar

[Michael Heerdegen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> The backtrace shows that Emacs was trying to load cal-move.so, and
> that's presumably something that Emacs tries to do when resolving the
> `autoload' definition of `calendar-cursor-to-visible-date', I think?
> (If I remember correctly, Emacs looks for all of so/elc/el, if Emacs is
> built with module support, when doing a `require'/`autoload' lookup.)

".so" is the first prefix in the return value of (get-load-suffixes) for
me - so it is tried first.

And we see in the backtrace that `calendar-basic-setup' is not done.
And why else should a call of `calendar-cursor-to-visible-date' directly
invoke tramp?  If an Elisp function would be involved, it would appear
in the backtrace.

Michael.

bug#50187: 28.0.50; tramp is called from calendar

[Lars Ingebrigtsen]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> And we see in the backtrace that `calendar-basic-setup' is not done.
> And why else should a call of `calendar-cursor-to-visible-date' directly
> invoke tramp?  If an Elisp function would be involved, it would appear
> in the backtrace.

I don't quite understand what you mean.

If you

(debug-on-entry 'tramp-file-name-handler)
(push "/ssh:host:/tmp/" load-path)

and then do something that will trigger an autoload, you get a backtrace
like that (depending on what it's autoloading):

  tramp-file-name-handler(expand-file-name "tramp" "/ssh:host:/tmp/")
  tramp-file-name-handler(expand-file-name "tramp" "/ssh:host:/tmp/")
  tramp-file-name-handler(expand-file-name "mule-util" "/ssh:host:/tmp/")
  truncate-string-to-width(#("<     Calendar     ? info / o other /
  calendar-string-spread((#("<" 0 1 (help-echo "mouse-1: previous m
  calendar-update-mode-line()
  calendar-mode()
  calendar-basic-setup(nil)
  calendar()
  eval((calendar) nil)

Here's it's calling truncate-string-to-width (which is autoloaded from
mule-utils).

bug#50187: 28.0.50; tramp is called from calendar

[Michael Heerdegen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

>   tramp-file-name-handler(expand-file-name "tramp" "/ssh:host:/tmp/")
>   tramp-file-name-handler(expand-file-name "tramp" "/ssh:host:/tmp/")
>   tramp-file-name-handler(expand-file-name "mule-util" "/ssh:host:/tmp/")
>   truncate-string-to-width(#("<     Calendar     ? info / o other /
>   calendar-string-spread((#("<" 0 1 (help-echo "mouse-1: previous m
>   calendar-update-mode-line()
>   calendar-mode()
>   calendar-basic-setup(nil)
>   calendar()
>   eval((calendar) nil)

Could be that the backtraces just show different moments in autoloading
progress.  AFAIK `tramp-file-name-handler' is called very often.  Maybe
there is also some caching mechanism involved or something like that and
the first `tramp-file-name-handler' call depends on what you did before
- I don't know.

The OP didn't tell us how he produced his backtrace (do you maybe
recall, Sam?).

Michael.

bug#50187: 28.0.50; tramp is called from calendar

[Sam Steingold]

> * Michael Heerdegen <zvpunry_urreqrtra@jro.qr> [2022-08-24 01:09:44 +0200]:
>
> The OP didn't tell us how he produced his backtrace (do you maybe
> recall, Sam?).

I have calendar in midnight-hook, so I came to this backtrace in the
morning.


-- 
Sam Steingold (https://aphar.dreamwidth.org/) on darwin Ns 10.3.2113
https://lastingimpactpsychology.com https://steingoldpsychology.com
http://think-israel.org https://ij.org/ https://www.peaceandtolerance.org/
Your mouse pad is incompatible with MS Windows - your HD will be reformatted.

bug#50187: 28.0.50; tramp is called from calendar

[Michael Heerdegen]

Sam Steingold <sds@gnu.org> writes:

> I have calendar in midnight-hook, so I came to this backtrace in the
> morning.

Yes thanks - but I wanted to know how you had obtained the backtrace,
that would help for the analysis.  M-x debug-on-entry [what function?],
or something else?  Can you maybe try to produce that backtrace again?

Michael.

bug#50187: 28.0.50; tramp is called from calendar

[Sam Steingold]

> * Michael Heerdegen <zvpunry_urreqrtra@jro.qr> [2022-09-13 04:14:24 +0200]:
>
> Sam Steingold <sds@gnu.org> writes:
>
>> I have calendar in midnight-hook, so I came to this backtrace in the
>> morning.
>
> Yes thanks - but I wanted to know how you had obtained the backtrace,
> that would help for the analysis.  M-x debug-on-entry [what function?],
> or something else?  Can you maybe try to produce that backtrace again?

I always run Emacs with `debug-on-error' set to t.
So `midnight-hook' runs `calendar', it errors out, and I see the
*Backtrace* first thing in the morning.

-- 
Sam Steingold (https://aphar.dreamwidth.org/) on darwin Ns 10.3.2113
https://lastingimpactpsychology.com https://steingoldpsychology.com
https://mideasttruth.com https://fairforall.org https://ij.org/
To be popular with ladies one has to be smart, handsome & rich. Or to be a cat.

bug#50187: 28.0.50; tramp is called from calendar

[Michael Heerdegen]

Sam Steingold <sds@gnu.org> writes:

> I always run Emacs with `debug-on-error' set to t.
> So `midnight-hook' runs `calendar', it errors out, and I see the
> *Backtrace* first thing in the morning.

I didn't know that you got an error.

And you can still reproduce the problem?  Then you could try to use the
calendar before midnight and see if that prevents that error at
midnight.  If it doesn't, my autoload theory would be wrong.

Michael.

bug#50187: 28.0.50; tramp is called from calendar

[Sam Steingold]

> * Michael Heerdegen <zvpunry_urreqrtra@jro.qr> [2022-09-14 04:54:36 +0200]:
>
> Sam Steingold <sds@gnu.org> writes:
>
>> I always run Emacs with `debug-on-error' set to t.
>> So `midnight-hook' runs `calendar', it errors out, and I see the
>> *Backtrace* first thing in the morning.
>
> I didn't know that you got an error.

Sorry, the original message was indeed unclear on that.

> And you can still reproduce the problem?

Alas, I have not seen this for quite some time.
I don't even recall _when_ the problem went away.
All I remember is that I saw it for a while, reported the bug, did
nothing specifically to correct the issue, and then it went away after
some time.

> Then you could try to use the calendar before midnight and see if that
> prevents that error at midnight.  If it doesn't, my autoload theory
> would be wrong.

I do use calendar regularly, but I have not seen this recently.

_However_, I just called calendar from a Tramp buffer and the *Calendar*
buffer's `default-directory' is a tramp directory.

I don't think this is right.

-- 
Sam Steingold (https://aphar.dreamwidth.org/) on darwin Ns 10.3.2113
https://lastingimpactpsychology.com https://steingoldpsychology.com
https://iris.org.il https://honestreporting.com https://jihadwatch.org
A good programmer: language change is easy, editor change is ... huh?!

bug#50187: 28.0.50; tramp is called from calendar

[Michael Heerdegen]

Sam Steingold <sds@gnu.org> writes:

> _However_, I just called calendar from a Tramp buffer and the *Calendar*
> buffer's `default-directory' is a tramp directory.
>
> I don't think this is right.

I think it's common behavior.  Does it cause trouble?

Michael.

bug#50187: 28.0.50; tramp is called from calendar

[Sam Steingold]

> * Michael Heerdegen <zvpunry_urreqrtra@jro.qr> [2022-09-15 12:36:00 +0200]:
>
> Sam Steingold <sds@gnu.org> writes:
>
>> _However_, I just called calendar from a Tramp buffer and the *Calendar*
>> buffer's `default-directory' is a tramp directory.
>>
>> I don't think this is right.
>
> I think it's common behavior.  Does it cause trouble?

Yes.

Local disk access is fast compared to Tramp (that may take forever and
then actually fail). Thus a simple C-x C-f from a buffer with a remote
`default-directory' can become a nightmare - before I even see the
prompt.

`default-directory' should be remote only when there is a definite
reason for that (IOW, for remote files and directories),
it should not be inherited by non-file buffers at random.

Thank you!

-- 
Sam Steingold (https://aphar.dreamwidth.org/) on darwin Ns 10.3.2113
https://lastingimpactpsychology.com https://steingoldpsychology.com
https://ij.org/ https://honestreporting.com https://www.peaceandtolerance.org/
Diplomacy is the art of saying "nice doggy" until you can find a nice rock.

bug#50187: 28.0.50; tramp is called from calendar

[Lars Ingebrigtsen]

Sam Steingold <sds@gnu.org> writes:

> `default-directory' should be remote only when there is a definite
> reason for that (IOW, for remote files and directories),
> it should not be inherited by non-file buffers at random.

It would be a break with how Emacs has worked for decades, so I don't
think that's something we could do in general.

I'm not even sure we could provide a user option for this -- if we're
not using the normal default directory here, which one should we choose
for `default-directory'?  "~/"?  "/"?

If starting calendar while in a Tramp buffer is problematic for you,
then I think the solution is to not do that, I'm afraid.

bug#50187: 28.0.50; tramp is called from calendar

[Michael Albinus]

Lars Ingebrigtsen <larsi@gnus.org> writes:

>> `default-directory' should be remote only when there is a definite
>> reason for that (IOW, for remote files and directories),
>> it should not be inherited by non-file buffers at random.
>
> It would be a break with how Emacs has worked for decades, so I don't
> think that's something we could do in general.
>
> I'm not even sure we could provide a user option for this -- if we're
> not using the normal default directory here, which one should we choose
> for `default-directory'?  "~/"?  "/"?

I agree.

> If starting calendar while in a Tramp buffer is problematic for you,
> then I think the solution is to not do that, I'm afraid.

If the problem is reproducible, we shall catch it. Set tramp-verbose to
10. Next morning, when the Tramp problem has appeared, the Tramp debug
buffer shall tell us what happened. Please show the buffer.

Best regards, Michael.

bug#50187: 28.0.50; tramp is called from calendar

[Gregory Heytings]

>
> If starting calendar while in a Tramp buffer is problematic for you, 
> then I think the solution is to not do that, I'm afraid.
>

Or to use this, for example:

(advice-add
  'calendar :around
  (lambda (fun &rest args)
    (let ((default-directory
 	  (if (file-remote-p default-directory)
 	      "~/"
 	    default-directory)))
      (apply fun args))))

bug#50187: 28.0.50; tramp is called from calendar

[Sam Steingold]

> * Lars Ingebrigtsen <ynefv@tahf.bet> [2022-09-16 11:41:48 +0200]:
>
> Sam Steingold <sds@gnu.org> writes:
>
>> `default-directory' should be remote only when there is a definite
>> reason for that (IOW, for remote files and directories),
>> it should not be inherited by non-file buffers at random.
>
> It would be a break with how Emacs has worked for decades, so I don't
> think that's something we could do in general.

;-(

> I'm not even sure we could provide a user option for this -- if we're
> not using the normal default directory here, which one should we choose
> for `default-directory'?  "~/"?  "/"?

(default-value 'default-directory)

> If starting calendar while in a Tramp buffer is problematic for you,
> then I think the solution is to not do that, I'm afraid.

1. calendar is not the only non-file-connected buffer
2. when calendar is called from midnight-hook, I cannot select which
buffer calendar starts in.

-- 
Sam Steingold (https://aphar.dreamwidth.org/) on darwin Ns 10.3.2113
https://lastingimpactpsychology.com https://steingoldpsychology.com
https://www.peaceandtolerance.org/ https://honestreporting.com
Isn't "Microsoft Works" an advertisement lie?

bug#50187: 28.0.50; tramp is called from calendar

[Michael Albinus]

Sam Steingold <sds@gnu.org> writes:

Hi Sam,

>> I'm not even sure we could provide a user option for this -- if we're
>> not using the normal default directory here, which one should we choose
>> for `default-directory'?  "~/"?  "/"?
>
> (default-value 'default-directory)

This is nil. `default-directory' has only buffer-local values.

>> If starting calendar while in a Tramp buffer is problematic for you,
>> then I think the solution is to not do that, I'm afraid.
>
> 1. calendar is not the only non-file-connected buffer

Sure. But we have catched similar errors in other packages already. And
fixed them.

> 2. when calendar is called from midnight-hook, I cannot select which
> buffer calendar starts in.

Yes. So let Tramp catch the traces, setting tramp-verbose to 10.

Best regards, Michael.

bug#50187: 28.0.50; tramp is called from calendar

[Sam Steingold]

> * Gregory Heytings <tertbel@urlgvatf.bet> [2022-09-16 10:04:57 +0000]:
>
>>
>> If starting calendar while in a Tramp buffer is problematic for you, then I
>> think the solution is to not do that, I'm afraid.
>>
>
> Or to use this, for example:
>
> (advice-add
>  'calendar :around
>  (lambda (fun &rest args)
>    (let ((default-directory
> 	  (if (file-remote-p default-directory)
> 	      "~/"
> 	    default-directory)))
>      (apply fun args))))

calendar is far from being the only problem.
I run this:

--8<---------------cut here---------------start------------->8---
(dolist (b (buffer-list))
  (with-current-buffer b
    (when (and (null buffer-file-name)
               (not (eq major-mode 'dired-mode))
               (not (string-match " ?\\*.*\\(tramp\\|vc\\|diff\\)" (buffer-name)))
               (find-file-name-handler default-directory 'file-remote-p))
      (message "Reset 'default-directory' in %s(%s) from %s"
               b (or buffer-file-name list-buffers-directory) default-directory)
      (setq default-directory (default-value 'default-directory))
      )))
--8<---------------cut here---------------end--------------->8---

every now and then.

-- 
Sam Steingold (https://aphar.dreamwidth.org/) on darwin Ns 10.3.2113
https://lastingimpactpsychology.com https://steingoldpsychology.com
https://jij.org https://www.memritv.org https://www.peaceandtolerance.org/
If at first you don't suck seed, try and suck another seed.

bug#50187: 28.0.50; tramp is called from calendar

[Michael Albinus]

Sam Steingold <sds@gnu.org> writes:

Hi Sam,

> (dolist (b (buffer-list))
>   (with-current-buffer b
>     (when (and (null buffer-file-name)
>                (not (eq major-mode 'dired-mode))
>                (not (string-match " ?\\*.*\\(tramp\\|vc\\|diff\\)" (buffer-name)))
>                (find-file-name-handler default-directory 'file-remote-p))
>       (message "Reset 'default-directory' in %s(%s) from %s"
>                b (or buffer-file-name list-buffers-directory) default-directory)
>       (setq default-directory (default-value 'default-directory))
>       )))

This works by sheer luck then. `default-directory' must not be nil; it
is fundamental that it is a string.

That code makes other packages useless for remote buffers, like shell or
compile. This cannot be the solution.

Best regards, Michael.

bug#50187: 28.0.50; tramp is called from calendar

[Gregory Heytings]

>
> calendar is far from being the only problem.
>

That wasn't clear from the bug title and the discussion.

>
> I run this:
>
> (dolist (b (buffer-list))
>  (with-current-buffer b
>    (when (and (null buffer-file-name)
>               (not (eq major-mode 'dired-mode))
>               (not (string-match " ?\\*.*\\(tramp\\|vc\\|diff\\)" (buffer-name)))
>               (find-file-name-handler default-directory 'file-remote-p))
>      (message "Reset 'default-directory' in %s(%s) from %s"
>               b (or buffer-file-name list-buffers-directory) default-directory)
>      (setq default-directory (default-value 'default-directory))
>      )))
>
> every now and then.
>

I think you can achieve a similar effect automatically, by adding a 
function in buffer-list-update-hook that does the above on the first 
element of buffer-list.  But as Michael said you should probably not use 
nil.

bug#50187: 28.0.50; tramp is called from calendar

[Sam Steingold]

> * Gregory Heytings <tertbel@urlgvatf.bet> [2022-09-16 15:02:04 +0000]:
>
>> calendar is far from being the only problem.
>
> That wasn't clear from the bug title and the discussion.

I am pretty sure I mentioned this a few time here and elsewhere but you
don't have to track my pet peeves ;-)

>>
>> I run this:
>>
>> (dolist (b (buffer-list))
>>  (with-current-buffer b
>>    (when (and (null buffer-file-name)
>>               (not (eq major-mode 'dired-mode))
>>               (not (string-match " ?\\*.*\\(tramp\\|vc\\|diff\\)" (buffer-name)))
>>               (find-file-name-handler default-directory 'file-remote-p))
>>      (message "Reset 'default-directory' in %s(%s) from %s"
>>               b (or buffer-file-name list-buffers-directory) default-directory)
>>      (setq default-directory (default-value 'default-directory))
>>      )))
>>
>> every now and then.
>>
>
> I think you can achieve a similar effect automatically, by adding a
> function in buffer-list-update-hook that does the above on the first
> element of buffer-list.

Wow, thanks Gregory, didn't even think about it.

1. This hook seems to be called far too often; but I do not see a
`create-buffer-hook' - any reason for that? (there is a
`kill-buffer-hook')

2. It appears that I can use (current-buffer) instead of (car
(buffer-list))


> But as Michael said you should probably not use nil.

I am not sure what you mean, could you please clarify?

-- 
Sam Steingold (https://aphar.dreamwidth.org/) on darwin Ns 10.3.2113
https://lastingimpactpsychology.com https://steingoldpsychology.com
https://www.dhimmitude.org https://jihadwatch.org https://camera.org
Time would have been the best Teacher, if it did not kill all its students.

bug#50187: 28.0.50; tramp is called from calendar

[Sam Steingold]

> * Sam Steingold <fqf@tah.bet> [2022-09-16 12:56:39 -0400]:
>
> Wow, thanks Gregory, didn't even think about it.

... mostly because I was still hoping for a fix in Emacs ;-(

-- 
Sam Steingold (https://aphar.dreamwidth.org/) on darwin Ns 10.3.2113
https://lastingimpactpsychology.com https://steingoldpsychology.com
https://fairforall.org https://honestreporting.com https://jihadwatch.org
Three can keep a secret if two of them are dead.

bug#50187: 28.0.50; tramp is called from calendar

[Gregory Heytings]

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


>
> 1. This hook seems to be called far too often; but I do not see a 
> `create-buffer-hook' - any reason for that? (there is a 
> `kill-buffer-hook')
>

It's not clear when such a hook would have to run I think.

>
> 2. It appears that I can use (current-buffer) instead of (car 
> (buffer-list))
>

Yes, that's another possibility indeed.

>> But as Michael said you should probably not use nil.
>
> I am not sure what you mean, could you please clarify?
>

The docstring says "it should be an absolute directory name", and nil is 
not an absolute directory name 😉

>
> ... mostly because I was still hoping for a fix in Emacs ;-(
>

It's not clear to me what the "fix" would be here, can you explain what 
you have in mind?

bug#50187: 28.0.50; tramp is called from calendar

[Eli Zaretskii]

> Cc: 50187@debbugs.gnu.org
> From: Sam Steingold <sds@gnu.org>
> Date: Fri, 16 Sep 2022 13:13:50 -0400
> 
> > * Sam Steingold <fqf@tah.bet> [2022-09-16 12:56:39 -0400]:
> >
> > Wow, thanks Gregory, didn't even think about it.
> 
> ... mostly because I was still hoping for a fix in Emacs ;-(

I thought Michael asked for additional data to be collected, so he
could look into this issue?

bug#50187: 28.0.50; tramp is called from calendar

[Sam Steingold]

> * Gregory Heytings <tertbel@urlgvatf.bet> [2022-09-16 17:26:45 +0000]:
>
>>> But as Michael said you should probably not use nil.
>>
>> I am not sure what you mean, could you please clarify?
>>
>
> The docstring says "it should be an absolute directory name", and nil
> is not an absolute directory name 😉

Ah, right, the initial global value of `default-directory' is nil, but I do

(setq-default default-directory (expand-file-name "~/"))

>> ... mostly because I was still hoping for a fix in Emacs ;-(
>
> It's not clear to me what the "fix" would be here, can you explain
> what you have in mind?

1. `default-directory' should have a global default, see above
2. new buffers should inherit `default-directory' from the global
default instead of the previous buffer from which this one was created.

Thank you!

-- 
Sam Steingold (https://aphar.dreamwidth.org/) on darwin Ns 10.3.2113
https://lastingimpactpsychology.com https://steingoldpsychology.com
https://ffii.org https://jihadwatch.org http://think-israel.org
The more project management you do, the less likely your project is to succeed.

bug#50187: 28.0.50; tramp is called from calendar

[Michael Albinus]

Sam Steingold <sds@gnu.org> writes:

Hi Sam,

> 1. `default-directory' should have a global default, see above

It has. It is nil, and there's nothing wrong with it.

> 2. new buffers should inherit `default-directory' from the global
> default instead of the previous buffer from which this one was created.

No. This would break many packages.

Show us the Tramp traces if calendar is called from a remote buffer. We
might be able to fix it.

> Thank you!

Best regards, Michael.

bug#50187: 28.0.50; tramp is called from calendar

[Eli Zaretskii]

> Cc: Michael Heerdegen <michael_heerdegen@web.de>, 50187@debbugs.gnu.org,
>  Lars Ingebrigtsen <larsi@gnus.org>, Michael Albinus <michael.albinus@gmx.de>
> From: Sam Steingold <sds@gnu.org>
> Date: Fri, 16 Sep 2022 14:45:25 -0400
> 
> (setq-default default-directory (expand-file-name "~/"))
> 
> >> ... mostly because I was still hoping for a fix in Emacs ;-(
> >
> > It's not clear to me what the "fix" would be here, can you explain
> > what you have in mind?
> 
> 1. `default-directory' should have a global default, see above

But using "~/" as that default is IMO wrong, as it contradicts what
expand-file-name does when default-directory is nil: it uses "/" on
Posix systems and the root of the Emacs installation on MS-Windows.
If we want default-directory to have a global default (and I'm not yet
convinced that it's a good idea), we should at least use the same
value as expand-file-name does, otherwise we'll have bugs.

> 2. new buffers should inherit `default-directory' from the global
> default instead of the previous buffer from which this one was created.

I question the validity of this assertion.  It seems to be based on a
particular class of use cases, while its effect is over-reaching.
Consider, for example, the frequent paradigm of using
with-temp-buffer.

bug#50187: 28.0.50; tramp is called from calendar

[Gregory Heytings]

>> It's not clear to me what the "fix" would be here, can you explain what 
>> you have in mind?
>
> 1. `default-directory' should have a global default, see above
>
> 2. new buffers should inherit `default-directory' from the global 
> default instead of the previous buffer from which this one was created.
>

That fix would break *lots* of code.  There's a good reason that the 
default value of non-file-visiting buffers is inherited from that of the 
buffer from which they were created: it is, in most cases, the 
default-directory value that is expected and useful in that buffer. 
Think of cases like occur, grep, compilation, diff, dired, and so forth. 
It is much better to manually fix the few cases in which you do not want 
to inherit its value.

What would perhaps be feasible would be to add a variable similar to 
display-buffer-alist: an alist of user-defined conditional values for 
default-directory.

bug#50187: 28.0.50; tramp is called from calendar

[Sam Steingold]

> * Gregory Heytings <tertbel@urlgvatf.bet> [2022-09-16 19:30:28 +0000]:
>
>>> It's not clear to me what the "fix" would be here, can you explain what you
>>> have in mind?
>>
>> 1. `default-directory' should have a global default, see above
>>
>> 2. new buffers should inherit `default-directory' from the global default
>> instead of the previous buffer from which this one was created.
>
> That fix would break *lots* of code.

;-(


> Think of cases like occur, grep, compilation, diff, dired, and so
> forth. It is much better to manually fix the few cases in which you do
> not want to inherit its value.

I admit that I was sloppy in my second point.
I should have said that each emacs buffer has a natural "parent".
E.g., the initial *scratch* is like init(1), and the rest either has it
as the parent (e.g., gnus, calendar, list-packages, list-buffers) and
the rest have the parent the buffer from which it was created (like
occur, diff, and other examples you have).
It makes perfect sense for *occur* to inherit `default-directory', and
no sense for calendar.

> What would perhaps be feasible would be to add a variable similar to
> display-buffer-alist: an alist of user-defined conditional values for
> default-directory.

I would do this somewhat differently.

You are right that we have a long standing assumption that a new buffer
inherits `default-directory' from the "previous buffer" and we will
probably have to keep that.

However, we also did not have `quit-window' and `special-mode' until
relatively recently in Emacs history.
I suggest a solution similar to those.

Specifically, define a function `disinherit' (and add `disinherit'
optional argument to `get-buffer-create' et al) that would reset
`default-directory' et al to the "root" value (whatever the value would
be in *scratch* for `emacs -Q`) for the newly created buffer.

Then encourage developers to use disinherit in things like games,
calendar &c &c &c.

Thank you.

-- 
Sam Steingold (https://aphar.dreamwidth.org/) on darwin Ns 10.3.2113
https://lastingimpactpsychology.com https://steingoldpsychology.com
https://ffii.org https://camera.org https://fairforall.org
Sometimes "pain in the ass" and "headache" are synonyms.

bug#50187: 28.0.50; tramp is called from calendar

[Eli Zaretskii]

> Cc: Michael Heerdegen <michael_heerdegen@web.de>, 50187@debbugs.gnu.org,
>  Lars Ingebrigtsen <larsi@gnus.org>, Michael Albinus <michael.albinus@gmx.de>
> From: Sam Steingold <sds@gnu.org>
> Date: Fri, 16 Sep 2022 17:43:17 -0400
> 
> It makes perfect sense for *occur* to inherit `default-directory', and
> no sense for calendar.

Then "M-x calendar" should take care of setting the default-directory
of its buffer.  It cannot be done by the infrastructure, because in
many cases when a buffer is created, Emacs doesn't yet know its future
purpose.

But we are arguing about issues that might be purely academic.
Michael asked you to collect some Tramp-related data, so he could look
into what happens in this particular case.  Please provide him the
data he asked for: it could very well lead to a simple and
uncontroversial solution.

> Specifically, define a function `disinherit' (and add `disinherit'
> optional argument to `get-buffer-create' et al) that would reset
> `default-directory' et al to the "root" value (whatever the value would
> be in *scratch* for `emacs -Q`) for the newly created buffer.

The default-directory of *scratch* is the directory where you start
Emacs, so it's not a fixed directory, and I don't see how it can serve
the model for anything referenced in this discussion.

bug#50187: 28.0.50; tramp is called from calendar

[Michael Albinus]

Sam Steingold <sds@gnu.org> writes:

Hi Sam,

> Specifically, define a function `disinherit' (and add `disinherit'
> optional argument to `get-buffer-create' et al) that would reset
> `default-directory' et al to the "root" value (whatever the value would
> be in *scratch* for `emacs -Q`) for the newly created buffer.
>
> Then encourage developers to use disinherit in things like games,
> calendar &c &c &c.

The usual approach in packages, which do not want to be offended by a
remote default-directory, shall be

--8<---------------cut here---------------start------------->8---
(let ((default-directory temporary-file-directory))
   ...)
--8<---------------cut here---------------end--------------->8---

But it is up to the package to do so in its implementation.

> Thank you.

Best regards, Michael.

bug#50187: 28.0.50; tramp is called from calendar

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

>> Cc: Michael Heerdegen <michael_heerdegen@web.de>, 50187@debbugs.gnu.org,
>>  Lars Ingebrigtsen <larsi@gnus.org>, Michael Albinus <michael.albinus@gmx.de>
>> From: Sam Steingold <sds@gnu.org>
>> Date: Fri, 16 Sep 2022 17:43:17 -0400
>>
>> It makes perfect sense for *occur* to inherit `default-directory', and
>> no sense for calendar.
>
> Then "M-x calendar" should take care of setting the default-directory
> of its buffer.  It cannot be done by the infrastructure, because in
> many cases when a buffer is created, Emacs doesn't yet know its future
> purpose.
>
> But we are arguing about issues that might be purely academic.
> Michael asked you to collect some Tramp-related data, so he could look
> into what happens in this particular case.  Please provide him the
> data he asked for: it could very well lead to a simple and
> uncontroversial solution.

We seem to need more information here to make any progress.  Without
that information, I don't think it makes sense to keep this bug open.

Sam, could you please try to collect the information that Michael has
asked for?  Thanks in advance.

bug#50187: 28.0.50; tramp is called from calendar

[Stefan Kangas]

Stefan Kangas <stefankangas@gmail.com> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> Cc: Michael Heerdegen <michael_heerdegen@web.de>, 50187@debbugs.gnu.org,
>>>  Lars Ingebrigtsen <larsi@gnus.org>, Michael Albinus <michael.albinus@gmx.de>
>>> From: Sam Steingold <sds@gnu.org>
>>> Date: Fri, 16 Sep 2022 17:43:17 -0400
>>>
>>> It makes perfect sense for *occur* to inherit `default-directory', and
>>> no sense for calendar.
>>
>> Then "M-x calendar" should take care of setting the default-directory
>> of its buffer.  It cannot be done by the infrastructure, because in
>> many cases when a buffer is created, Emacs doesn't yet know its future
>> purpose.
>>
>> But we are arguing about issues that might be purely academic.
>> Michael asked you to collect some Tramp-related data, so he could look
>> into what happens in this particular case.  Please provide him the
>> data he asked for: it could very well lead to a simple and
>> uncontroversial solution.
>
> We seem to need more information here to make any progress.  Without
> that information, I don't think it makes sense to keep this bug open.
>
> Sam, could you please try to collect the information that Michael has
> asked for?  Thanks in advance.

More information was requested, but none was given within 4 months, so
I'm closing this bug.

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