[david.reitter@gmail.com: file-remote-p malfunctions at site-start (file-name-handler-alist init)]

[david.reitter@gmail.com: file-remote-p malfunctions at site-start (file-name-handler-alist init)]

[Richard Stallman]

Would someone please DTRT and ack?

------- Start of forwarded message -------
X-Spam-Status: No, score=0.0 required=5.0 tests=UNPARSEABLE_RELAY 
	autolearn=failed version=3.1.0
DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta;
	h=domainkey-signature:received:received:mime-version:content-transfer-encoding:message-id:content-type:to:from:subject:date:x-mailer;
	b=s7BXyK+4GhOwW5H7jKdX9z5Vz4neRHIL2YqUkZgGtU6dWuhYC6BcFujLBLTrEPa09HRu0Di1NCR+jtLHuvR4f9wY8gC61A0libpAcUGY0k3ZK74H15WvMZn8c8NIzrWp3RcglmnIRhACDhqT0m5q3Y7doc4c2PboX/AjM3A+Cdw=
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
To: emacs-pretest-bug@gnu.org
From: David Reitter <david.reitter@gmail.com>
Date: Fri, 23 Mar 2007 21:53:59 +0000
Subject: file-remote-p malfunctions at site-start (file-name-handler-alist
	init)

If a site-start.el file is created with the following contents:

(print file-name-handler-alist)
(print (file-remote-p "/ssh:dreitter@ssh:/home/dreitter/test2"))

the output of the last expression is nil for me.
It should (correctly) be non-nil.


The reason for that is that `file-name-handler-alist' does not  
contain handlers for tramp file names when the site-start file is  
loaded - at a later point, the appropriate handlers are added.

The practical relevance is that when users (or site or distribution  
admins) load and turn on recentf-mode from a site-start file together  
with a `file-remote-p' predicate in `recentf-keep', then all recent- 
file entries containing a tramp path will be purged. That's very  
inconvenient.

The problem would go away if `file-name-handler-alist' was correctly  
initialized before site-start files are executed. Additionally,  
please consider defining the handler function for tramp files  
somewhere outside of tramp so that `file-remote-p' doesn't cause  
tramp to load just because it is checked for some file.





If Emacs crashed, and you have the Emacs process in the gdb debugger,
please include the output from the following gdb commands:
     `bt full' and `xbacktrace'.
If you would like to further debug the crash, please read the file
/Applications/Emacs.app/Contents/Resources/etc/DEBUG for instructions.


In GNU Emacs 22.0.96.1 (powerpc-apple-darwin7.9.0, Carbon Version 1.6.0)
of 2007-03-22 on rodrigues.inf.ed.ac.uk
Windowing system distributor `Apple Inc.', version 10.4.9
configured using `configure  '--without-x' '--prefix=/usr/local''

Important settings:
   value of $LC_ALL: nil
   value of $LC_COLLATE: nil
   value of $LC_CTYPE: nil
   value of $LC_MESSAGES: nil
   value of $LC_MONETARY: nil
   value of $LC_NUMERIC: nil
   value of $LC_TIME: nil
   value of $LANG: nil
   locale-coding-system: iso-8859-1
   default-enable-multibyte-characters: t

Major mode: Lisp Interaction

Minor modes in effect:
   encoded-kbd-mode: t
   tooltip-mode: t
   tool-bar-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
   unify-8859-on-encoding-mode: t
   utf-translate-cjk-mode: t
   auto-compression-mode: t
   line-number-mode: t

Recent input:
<down-mouse-1> <mouse-1> <help-echo> <help-echo> <help-echo>
<menu-bar> <help-menu> <report-emacs-bug>

Recent messages:

(("\\.Z\\(~\\|\\.~[0-9]+~\\)?\\'\\|\\.bz2\\(~\\|\\.~[0-9]+~\\)?\\'\\|\ 
\.tbz\\'\\|\\.tgz\\'\\|\\.g?z\\(~\\|\\.~[0-9]+~\\)?\\'\\|\\.dz\\'" .  
jka-compr-handler) ("\\`/:" . file-name-non-special))

nil

For information about the GNU Project and its goals, type C-h C-p. [2  
times]
Loading emacsbug...
Loading regexp-opt...done
Loading emacsbug...done
Loading encoded-kb...done



_______________________________________________
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
------- End of forwarded message -------

Re: [david.reitter@gmail.com: file-remote-p malfunctions at site-start (file-name-handler-alist init)]

[Chong Yidong]

> If a site-start.el file is created with the following contents:
>
> (print file-name-handler-alist)
> (print (file-remote-p "/ssh:dreitter@ssh:/home/dreitter/test2"))
>
> the output of the last expression is nil for me.
> It should (correctly) be non-nil.
>
> The reason for that is that `file-name-handler-alist' does not
> contain handlers for tramp file names when the site-start file is
> loaded - at a later point, the appropriate handlers are added.

This could conceivably be achieved by moving
tramp-register-file-name-handlers from after-init-hook to
before-init-hook.  On the other hand, the risk of making a change to
the init sequence at this stage probably outweighs the marginal
benefit; I don't think the above is a very common scenario.

What do people think?

Re: [david.reitter@gmail.com: file-remote-p malfunctions at site-start (file-name-handler-alist init)]

[Stefan Monnier]

> This could conceivably be achieved by moving
> tramp-register-file-name-handlers from after-init-hook to
> before-init-hook.

Why is it done so late?  Why not do it at dump time?


        Stefan

Re: [david.reitter@gmail.com: file-remote-p malfunctions at site-start (file-name-handler-alist init)]

[Michael Albinus]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> This could conceivably be achieved by moving
>> tramp-register-file-name-handlers from after-init-hook to
>> before-init-hook.
>
> Why is it done so late?  Why not do it at dump time?

It was there initially. Then it was changed, because people didn't
want to get Tramp enabled mandatory for file name completion. Now the
registration is done only in case `partial-completion-mode' is
active, which must be checked. The comment in the code says

;; During autoload, it shall be checked whether
;; `partial-completion-mode' is active.  Therefore registering will be
;; delayed.

See also <http://lists.gnu.org/archive/html/emacs-devel/2006-05/msg00017.html>

>         Stefan

Best regards, Michael.

Re: [david.reitter@gmail.com: file-remote-p malfunctions at site-start (file-name-handler-alist init)]

[Chong Yidong]

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

>>> This could conceivably be achieved by moving
>>> tramp-register-file-name-handlers from after-init-hook to
>>> before-init-hook.
>>
>> Why is it done so late?  Why not do it at dump time?
>
> It was there initially. Then it was changed, because people didn't
> want to get Tramp enabled mandatory for file name completion. Now the
> registration is done only in case `partial-completion-mode' is
> active, which must be checked.

In that case, I suggest documenting this in PROBLEMS: if you want to
use Tramp in your site-start file, run tramp-register-file-name-handlers
first (and remove it from after-init-hook).

Re: [david.reitter@gmail.com: file-remote-p malfunctions at site-start (file-name-handler-alist init)]

[Michael Albinus]

Chong Yidong <cyd@stupidchicken.com> writes:

>> It was there initially. Then it was changed, because people didn't
>> want to get Tramp enabled mandatory for file name completion. Now the
>> registration is done only in case `partial-completion-mode' is
>> active, which must be checked.
>
> In that case, I suggest documenting this in PROBLEMS: if you want to
> use Tramp in your site-start file, run tramp-register-file-name-handlers
> first (and remove it from after-init-hook).

I haven't a better idea. Maybe one should argue that it isn't a good
idea to access remote files in site-init files.

Note that removing tramp-register-file-name-handlers from
after-init-hook is not necessary, the registration is re-entrant.

OTOH, the OP gave as practical example recentf-mode problems with
remote files (handled in site-init). It would require changes in
recentf at least.

Best regards, Michael.

Re: [david.reitter@gmail.com: file-remote-p malfunctions at site-start (file-name-handler-alist init)]

[Stefan Monnier]

> Note that removing tramp-register-file-name-handlers from
> after-init-hook is not necessary, the registration is re-entrant.
                                                        ^^^^^^^^^^
                                                        idempotent

> OTOH, the OP gave as practical example recentf-mode problems with
> remote files (handled in site-init).  It would require changes in
> recentf at least.

It looks like we can't do much about it at this stage.
We should probably leave it as is for Emacs-22 and improve it afterwards.
How to improve it should probably look like:
1 - register Tramp at dump time.
2 - make sure that registering does not cause Tramp to be loaded.
3 - when completion is requested, Tramp is not loaded, and the config says
    that completion should obey Tramp (e.g. because partial-completion-mode
    is ON), then load Tramp.


-- Stefan

Re: [david.reitter@gmail.com: file-remote-p malfunctions at site-start (file-name-handler-alist init)]

[Chong Yidong]

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

>> In that case, I suggest documenting this in PROBLEMS: if you want to
>> use Tramp in your site-start file, run tramp-register-file-name-handlers
>> first (and remove it from after-init-hook).
>
> I haven't a better idea. Maybe one should argue that it isn't a good
> idea to access remote files in site-init files.

OK, I documented it in PROBLEMS.

Re: [david.reitter@gmail.com: file-remote-p malfunctions at site-start (file-name-handler-alist init)]

[Michael Albinus]

Chong Yidong <cyd@stupidchicken.com> writes:

> Michael Albinus <michael.albinus@gmx.de> writes:
>
>> I haven't a better idea. Maybe one should argue that it isn't a good
>> idea to access remote files in site-init files.
>
> OK, I documented it in PROBLEMS.

Finally, I've divided `tramp-register-file-name-handlers' into two
parts, which are evaluated at different startup places. This should
solve the problem.

Best regards, Michael.

Re: [david.reitter@gmail.com: file-remote-p malfunctions at site-start (file-name-handler-alist init)]

[David Kastrup]

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

> Chong Yidong <cyd@stupidchicken.com> writes:
>
>> Michael Albinus <michael.albinus@gmx.de> writes:
>>
>>> I haven't a better idea. Maybe one should argue that it isn't a good
>>> idea to access remote files in site-init files.
>>
>> OK, I documented it in PROBLEMS.
>
> Finally, I've divided `tramp-register-file-name-handlers' into two
> parts, which are evaluated at different startup places. This should
> solve the problem.

Tramp is a central part of the file access infrastructure.  So I think
this change warrants another pretest, preferably when the HPUX
problems have been sorted out (or are they already?).  If this can be
achieved this weekend and nothing else intervenes, next weekend could
be our final target.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Pretest

[Chong Yidong]

> I think this change warrants another pretest, preferably when the
> HPUX problems have been sorted out (or are they already?).  If this
> can be achieved this weekend...

This weekend is probably too soon; let's make that Tuesday, April 3.

If there are no objections, I'll roll a new pretest tarball on that
date.

> ... and nothing else intervenes, next weekend could be our final
> target.

I would like that, but this is dependent on Kevin Rodger's papers
arriving (I guess RMS will inform us about that).