GNU bug report logs -
#18891
Doesn't handle pwd = /C: very well
Previous Next
Reported by: Glenn Morris <rgm <at> gnu.org>
Date: Wed, 29 Oct 2014 20:04:01 UTC
Severity: minor
Found in version 24.4
Fixed in version 24.5
Done: Michael Albinus <michael.albinus <at> gmx.de>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 18891 in the body.
You can then email your comments to 18891 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#18891
; Package
emacs
.
(Wed, 29 Oct 2014 20:04:01 GMT)
Full text and
rfc822 format available.
Message #3 received at submit <at> debbugs.gnu.org (full text, mbox):
Package: emacs
Severity: minor
Version: 24.4
On a GNU/Linux system:
mkdir -p /C:
cd /C:
emacs-24.4 -Q
->
Tramp: Opening connection for C using scp...
Opening connection for C using scp... \
Tramp: Sending command `exec ssh -e none C'
Tramp: Waiting for prompts from remote shell...
Waiting for prompts from remote shell... \
Tramp failed to connect. If this happens repeatedly, try
`M-x tramp-cleanup-this-connection'
[waits for ~ 30 seconds]
Wrote /home/rgm/.emacs.d/tramp
and Emacs never actually starts.
cf: http://lists.gnu.org/archive/html/bug-gnu-emacs/2001-09/msg00154.html
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#18891
; Package
emacs
.
(Tue, 04 Nov 2014 12:50:02 GMT)
Full text and
rfc822 format available.
Message #6 received at 18891 <at> debbugs.gnu.org (full text, mbox):
Glenn Morris <rgm <at> gnu.org> writes:
> On a GNU/Linux system:
>
> mkdir -p /C:
> cd /C:
> emacs-24.4 -Q
>
> ->
>
> Tramp: Opening connection for C using scp...
> Opening connection for C using scp... \
> Tramp: Sending command `exec ssh -e none C'
> Tramp: Waiting for prompts from remote shell...
> Waiting for prompts from remote shell... \
> Tramp failed to connect. If this happens repeatedly, try
> `M-x tramp-cleanup-this-connection'
> [waits for ~ 30 seconds]
> Wrote /home/rgm/.emacs.d/tramp
>
> and Emacs never actually starts.
1. The Lisp backtrace reads like this:
...
apply(tramp-sh-file-name-handler expand-file-name ("/C:./." nil))
tramp-file-name-handler(expand-file-name "/C:./." nil)
file-attributes("/C:./.")
normal-top-level()
"/C:" as default directory is wrong. It triggers Tramp to start,
which fails. Maybe one could prevent this problem by giving the
default directory the prefix "/:".
2. If I wrap the call of `file-attributes' in `normal-top-level' with
`ignore-errors', Emacs starts up after claiming the Tramp
error. However, the docstring of `file-attributes' says "Value is nil
if specified file cannot be opened.". Therefore, `file-attributes'
itself must suppress errors even in such calls like
dired.c:912: filename = Fexpand_file_name (filename, Qnil);
3. The 30 sec delay is caused by Tramp, which tries to show the
connection buffer in order to give the user the possibility to know
what's up. This is not useful in this case, because Emacs hasn't
started yet. I would like to suppress this pause at this stage;
however I didn't find a way, how I could check whether Emacs is able
to show a buffer to the user (startup finished). A hint for this kind
of check would be helpful for me.
> cf: http://lists.gnu.org/archive/html/bug-gnu-emacs/2001-09/msg00154.html
13 years old ... it's time to fix it.
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#18891
; Package
emacs
.
(Tue, 04 Nov 2014 16:48:03 GMT)
Full text and
rfc822 format available.
Message #9 received at 18891 <at> debbugs.gnu.org (full text, mbox):
Michael Albinus wrote:
> "/C:" as default directory is wrong. It triggers Tramp to start,
> which fails. Maybe one could prevent this problem by giving the
> default directory the prefix "/:".
You know much more about this than I do, but my dumb idea was:
if a directory name happens to match a tramp pattern, as "/C:"
presumably does, how about first checking if a local directory literally
named that exists, before invoking a remote handler?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#18891
; Package
emacs
.
(Tue, 04 Nov 2014 17:07:02 GMT)
Full text and
rfc822 format available.
Message #12 received at 18891 <at> debbugs.gnu.org (full text, mbox):
> From: Glenn Morris <rgm <at> gnu.org>
> Date: Tue, 04 Nov 2014 11:47:19 -0500
> Cc: 18891 <at> debbugs.gnu.org
>
> Michael Albinus wrote:
>
> > "/C:" as default directory is wrong. It triggers Tramp to start,
> > which fails. Maybe one could prevent this problem by giving the
> > default directory the prefix "/:".
>
> You know much more about this than I do, but my dumb idea was:
> if a directory name happens to match a tramp pattern, as "/C:"
> presumably does, how about first checking if a local directory literally
> named that exists, before invoking a remote handler?
That's probably something Emacs should do _before_ invoking the
handler, no? I mean, the decision whether to let the handler do this
job is outside the scope of the handler.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#18891
; Package
emacs
.
(Tue, 04 Nov 2014 17:37:02 GMT)
Full text and
rfc822 format available.
Message #15 received at 18891 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii wrote:
>> if a directory name happens to match a tramp pattern, as "/C:"
>> presumably does, how about first checking if a local directory literally
>> named that exists, before invoking a remote handler?
>
> That's probably something Emacs should do _before_ invoking the
> handler, no? I mean, the decision whether to let the handler do this
> job is outside the scope of the handler.
That's what I meant, I think...
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#18891
; Package
emacs
.
(Tue, 04 Nov 2014 18:48:01 GMT)
Full text and
rfc822 format available.
Message #18 received at 18891 <at> debbugs.gnu.org (full text, mbox):
Glenn Morris <rgm <at> gnu.org> writes:
> Eli Zaretskii wrote:
>
>>> if a directory name happens to match a tramp pattern, as "/C:"
>>> presumably does, how about first checking if a local directory literally
>>> named that exists, before invoking a remote handler?
>>
>> That's probably something Emacs should do _before_ invoking the
>> handler, no? I mean, the decision whether to let the handler do this
>> job is outside the scope of the handler.
>
> That's what I meant, I think...
There could be undesired side effects. File name handlers are invoked
only if the file *name* matches a corresponding regexp, nothing else. If
you want to make checks on the file system itself, it would result at
least in performance penalties.
Not to speak about cases where it is not possible.
(substitute-in-file-name "/C:/$FOO") requires the expansion of
$FOO. That's the task of Tramp, according to that file name. Nothing you
can check before invoking Tramp, because you don't know the value of $FOO.
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#18891
; Package
emacs
.
(Tue, 04 Nov 2014 18:59:01 GMT)
Full text and
rfc822 format available.
Message #21 received at 18891 <at> debbugs.gnu.org (full text, mbox):
Michael Albinus wrote:
> There could be undesired side effects. File name handlers are invoked
> only if the file *name* matches a corresponding regexp, nothing else. If
> you want to make checks on the file system itself, it would result at
> least in performance penalties.
>
> Not to speak about cases where it is not possible.
>
> (substitute-in-file-name "/C:/$FOO") requires the expansion of
> $FOO. That's the task of Tramp, according to that file name. Nothing you
> can check before invoking Tramp, because you don't know the value of $FOO.
Well, it seems to me that so long as the Tramp file name syntax can also
match a real local file name, you cannot avoid testing for the existence
of such a file. If you are saying that needs to be done in Tramp rather
than before Tramp is invoked, fine by me.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#18891
; Package
emacs
.
(Tue, 04 Nov 2014 19:12:01 GMT)
Full text and
rfc822 format available.
Message #24 received at 18891 <at> debbugs.gnu.org (full text, mbox):
Michael Albinus wrote:
> There could be undesired side effects. File name handlers are invoked
> only if the file *name* matches a corresponding regexp, nothing else. If
> you want to make checks on the file system itself, it would result at
> least in performance penalties.
I don't consider a performance penalty an undesired side effect, but
rather necessary to avoid a completely incorrect result, such as we have
in this case.
> (substitute-in-file-name "/C:/$FOO") requires the expansion of
> $FOO. That's the task of Tramp, according to that file name. Nothing you
> can check before invoking Tramp, because you don't know the value of $FOO.
Why can't it be checked before Tramp?
What if "FOO = foo" in the local environment, and "/C:/foo"
is a real directory on the local machine?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#18891
; Package
emacs
.
(Tue, 04 Nov 2014 19:31:01 GMT)
Full text and
rfc822 format available.
Message #27 received at 18891 <at> debbugs.gnu.org (full text, mbox):
Glenn Morris <rgm <at> gnu.org> writes:
> Well, it seems to me that so long as the Tramp file name syntax can also
> match a real local file name, you cannot avoid testing for the existence
> of such a file. If you are saying that needs to be done in Tramp rather
> than before Tramp is invoked, fine by me.
*If* you don't want a file name handler being invoked, you can either
let-bind `file-name-handler-alist' to nil, or you could prepend the file
name by "/:", i.e. "/:/C:/" in the case which triggered the bug. Both is
possible in order to mask default-directory when starting up Emacs.
And a local file name which will be in conflict with such a file name
for Tramp will be extremely rare, I believe. Do there exist real life
reports?
And this bug (Emacs does not start) is triggered by `file-attributes'
implementation, which does not keep its promises (return nil when
FILENAME cannot be opened). I believe we shall fix this, instead of
changing basic design decisions.
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#18891
; Package
emacs
.
(Tue, 04 Nov 2014 19:37:01 GMT)
Full text and
rfc822 format available.
Message #30 received at 18891 <at> debbugs.gnu.org (full text, mbox):
Glenn Morris <rgm <at> gnu.org> writes:
> I don't consider a performance penalty an undesired side effect, but
> rather necessary to avoid a completely incorrect result, such as we have
> in this case.
The "unnecessary result" is an error in `file-attributes'.
>> (substitute-in-file-name "/C:/$FOO") requires the expansion of
>> $FOO. That's the task of Tramp, according to that file name. Nothing you
>> can check before invoking Tramp, because you don't know the value of $FOO.
>
> Why can't it be checked before Tramp?
>
> What if "FOO = foo" in the local environment, and "/C:/foo"
> is a real directory on the local machine?
`substitute-in-file-name' is an operation supporting file name
handlers. This handler must be called, instead of expanding an
environment variable locally. That's the design, and the promise by the
API.
Everything could be changed, of course. But please then with a
corresponding *design* change. And `substitute-in-file-name' was just
the very first example which came to my mind, without thinking about
seriously. There are many other operations supporting file name
handlers, which must be investigated for this kind of changes as well.
For the records: I do not oppose fundamentally such changes. I just
resist to change something on-the-fly, without redesign.
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#18891
; Package
emacs
.
(Tue, 04 Nov 2014 20:25:02 GMT)
Full text and
rfc822 format available.
Message #33 received at 18891 <at> debbugs.gnu.org (full text, mbox):
> That's probably something Emacs should do _before_ invoking the
> handler, no? I mean, the decision whether to let the handler do this
> job is outside the scope of the handler.
The jka-compr and epa handlers apply to files that are accessible
locally, so I don't think we can decide it before running the handler.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#18891
; Package
emacs
.
(Wed, 05 Nov 2014 11:27:02 GMT)
Full text and
rfc822 format available.
Message #36 received at 18891 <at> debbugs.gnu.org (full text, mbox):
Hi,
I've committed two patches to the emacs-24 branch, which should fix the
problem. Glenn, could you, please, check?
Thanks, and best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#18891
; Package
emacs
.
(Wed, 05 Nov 2014 19:44:01 GMT)
Full text and
rfc822 format available.
Message #39 received at 18891 <at> debbugs.gnu.org (full text, mbox):
Michael Albinus wrote:
> I've committed two patches to the emacs-24 branch, which should fix the
> problem. Glenn, could you, please, check?
Well, Emacs starts now.
It still prints
Tramp: Opening connection for C using scp...
Opening connection for C using scp... \
Tramp: Sending command `exec ssh -e none C'
Tramp: Waiting for prompts from remote shell...
Waiting for prompts from remote shell... \
Tramp: Waiting for prompts from remote shell...failed
Tramp: Opening connection for C using scp...failed
in the terminal, and C-x C-f shows the prompt as the weird-looking:
Find file: /:/C:/
but if that is how it has to be, so be it.
Trying to visit a new file fails though:
C-x C-f bar RET
since it again tries to do something via Tramp and fails.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#18891
; Package
emacs
.
(Wed, 05 Nov 2014 19:46:03 GMT)
Full text and
rfc822 format available.
Message #42 received at 18891 <at> debbugs.gnu.org (full text, mbox):
PS this makes me think, what happens if the local file name happens to
match a remote host that does exist...
If as you say the design prefers remote hosts over local ones, that
seems like a bad design to me.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#18891
; Package
emacs
.
(Wed, 05 Nov 2014 19:54:01 GMT)
Full text and
rfc822 format available.
Message #45 received at 18891 <at> debbugs.gnu.org (full text, mbox):
> From: Glenn Morris <rgm <at> gnu.org>
> Date: Wed, 05 Nov 2014 14:45:36 -0500
> Cc: 18891 <at> debbugs.gnu.org
>
>
> PS this makes me think, what happens if the local file name happens to
> match a remote host that does exist...
I think the file should match a remote host prefixed with a protocol
supported by Tramp, not just the host name, for this issue to pop up.
> If as you say the design prefers remote hosts over local ones, that
> seems like a bad design to me.
I think the idea is that such files are very rare, and using the /:
prefix to quote them is the fire escape.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#18891
; Package
emacs
.
(Wed, 05 Nov 2014 19:57:01 GMT)
Full text and
rfc822 format available.
Message #48 received at 18891 <at> debbugs.gnu.org (full text, mbox):
Glenn Morris <rgm <at> gnu.org> writes:
> PS this makes me think, what happens if the local file name happens to
> match a remote host that does exist...
>
> If as you say the design prefers remote hosts over local ones, that
> seems like a bad design to me.
Don't blame me, the design seems to be older than my liaison with Emacs
(ange-ftp.el is copyrighted since 1989; I've started with Emacs in
autumn 1990, IIRC).
You have the same problem with other file name handlers. If you work on
a file foo.gpg, epa-file-handler will be invoked just because of this
name. It doesn't matter, whether taht file is encrypted with gpg, or not.
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#18891
; Package
emacs
.
(Wed, 05 Nov 2014 20:05:02 GMT)
Full text and
rfc822 format available.
Message #51 received at 18891 <at> debbugs.gnu.org (full text, mbox):
Glenn Morris <rgm <at> gnu.org> writes:
> Well, Emacs starts now.
> It still prints
>
> Tramp: Opening connection for C using scp...
> Opening connection for C using scp... \
> Tramp: Sending command `exec ssh -e none C'
> Tramp: Waiting for prompts from remote shell...
> Waiting for prompts from remote shell... \
> Tramp: Waiting for prompts from remote shell...failed
> Tramp: Opening connection for C using scp...failed
This is expected. But I've suppressed the 30 sec pause now, do you see?
> in the terminal, and C-x C-f shows the prompt as the weird-looking:
>
> Find file: /:/C:/
>
> but if that is how it has to be, so be it.
*This* shall work. Prefixing absolute file names with "/:" shall suppress
all file name handlers, see (info "(emacs) Quoted File Names")
> Trying to visit a new file fails though:
>
> C-x C-f bar RET
>
> since it again tries to do something via Tramp and fails.
Unfortune, yes. But how often does it happen, that your default
directory has such a value like "/C:/" ?
Anyway, I will check how I could convince Tramp that "/:/C:/bar"
shouldn't be touched.
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#18891
; Package
emacs
.
(Wed, 05 Nov 2014 20:08:02 GMT)
Full text and
rfc822 format available.
Message #54 received at 18891 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> PS this makes me think, what happens if the local file name happens to
>> match a remote host that does exist...
>
> I think the file should match a remote host prefixed with a protocol
> supported by Tramp, not just the host name, for this issue to pop up.
Tramp supports both "/method:host:" and just "/host:".
> I think the idea is that such files are very rare, and using the /:
> prefix to quote them is the fire escape.
Yes. But somehow I have the impression, that it doesn't work fully as
expected in Glenn's scenario. Will check.
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#18891
; Package
emacs
.
(Wed, 05 Nov 2014 20:23:02 GMT)
Full text and
rfc822 format available.
Message #57 received at 18891 <at> debbugs.gnu.org (full text, mbox):
Michael Albinus wrote:
> This is expected. But I've suppressed the 30 sec pause now, do you see?
Yes, no pause.
> Unfortune, yes. But how often does it happen, that your default
> directory has such a value like "/C:/" ?
Never! :)
I did say this was severity: minor... :)
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#18891
; Package
emacs
.
(Wed, 05 Nov 2014 22:45:01 GMT)
Full text and
rfc822 format available.
Message #60 received at 18891 <at> debbugs.gnu.org (full text, mbox):
> Don't blame me, the design seems to be older than my liaison with Emacs
> (ange-ftp.el is copyrighted since 1989; I've started with Emacs in
> autumn 1990, IIRC).
I guess Tramp could check if there's matching local dir and pass the
request through untouched if there is.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#18891
; Package
emacs
.
(Thu, 06 Nov 2014 03:51:01 GMT)
Full text and
rfc822 format available.
Message #63 received at 18891 <at> debbugs.gnu.org (full text, mbox):
> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Date: Wed, 05 Nov 2014 17:44:44 -0500
> Cc: 18891 <at> debbugs.gnu.org
>
> > Don't blame me, the design seems to be older than my liaison with Emacs
> > (ange-ftp.el is copyrighted since 1989; I've started with Emacs in
> > autumn 1990, IIRC).
>
> I guess Tramp could check if there's matching local dir and pass the
> request through untouched if there is.
If Tramp did that, how would the user tell Tramp that it should access
the remote host, even though there is a matching local file? (The
converse situation can be handled with /: quoting.)
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#18891
; Package
emacs
.
(Thu, 06 Nov 2014 08:34:01 GMT)
Full text and
rfc822 format available.
Message #66 received at 18891 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> > Don't blame me, the design seems to be older than my liaison with Emacs
>> > (ange-ftp.el is copyrighted since 1989; I've started with Emacs in
>> > autumn 1990, IIRC).
>>
>> I guess Tramp could check if there's matching local dir and pass the
>> request through untouched if there is.
>
> If Tramp did that, how would the user tell Tramp that it should access
> the remote host, even though there is a matching local file? (The
> converse situation can be handled with /: quoting.)
Indeed. And there are even cases where checking a local dir wouldn't work:
(make-directory "/C:/foo/bar/baz" t)
After all, I believe the use case (local file name, which looks like a
remote one) isn't relevant enough to add ugly hacks.
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#18891
; Package
emacs
.
(Thu, 06 Nov 2014 15:40:02 GMT)
Full text and
rfc822 format available.
Message #69 received at 18891 <at> debbugs.gnu.org (full text, mbox):
>>> I guess Tramp could check if there's matching local dir and pass the
>>> request through untouched if there is.
>> If Tramp did that, how would the user tell Tramp that it should access
>> the remote host, even though there is a matching local file? (The
>> converse situation can be handled with /: quoting.)
It could use an alternative syntax. E.g. /ssh:C:. or /ssh:c:~ or
/ssh:c.mydomain.org: , you name it.
It seems like a sufficiently oddball case (after all, the current
assumption is that such conflicts never happen).
> Indeed. And there are even cases where checking a local dir wouldn't work:
> (make-directory "/C:/foo/bar/baz" t)
I don't see what's different, unless you were thinking of checking the
existence of "/C:/foo/bar/baz" whereas I'd only want to check the
existence of the "root", i.e. "/C:".
> After all, I believe the use case (local file name, which looks like a
> remote one) isn't relevant enough to add ugly hacks.
Agreed. This said, I'm in favor of deprecating the "/<host>:" syntax in
favor of "/<method>:<host>:", which should make the possibility of such
conflicts even more remote (pun intended).
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#18891
; Package
emacs
.
(Thu, 06 Nov 2014 15:51:02 GMT)
Full text and
rfc822 format available.
Message #72 received at 18891 <at> debbugs.gnu.org (full text, mbox):
Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
>> After all, I believe the use case (local file name, which looks like a
>> remote one) isn't relevant enough to add ugly hacks.
>
> Agreed. This said, I'm in favor of deprecating the "/<host>:" syntax in
> favor of "/<method>:<host>:", which should make the possibility of such
> conflicts even more remote (pun intended).
From implementation point of view, I'm with you. It would make parsing a
file name easier.
I suspect using the "/<host>:" syntax was motivated by a smooth
migration from ange-ftp to Tramp. One could tell people, that they
should set tramp-default-method to "ftp", and they wouldn't need to
change anything.
That's more than a decade ago. Don't know, whether Emacs users are ready
to change to "/<method>:<host>:". And a default method like "/:<host>:"
is not applicable, because "/:" is used for something different.
> Stefan
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#18891
; Package
emacs
.
(Thu, 06 Nov 2014 23:31:02 GMT)
Full text and
rfc822 format available.
Message #75 received at 18891 <at> debbugs.gnu.org (full text, mbox):
> That's more than a decade ago. Don't know, whether Emacs users are ready
> to change to "/<method>:<host>:".
I'm pretty sure it wouldn't be a big deal, tho we'd still have to accept
the old syntax for a while.
FWIW, I've been using systematically /<method>:<host>: for many years
now, and not to avoid conflicts but because I found it easier not to
have to worry about which method I'd get with /<host>:.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#18891
; Package
emacs
.
(Fri, 07 Nov 2014 10:39:01 GMT)
Full text and
rfc822 format available.
Message #78 received at 18891 <at> debbugs.gnu.org (full text, mbox):
Stefan Monnier <monnier <at> IRO.UMontreal.CA> writes:
>> That's more than a decade ago. Don't know, whether Emacs users are ready
>> to change to "/<method>:<host>:".
>
> I'm pretty sure it wouldn't be a big deal, tho we'd still have to accept
> the old syntax for a while.
I would be annoyed if I have to remember what is the name of the default
method (which can differ depending on the host).
Andreas.
--
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#18891
; Package
emacs
.
(Fri, 07 Nov 2014 14:53:01 GMT)
Full text and
rfc822 format available.
Message #81 received at 18891 <at> debbugs.gnu.org (full text, mbox):
Glenn Morris <rgm <at> gnu.org> writes:
> in the terminal, and C-x C-f shows the prompt as the weird-looking:
>
> Find file: /:/C:/
>
> but if that is how it has to be, so be it.
This still doesn't work. dired applies call-process internally, and
there seem to be several side effects which I couldn't trap.
> Trying to visit a new file fails though:
>
> C-x C-f bar RET
>
> since it again tries to do something via Tramp and fails.
This shall work now, both cases bar being an existing file, and bar not
existing. I've committed respective patches to the emacs-24 branch.
Although not *everything* is working correctly (call-process), I would
propose to close the bug. It's not important enough.
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#18891
; Package
emacs
.
(Fri, 07 Nov 2014 15:07:02 GMT)
Full text and
rfc822 format available.
Message #84 received at 18891 <at> debbugs.gnu.org (full text, mbox):
>>> That's more than a decade ago. Don't know, whether Emacs users are ready
>>> to change to "/<method>:<host>:".
>> I'm pretty sure it wouldn't be a big deal, tho we'd still have to accept
>> the old syntax for a while.
> I would be annoyed if I have to remember what is the name of the default
> method (which can differ depending on the host).
Do you configure those methods explicitly, or do Tramp's defaults just
work for you?
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#18891
; Package
emacs
.
(Fri, 07 Nov 2014 15:15:02 GMT)
Full text and
rfc822 format available.
Message #87 received at 18891 <at> debbugs.gnu.org (full text, mbox):
> From: Michael Albinus <michael.albinus <at> gmx.de>
> Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, Eli Zaretskii <eliz <at> gnu.org>, 18891 <at> debbugs.gnu.org
> Date: Fri, 07 Nov 2014 15:52:37 +0100
>
> > C-x C-f bar RET
> >
> > since it again tries to do something via Tramp and fails.
>
> This shall work now, both cases bar being an existing file, and bar not
> existing. I've committed respective patches to the emacs-24 branch.
Your change calls Ffile_accessible_directory_p, Fstring_match, and
Fsubstring with a unibyte (encoded) string as their argument. I think
we should avoid that, as, e.g., Fstring_match might yield a false
positive under some encodings.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#18891
; Package
emacs
.
(Fri, 07 Nov 2014 16:59:02 GMT)
Full text and
rfc822 format available.
Message #90 received at 18891 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> Your change calls Ffile_accessible_directory_p, Fstring_match, and
> Fsubstring with a unibyte (encoded) string as their argument. I think
> we should avoid that, as, e.g., Fstring_match might yield a false
> positive under some encodings.
Shall I change it like this?
--8<---------------cut here---------------start------------->8---
*** /usr/local/src/emacs-24/src/callproc.c.~117680~ 2014-11-07 17:54:37.318055813 +0100
--- /usr/local/src/emacs-24/src/callproc.c 2014-11-07 17:54:03.865559094 +0100
***************
*** 150,157 ****
dir = expand_and_dir_to_file (dir, Qnil);
- if (STRING_MULTIBYTE (dir))
- dir = ENCODE_FILE (dir);
if (NILP (Ffile_accessible_directory_p (dir)))
report_file_error ("Setting current directory",
BVAR (current_buffer, directory));
--- 150,155 ----
***************
*** 160,165 ****
--- 158,166 ----
if (Fstring_match (build_string ("^/:"), dir, Qnil))
dir = Fsubstring (dir, make_number (2), Qnil);
+ if (STRING_MULTIBYTE (dir))
+ dir = ENCODE_FILE (dir);
+
RETURN_UNGCPRO (dir);
}
--8<---------------cut here---------------end--------------->8---
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#18891
; Package
emacs
.
(Fri, 07 Nov 2014 18:55:01 GMT)
Full text and
rfc822 format available.
Message #93 received at 18891 <at> debbugs.gnu.org (full text, mbox):
Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
>>>> That's more than a decade ago. Don't know, whether Emacs users are ready
>>>> to change to "/<method>:<host>:".
>>> I'm pretty sure it wouldn't be a big deal, tho we'd still have to accept
>>> the old syntax for a while.
>> I would be annoyed if I have to remember what is the name of the default
>> method (which can differ depending on the host).
>
> Do you configure those methods explicitly, or do Tramp's defaults just
> work for you?
I have added an element to tramp-default-method-alist.
Andreas.
--
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#18891
; Package
emacs
.
(Fri, 07 Nov 2014 19:57:02 GMT)
Full text and
rfc822 format available.
Message #96 received at 18891 <at> debbugs.gnu.org (full text, mbox):
> From: Michael Albinus <michael.albinus <at> gmx.de>
> Cc: rgm <at> gnu.org, monnier <at> iro.umontreal.ca, 18891 <at> debbugs.gnu.org
> Date: Fri, 07 Nov 2014 17:58:30 +0100
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > Your change calls Ffile_accessible_directory_p, Fstring_match, and
> > Fsubstring with a unibyte (encoded) string as their argument. I think
> > we should avoid that, as, e.g., Fstring_match might yield a false
> > positive under some encodings.
>
> Shall I change it like this?
Yes, I think this is much better. Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#18891
; Package
emacs
.
(Fri, 07 Nov 2014 20:11:01 GMT)
Full text and
rfc822 format available.
Message #99 received at 18891 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> Shall I change it like this?
>
> Yes, I think this is much better. Thanks.
Done.
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#18891
; Package
emacs
.
(Sat, 08 Nov 2014 04:36:02 GMT)
Full text and
rfc822 format available.
Message #102 received at 18891 <at> debbugs.gnu.org (full text, mbox):
>> Do you configure those methods explicitly, or do Tramp's defaults just
>> work for you?
> I have added an element to tramp-default-method-alist.
So maybe we should simply change tramp-default-method-alist to default
to nil, and to say that if none of the entries match, then the file is
passed through rather than handled by Tramp.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#18891
; Package
emacs
.
(Sat, 08 Nov 2014 08:14:02 GMT)
Full text and
rfc822 format available.
Message #105 received at 18891 <at> debbugs.gnu.org (full text, mbox):
Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
> So maybe we should simply change tramp-default-method-alist to default
> to nil, and to say that if none of the entries match, then the file is
> passed through rather than handled by Tramp.
If we support only "/<method>:<host>:" syntax, there is no need anymore
for tramp-default-method and tramp-default-method-alist.
> Stefan
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#18891
; Package
emacs
.
(Sat, 08 Nov 2014 08:15:02 GMT)
Full text and
rfc822 format available.
Message #108 received at 18891 <at> debbugs.gnu.org (full text, mbox):
Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
>>> Do you configure those methods explicitly, or do Tramp's defaults just
>>> work for you?
>> I have added an element to tramp-default-method-alist.
>
> So maybe we should simply change tramp-default-method-alist to default
> to nil, and to say that if none of the entries match, then the file is
> passed through rather than handled by Tramp.
How does that fix the annoyance?
Andreas.
--
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#18891
; Package
emacs
.
(Sat, 08 Nov 2014 15:34:02 GMT)
Full text and
rfc822 format available.
Message #111 received at 18891 <at> debbugs.gnu.org (full text, mbox):
>> So maybe we should simply change tramp-default-method-alist to default
>> to nil, and to say that if none of the entries match, then the file is
>> passed through rather than handled by Tramp.
> How does that fix the annoyance?
It removes the /<host>: from the defaults (so there's no more risk of it
colliding with a local file name), but it lets you keep using that
/<host>: syntax for those specific entries you want (and if they collide
with a local file, it's your own fault).
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#18891
; Package
emacs
.
(Sat, 08 Nov 2014 16:15:02 GMT)
Full text and
rfc822 format available.
Message #114 received at 18891 <at> debbugs.gnu.org (full text, mbox):
Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
>>> So maybe we should simply change tramp-default-method-alist to default
>>> to nil, and to say that if none of the entries match, then the file is
>>> passed through rather than handled by Tramp.
>> How does that fix the annoyance?
>
> It removes the /<host>: from the defaults (so there's no more risk of it
> colliding with a local file name), but it lets you keep using that
> /<host>: syntax for those specific entries you want (and if they collide
> with a local file, it's your own fault).
That doesn't fix the annoyance.
Andreas.
--
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#18891
; Package
emacs
.
(Sat, 08 Nov 2014 18:02:02 GMT)
Full text and
rfc822 format available.
Message #117 received at 18891 <at> debbugs.gnu.org (full text, mbox):
> That doesn't fix the annoyance.
Then I guess I don't know which annoyance you're referring to.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#18891
; Package
emacs
.
(Sat, 08 Nov 2014 18:14:02 GMT)
Full text and
rfc822 format available.
Message #120 received at 18891 <at> debbugs.gnu.org (full text, mbox):
Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
>> That doesn't fix the annoyance.
>
> Then I guess I don't know which annoyance you're referring to.
I would be annoyed if I have to remember what is the name of the default
method (which can differ depending on the host).
Andreas.
--
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#18891
; Package
emacs
.
(Sat, 08 Nov 2014 20:31:02 GMT)
Full text and
rfc822 format available.
Message #123 received at 18891 <at> debbugs.gnu.org (full text, mbox):
>>> That doesn't fix the annoyance.
>> Then I guess I don't know which annoyance you're referring to.
> I would be annoyed if I have to remember what is the name of the default
> method (which can differ depending on the host).
But you wouldn't have to remember: you'd set it once and for all in
tramp-default-method-alist (you could even copy that from the setting
in 24.4 if that setting suited you) and then you would keep using
/<host>: as before.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#18891
; Package
emacs
.
(Sat, 08 Nov 2014 20:59:02 GMT)
Full text and
rfc822 format available.
Message #126 received at 18891 <at> debbugs.gnu.org (full text, mbox):
Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
>>>> That doesn't fix the annoyance.
>>> Then I guess I don't know which annoyance you're referring to.
>> I would be annoyed if I have to remember what is the name of the default
>> method (which can differ depending on the host).
>
> But you wouldn't have to remember: you'd set it once and for all in
> tramp-default-method-alist (you could even copy that from the setting
> in 24.4 if that setting suited you) and then you would keep using
> /<host>: as before.
That works only for those that are matched by
tramp-default-method-alist.
Andreas.
--
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#18891
; Package
emacs
.
(Sat, 08 Nov 2014 22:04:02 GMT)
Full text and
rfc822 format available.
Message #129 received at 18891 <at> debbugs.gnu.org (full text, mbox):
>>>>> That doesn't fix the annoyance.
>>>> Then I guess I don't know which annoyance you're referring to.
>>> I would be annoyed if I have to remember what is the name of the default
>>> method (which can differ depending on the host).
>>
>> But you wouldn't have to remember: you'd set it once and for all in
>> tramp-default-method-alist (you could even copy that from the setting
>> in 24.4 if that setting suited you) and then you would keep using
>> /<host>: as before.
> That works only for those that are matched by
> tramp-default-method-alist.
If you copy the 24.4 setting, then all hosts will match something.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#18891
; Package
emacs
.
(Sat, 08 Nov 2014 22:10:02 GMT)
Full text and
rfc822 format available.
Message #132 received at 18891 <at> debbugs.gnu.org (full text, mbox):
Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
>>>>>> That doesn't fix the annoyance.
>>>>> Then I guess I don't know which annoyance you're referring to.
>>>> I would be annoyed if I have to remember what is the name of the default
>>>> method (which can differ depending on the host).
>>>
>>> But you wouldn't have to remember: you'd set it once and for all in
>>> tramp-default-method-alist (you could even copy that from the setting
>>> in 24.4 if that setting suited you) and then you would keep using
>>> /<host>: as before.
>> That works only for those that are matched by
>> tramp-default-method-alist.
>
> If you copy the 24.4 setting, then all hosts will match something.
No.
Andreas.
--
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#18891
; Package
emacs
.
(Sat, 08 Nov 2014 22:26:01 GMT)
Full text and
rfc822 format available.
Message #135 received at 18891 <at> debbugs.gnu.org (full text, mbox):
> No.
If you can't argument better than that, I'm afraid your opinion
won't matter.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#18891
; Package
emacs
.
(Sat, 08 Nov 2014 22:32:02 GMT)
Full text and
rfc822 format available.
Message #138 received at 18891 <at> debbugs.gnu.org (full text, mbox):
If you can't be bothered to actually check your claims your opinion is
worth nothing.
Andreas.
--
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#18891
; Package
emacs
.
(Sun, 09 Nov 2014 03:27:02 GMT)
Full text and
rfc822 format available.
Message #141 received at 18891 <at> debbugs.gnu.org (full text, mbox):
> If you can't be bothered to actually check your claims your opinion is
> worth nothing.
Ah, thanks, now it's all much more clear,
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#18891
; Package
emacs
.
(Sun, 09 Nov 2014 09:14:02 GMT)
Full text and
rfc822 format available.
Message #144 received at 18891 <at> debbugs.gnu.org (full text, mbox):
Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
>>> So maybe we should simply change tramp-default-method-alist to default
>>> to nil, and to say that if none of the entries match, then the file is
>>> passed through rather than handled by Tramp.
>> How does that fix the annoyance?
>
> It removes the /<host>: from the defaults (so there's no more risk of it
> colliding with a local file name), but it lets you keep using that
> /<host>: syntax for those specific entries you want (and if they collide
> with a local file, it's your own fault).
But there is also tramp-default-method, which is applied when there is
no match in tramp-default-method-alist. You would annoy all people who
haven't configured tramp-default-method-alist, and who are happy to
apply /<host>: today.
> Stefan
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#18891
; Package
emacs
.
(Sun, 09 Nov 2014 14:24:02 GMT)
Full text and
rfc822 format available.
Message #147 received at 18891 <at> debbugs.gnu.org (full text, mbox):
> But there is also tramp-default-method, which is applied when there is
> no match in tramp-default-method-alist. You would annoy all people who
> haven't configured tramp-default-method-alist, and who are happy to
> apply /<host>: today.
Of course, that's the core of my suggestion to deprecate the
/<host>: syntax.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#18891
; Package
emacs
.
(Sun, 09 Nov 2014 19:51:01 GMT)
Full text and
rfc822 format available.
Message #150 received at 18891 <at> debbugs.gnu.org (full text, mbox):
Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
>> But there is also tramp-default-method, which is applied when there is
>> no match in tramp-default-method-alist. You would annoy all people who
>> haven't configured tramp-default-method-alist, and who are happy to
>> apply /<host>: today.
>
> Of course, that's the core of my suggestion to deprecate the
> /<host>: syntax.
And that's what annoys Andreas.
> Stefan
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#18891
; Package
emacs
.
(Mon, 10 Nov 2014 15:30:03 GMT)
Full text and
rfc822 format available.
Message #153 received at 18891 <at> debbugs.gnu.org (full text, mbox):
>>> But there is also tramp-default-method, which is applied when there is
>>> no match in tramp-default-method-alist. You would annoy all people who
>>> haven't configured tramp-default-method-alist, and who are happy to
>>> apply /<host>: today.
>> Of course, that's the core of my suggestion to deprecate the
>> /<host>: syntax.
> And that's what annoys Andreas.
So he'll have to add an entry to tramp-default-method-alist.
Doesn't sound that terrible.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#18891
; Package
emacs
.
(Mon, 10 Nov 2014 15:56:02 GMT)
Full text and
rfc822 format available.
Message #156 received at 18891 <at> debbugs.gnu.org (full text, mbox):
Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
>>> Of course, that's the core of my suggestion to deprecate the
>>> /<host>: syntax.
>> And that's what annoys Andreas.
>
> So he'll have to add an entry to tramp-default-method-alist.
> Doesn't sound that terrible.
Looks like we are miscommunicating :-(
When the /<host>: syntax is deprecated, we must use /<method>:<host>:
There's no tramp-default-method-alist anymore.
When you still allow the /<host>: syntax, we have both
tramp-default-method-alist and tramp-default-method. The latter one is
used when there is no matching entry in tramp-default-method-alist.
Your proposal means to deprecate tramp-default-method, and to use the
/<method>:<host>: syntax for all hosts which are not matched in
tramp-default-method-alist. I don't see why it is better than the
current behaviour.
> Stefan
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#18891
; Package
emacs
.
(Mon, 10 Nov 2014 22:31:02 GMT)
Full text and
rfc822 format available.
Message #159 received at 18891 <at> debbugs.gnu.org (full text, mbox):
> tramp-default-method-alist. I don't see why it is better than the
> current behaviour.
It's better because out of the box /<host>: won't work any more (so it
can't collide with a local dir), but if people still like it, they can
get the old behavior by customizing tramp-default-method-alist.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#18891
; Package
emacs
.
(Tue, 11 Nov 2014 08:43:01 GMT)
Full text and
rfc822 format available.
Message #162 received at 18891 <at> debbugs.gnu.org (full text, mbox):
Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
>> tramp-default-method-alist. I don't see why it is better than the
>> current behaviour.
>
> It's better because out of the box /<host>: won't work any more (so it
> can't collide with a local dir), but if people still like it, they can
> get the old behavior by customizing tramp-default-method-alist.
When you proposed to deprecate the /<host>: syntax I said I'm with you
from the implementation point of view. Now your proposal still includes
this syntax, only discouraging people using it. So the promise of a
simpler implementation is not true anymore.
What's left is that we will annoy people, because tramp-default-method
won't exist anymore. They will learn soon, that (add-to-list
'tramp-default-method-alist '(nil nil "scp") t) will restore the
previous behaviour. We won't gain nothing.
And everything just for the rare-or-even-not-existing case that a user
has a local directory "/C:/" or similar. How often does it happen? I
haven't seen such reports for years (maybe never, but I distrust my
memory). Even this report is not based on an evidence in real life, but
on a 13 years old message about a problem with ange-ftp.
I don't believe this is sufficient for annoying Emacs users.
And users with such a special local directory could use "/:/C:/"
instead. Emacs supports this case already, and I've fixed some errors in
the run of this report. call-process with such a default-directory does
not work yet, but this is an error which could be fixed. It doesn't
qualify to change the Tramp design.
> Stefan
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#18891
; Package
emacs
.
(Tue, 11 Nov 2014 17:10:03 GMT)
Full text and
rfc822 format available.
Message #165 received at 18891 <at> debbugs.gnu.org (full text, mbox):
> When you proposed to deprecate the /<host>: syntax I said I'm with you
> from the implementation point of view. Now your proposal still includes
> this syntax, only discouraging people using it. So the promise of a
> simpler implementation is not true anymore.
So what would you propose instead for "deprecate the /<host>: syntax"?
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#18891
; Package
emacs
.
(Tue, 11 Nov 2014 21:14:02 GMT)
Full text and
rfc822 format available.
Message #168 received at 18891 <at> debbugs.gnu.org (full text, mbox):
Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
>> When you proposed to deprecate the /<host>: syntax I said I'm with you
>> from the implementation point of view. Now your proposal still includes
>> this syntax, only discouraging people using it. So the promise of a
>> simpler implementation is not true anymore.
>
> So what would you propose instead for "deprecate the /<host>: syntax"?
In order to simplify Tramp implementation, I would propose to obsolete
the /<host>: syntax completely. Since it doesn't seem to be acceptable
by the users, I'm in favor of doing nothing. Keep it as it is.
> Stefan
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#18891
; Package
emacs
.
(Wed, 12 Nov 2014 01:47:01 GMT)
Full text and
rfc822 format available.
Message #171 received at 18891 <at> debbugs.gnu.org (full text, mbox):
> In order to simplify Tramp implementation, I would propose to obsolete
> the /<host>: syntax completely. Since it doesn't seem to be acceptable
> by the users, I'm in favor of doing nothing. Keep it as it is.
OK, then. The only other option would be to split the /<host>: handling
to a separate file-name handler which redirects those requests to
/<method>:<host>:.
So this handler can be completely independent from Tramp (and could even
work for "arbitrary" filenames rather than only /<host>:, kind of like
a mount table).
But there's no urgent need to change the status quo.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#18891
; Package
emacs
.
(Wed, 12 Nov 2014 07:51:01 GMT)
Full text and
rfc822 format available.
Message #174 received at 18891 <at> debbugs.gnu.org (full text, mbox):
Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
> But there's no urgent need to change the status quo.
Thanks.
Glenn, do you think we need more work for this report? At least
call-process is not cooperating with a default-directory "/:/C:/".
OTOH, I've spent already some hours to hunt this problem, w/o success.
> Stefan
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#18891
; Package
emacs
.
(Sat, 15 Nov 2014 19:22:01 GMT)
Full text and
rfc822 format available.
Message #177 received at 18891 <at> debbugs.gnu.org (full text, mbox):
Michael Albinus wrote:
> Glenn, do you think we need more work for this report?
No. Thanks.
Reply sent
to
Michael Albinus <michael.albinus <at> gmx.de>
:
You have taken responsibility.
(Sun, 16 Nov 2014 10:20:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Glenn Morris <rgm <at> gnu.org>
:
bug acknowledged by developer.
(Sun, 16 Nov 2014 10:20:04 GMT)
Full text and
rfc822 format available.
Message #182 received at 18891-done <at> debbugs.gnu.org (full text, mbox):
Version: 24.5
Glenn Morris <rgm <at> gnu.org> writes:
> Michael Albinus wrote:
>
>> Glenn, do you think we need more work for this report?
>
> No. Thanks.
Closed.
Best regards, Michael.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Sun, 14 Dec 2014 12:24:05 GMT)
Full text and
rfc822 format available.
This bug report was last modified 10 years and 193 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.