On 15 Mar 2001, Stefan Monnier wrote:
>> "Daniel" == Daniel Pittman <[EMAIL PROTECTED]> writes:
>> Isn't C-u [1] C-x C-f what you want there, or is that just XEmacs?
>
> I think it's an Emacsism (but I wouldn't know).
>
>> It prompts me interactively for a coding system to visit with...
>
>
On 15 Mar 2001, Stefan Monnier wrote:
>> "Daniel" == Daniel Pittman <[EMAIL PROTECTED]> writes:
>> Isn't C-u [1] C-x C-f what you want there, or is that just XEmacs?
>
> I think it's an Emacsism (but I wouldn't know).
In Emacs, prefix arg for C-x C-f deals with wildcards, not with coding
sy
> "Daniel" == Daniel Pittman <[EMAIL PROTECTED]> writes:
> Isn't C-u [1] C-x C-f what you want there, or is that just XEmacs?
I think it's an Emacsism (but I wouldn't know).
> It prompts me interactively for a coding system to visit with...
Is that the coding system used for the file's cont
> Yes. Despite `file-remote-p'[1] being available, many packages are
> hard-coded to the knowledge of FTP-style paths.
VC did (in Emacs-20) and ediff still does.
Which others ?
> Yes. Especially because, for example, VC will refuse to operate on a FTP
> file path (because it can't), while TRAMP
On 15 Mar 2001, Kai Großjohann wrote:
> On 15 Mar 2001, Daniel Pittman wrote:
>
>> Anyway, I will look at that as a solution to the hook ordering
>> thing, unless someone felt like doing it for me. :)
>
> Well, your current filename suggestion means there is no clash. Which
> is good.
>
> In c
On 15 Mar 2001, Daniel Pittman wrote:
> Anyway, I will look at that as a solution to the hook ordering
> thing, unless someone felt like doing it for me. :)
Well, your current filename suggestion means there is no clash. Which
is good.
In case there is a filename syntax with clash, we can star
On 15 Mar 2001, Kai Großjohann wrote:
> On 15 Mar 2001, Daniel Pittman wrote:
>
>> Specifically, the FTP file access package assumes that `/[^/]:'
>> paths belong to them. This means that we need to chose from:
>>
>> 1. Change away from using paths that match that.
>> 2. Force EFS or Ange-FTP to
On 15 Mar 2001, Kai Großjohann wrote:
> On 15 Mar 2001, Daniel Pittman wrote:
>
>> True. I intend to take this up with the maintainers of it,
>> eventually. It's also true, though, of Ange-FTP.
>
> To my knowledge, Ange-FTP isn't so pushy. For Ange-FTP, it's
> sufficient to add it to file-name
On 15 Mar 2001, Daniel Pittman wrote:
> Specifically, the FTP file access package assumes that `/[^/]:'
> paths belong to them. This means that we need to chose from:
>
> 1. Change away from using paths that match that.
> 2. Force EFS or Ange-FTP to be loaded before TRAMP is.
Is number 2 really
On 15 Mar 2001, Daniel Pittman wrote:
> True. I intend to take this up with the maintainers of it,
> eventually. It's also true, though, of Ange-FTP.
To my knowledge, Ange-FTP isn't so pushy. For Ange-FTP, it's
sufficient to add it to file-name-handler-alist, and then to deal with
the function
On 14 Mar 2001, Kai Großjohann wrote:
> On Wed, 14 Mar 2001, Edward J. Sabol wrote:
>
>> On 15-Mar-2001, Daniel Pittman wrote:
[...]
>>> It's hard to support, requires hacking the innards of other
>>> packages and introduces load-order dependencies in the packages.
>>
>> Correct me if I'm wron
On Wed, 14 Mar 2001, Edward J. Sabol wrote:
> On 15-Mar-2001, Daniel Pittman wrote:
>> On Tue, 13 Mar 2001, Edward J. Sabol wrote:
>>> I agree with Francesco. I don't like "/!/" at all.
>> The prefix will be changeable, using custom, with no trouble at all.
>
> Yes, that's always been the case,
On Wed, 14 Mar 2001, Edward J. Sabol wrote:
> It's nice to say that users can customize the tramp prefix if they
> want to, but the reality is that few people will customize it.
All I'm saying it's enough to choose wisely before going stable :-)
Of course you're right, except for the `easy to t
>>> The prefix will be changeable, using custom, with no trouble at all.
>> Yes, that's always been the case, but I strongly feel that the
>> default should be wisely chosen.
> Finding the default shouldn't keep Daniel from implementing it, I
> think. After all, this is the development version!
I
On Wed, 14 Mar 2001, Edward J. Sabol wrote:
> On 15-Mar-2001, Daniel Pittman wrote:
>
>> The prefix will be changeable, using custom, with no trouble at
>> all.
>
> Yes, that's always been the case, but I strongly feel that the
> default should be wisely chosen.
Finding the default shouldn't ke
On 15-Mar-2001, Daniel Pittman wrote:
> On Tue, 13 Mar 2001, Edward J. Sabol wrote:
>> I agree with Francesco. I don't like "/!/" at all.
> The prefix will be changeable, using custom, with no trouble at all.
Yes, that's always been the case, but I strongly feel that the default should
be wisely
On Wed, 14 Mar 2001, Francesco Potorti` wrote:
> Well, I tried to write a message for the Emacs developers and
> pretesters lists, but could not manage to write anything that would
> make sense.
I am happy to offer what help I can. I would like to see a good solution
to the issue forged.
> I su
On 13 Mar 2001, Stefan Monnier wrote:
>> "Francesco" == Francesco Potorti` <[EMAIL PROTECTED]> writes:
>> Emacs should have a general hook for /[^/]+:.* filenames, where [^/]+
>> is the protocol. Then, different packages could register to that hook
>> and tell it which protocol they do manage.
On Tue, 13 Mar 2001, Edward J. Sabol wrote:
> I agree with Francesco. I don't like "/!/" at all.
The prefix will be changeable, using custom, with no trouble at all.
> First off, I have to use the shift key to type the exclamation point.
So, pick something different. "/tramp/" is available.
On 14 Mar 2001, Kai Großjohann wrote:
> On Tue, 13 Mar 2001, Francesco Potorti` wrote:
>
>> In the long run, perhaps. But if we think that this is The Right
>> Thing, then we should make this discussion go public, and at least
>> hear from others.
>
> I think RMS has said he wants it, if somebo
On Tue, 13 Mar 2001, Francesco Potorti` wrote:
>> As such, I want to propose an alternate tag to indicate our own
>> paths:
>>
>>"/!/"
>
>Seconded.
>
> I still do not like it at all. It's completely different from anything
> that is done out there. There is a quasi-stand
On 13 Mar 2001, Stefan Monnier wrote:
>> "Pete" == Pete Forman <[EMAIL PROTECTED]> writes:
>> /![@enc]/:telnet://[usr[:pwd]@]host1[:port]/ssh://host2/:/path/to/file
> [...]
>> F tramp-prefix-authority"//:" or "#"
>
> Clearly ""//:"" won't do since Emacs tends to interpret it directly.
On Tue, 13 Mar 2001, Pete Forman wrote:
> Daniel Pittman writes:
> > As such, I want to propose an alternate tag to indicate our own
> > paths:
> >
> >"/!/"
[...]
> I agree with you but would like to take it further. How about
> reworking the whole syntax along these lines.
>
> /![@en
Well, I tried to write a message for the Emacs developers and pretesters
lists, but could not manage to write anything that would make sense. I
suspect that we (ar at least it's me) do not have ideas clear enough to
be explained outside of here.
In fact, I do not manage to make a resume of
> "Pete" == Pete Forman <[EMAIL PROTECTED]> writes:
> /![@enc]/:telnet://[usr[:pwd]@]host1[:port]/ssh://host2/:/path/to/file
[...]
> F tramp-prefix-authority"//:" or "#"
Clearly ""//:"" won't do since Emacs tends to interpret it directly.
I liked the @enc thing, except that I'd use it
> "Francesco" == Francesco Potorti` <[EMAIL PROTECTED]> writes:
> Emacs should have a general hook for /[^/]+:.* filenames, where [^/]+ is
> the protocol. Then, different packages could register to that hook and
> tell it which protocol they do manage.
I think using /: is just fine, indeed.
On Tue, 13 Mar 2001, Francesco Potorti` wrote:
> In the long run, perhaps. But if we think that this is The Right
> Thing, then we should make this discussion go public, and at least
> hear from others.
I think RMS has said he wants it, if somebody can show him that it
works. Dunno of any othe
AFAIK, only ange-ftp/EFS and DOS use "/.*:". What other protocols are
you referring to?
I am loosely referring to the main established remote-file syntax (the
URL) which is protocol://, that of mc, which is /#protocol:, that of
ange-ftp, which is /host: (in this case the pro
Edward J. Sabol writes:
> I agree with Francesco. I don't like "/!/" at all. First off, I
> have to use the shift key to type the exclamation point. Secondly,
> there's no mnemonic for it at all. "/tr:" was the best idea that's
> been mentioned.
but on my keyboard i need to press the shift ke
I agree with Francesco. I don't like "/!/" at all. First off, I have to use
the shift key to type the exclamation point. Secondly, there's no mnemonic
for it at all. "/tr:" was the best idea that's been mentioned. That will fix
the DOS problem, though perhaps not the EFS problem, but we've lived w
Francesco Potorti` writes:
>> As such, I want to propose an alternate tag to indicate our
>> own paths:
>>
>>"/!/"
>
>Seconded.
>
> I still do not like it at all. It's completely different from
> anything that is done out there. There is a quasi-standard fo
Daniel Pittman writes:
> As such, I want to propose an alternate tag to indicate our own
> paths:
>
>"/!/"
>
> This will /not/ trigger either EFS or Ange-FTP when dealing with
> paths. This removes the need for hacking around at a number of
> fundamental levels to avoid treading (to
> As such, I want to propose an alternate tag to indicate our own
> paths:
>
>"/!/"
Seconded.
I still do not like it at all. It's completely different from anything
that is done out there. There is a quasi-standard for doing such
things, which involves using
On 13 Mar 2001, Kai Großjohann wrote:
> On 13 Mar 2001, Daniel Pittman wrote:
>
>> As such, I want to propose an alternate tag to indicate our own
>> paths:
>>
>>"/!/"
>
> Seconded. People might wish to change it to something that's easy to
> type on their keyboard. On a German keyboard,
On 13 Mar 2001, Daniel Pittman wrote:
> As such, I want to propose an alternate tag to indicate our own
> paths:
>
>"/!/"
Seconded. People might wish to change it to something that's easy to
type on their keyboard. On a German keyboard, I think "/&/" is easy
to type. ("/" is shift-7 and
I have been thinking on the issue of TRAMP and it's interference with
EFS/Ange-FTP file handlers.
As a result of this, I went and took a look at the patters that are
absorbed by these two packages.
Both of them define that any path matching "/[^/]:" belongs to them.
This is, I think, a little un
36 matches
Mail list logo
