tramp-devel
[Top][All Lists]
Advanced

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

Re: tramp (2.2.6-pre); Bad interaction with session.el


From: Michael Albinus
Subject: Re: tramp (2.2.6-pre); Bad interaction with session.el
Date: Tue, 16 Oct 2012 08:42:19 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1.50 (gnu/linux)

Dave Abrahams <address@hidden> writes:

Hi Dave,

> I long since cleaned up all the buffers and connections, but session
> remembers which files I had open, and now clicking in my menu bar
> actually tries to re-establish a connnection.  It's nasty to have
> Emacs lock up on me just because I tried to use the menu.

I don't know whether Tramp is the right place to complain. session.el
does not belong to the Emacs tree; Tramp cannot know it.

If I understand the trace correctly, Tramp tries to open the following
file:

>   tramp-sh-handle-expand-file-name("/sudo:90-plugin.conf" nil)

This does not work, because "sudo" is not a valid host name. Tramp tries
to open that file, because it is said so by:

>   get-file-buffer("/sudo:90-plugin.conf")

[...]

>   session-file-changed-menu-filter((["Move File Names Of All Buffers To Top" 
> session-file-opened-recompute] "---") 
> ("~/.emacs.d/el-get/tramp/share/emacs/site-lisp/" 
> "~/.emacs.d/el-get/tramp/share/emacs/site-lisp/tramp.el" 
> "~/.emacs.d/el-get/tramp/share/emacs/site-lisp/tramp-cmds.el" 
> "~/src/ryppl/feeds/ryppl/ryppl.xml" "~/Notes/modules.org" 
> "~/Notes/modules.org" "~/Documents/C++/2012-09/notes.org" 
> "/sudo:address@hidden:/etc/postfix/main.cf" "/sudo::/etc/postfix/main.cf" 
> "~/.emacs.d/el-get/nognus/lisp/gnus-agent.el" 
> "~/.emacs.d/el-get/nognus/lisp/message.el" 
> "/sudo:address@hidden:/opt/local/etc/pdnsd/pdnsd.conf" 
> "/sudo::/opt/local/etc/pdnsd/pdnsd.conf" 
> "/sudo:address@hidden:/usr/local/etc/dovecot/conf.d/10-mail.conf" 
> "/sudo::/usr/local/etc/dovecot/conf.d/10-mail.conf" 
> "/usr/local/etc/dovecot/conf.d/sudo::/usr/local/etc/dovecot/conf.d/10-mail.conf"
>  "sudo::/usr/local/etc/dovecot/conf.d/10-mail.conf" 
> "/sudo:address@hidden:/usr/local/etc/dovecot/conf.d/90-plugin.conf" 
> "/sudo::/usr/local/etc/dovecot/conf.d/90-plugin.conf" 
> "/sudo:/usr/local/etc/dovecot/conf.d/90-plugin.conf" "/sudo:90-plugin.conf" 
> "/usr/local/etc/dovecot/conf.d/90-plugin.conf" 
> "/usr/local/etc/dovecot/conf.d/10-mail.conf" "/usr/local/etc/dovecot/" 
> "~/.emacs.d/el-get/nognus/lisp/nnir.el" 
> "~/.emacs.d/el-get/nognus/lisp/nnimap.el" "~/Documents/C++/2012-09/notes.org" 
> "~/Documents/C++/2012-09" "~/.emacs.d/el-get/org-mode/lisp/org.el" 
> "~/.emacs.d/el-get/dwamacs/settings/settings.el"))
>   session-file-opened-menu-filter((["Move File Names Of All Buffers To Top" 
> session-file-opened-recompute] "---"))
>   (easy-menu-filter-return (session-file-opened-menu-filter menu) 
> "Open...Recently Visited")
>   (lambda (menu) (easy-menu-filter-return (session-file-opened-menu-filter 
> menu) "Open...Recently Visited"))((["Move File Names Of All Buffers To Top" 
> session-file-opened-recompute] "---"))

I don't know, where `session-file-changed-menu-filter' gets its list of
file names from. However, session.el contains hooks, including
`session-kill-buffer-hook' and friends. They should cleanup file lists
properly, I believe.

I don't know the functionality of session.el, it might be worth to ask
the maintainer what's going on. Please keep me on Cc; I could answer
Tramp specific questions.

Note that `tramp-cleanup-all-connections' does not kill buffers
belonging to remote files. This is done by `tramp-cleanup-all-buffers'.

A wild guess is that you have opened "/sudo:90-plugin.conf" by accident,
and you have fixed this by `tramp-cleanup-all-connections'. Therefore,
the corresponding buffer has not been killed, and "/sudo:90-plugin.conf"
is still contained in session's internal file name list, which has
survived an Emacs restart. In that case I would recommend, that
session.el takes special care on remote file names, and does not open them
blindly. See `recentf-keep' in recentf.el, which handles a similar problem.

Best regards, Michael.



reply via email to

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