Re: Reverting *Locate* buffers.

[David Kastrup <dak@gnu.org>]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:

> T. V. Raman wrote:
>
>    While on the error message regarding tramp, I've found that tramp
>    being around causes *a lot* of recursive expand file calls ---
>    try running edebug on anything that calls expand-file-name to see
>    what I mean.
>
>    Basically, tramp should only fire on the  "head" of the path
>    being expanded -- at present it appears to fire for *each* path
>    component. 
>
> Just as a general question to everybody interested (not just to the
> person in the "To" field):
>
> Where do we stand now in this thread?  Obviously, I can not implement
> David's suggestion as long as there is this error message (assuming it
> would not give other problems, even without that message, which I can
> not test).
>
> Do I just commit my previously sent patch, or do we have the feeling
> that there are bugs in Tramp which should be reported?

Sounds like a bug to me.  I think that my suggestion should be able to
work and it is not really out of the ordinary with regard to using
tramp.  That being said, using "cd" to change into root is certainly
not something to be done as a default setting, and it is actually not
possible to know whether the "sudo" or "su" method would need to get
used for a particular user on a particular system (if locate _is_
already running in some remote but non-root context, one would
probably even want to use a multihop method from tramp, but this is so
crazy that we really need not worry about it now).  But the feature is
so obscure that it needs to announce itself for customization, so
failure of updatedb should be detected and the variable to try for
customization in order to place updatedb in a tramp-governed announced
after the error message.

Note that this is a "wow feature": people will be pleasantly surprised
if it is there, but not really expect it.  So there is no large
incentive to get it going if other difficulties rather than a tramp
bug seem to make that infeasible.

> Note that Tramp is independently maintained by tramp-devel, which I
> have CC-ed, rather than by emacs-devel.  I believe that the people
> maintaining Tramp also read emacs-devel, but I am not sure that they
> have followed this thread.

Let's wait for their comment.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum