Re: [9fans] long paths in acme tags

Re: [9fans] long paths in acme tags

[sl]

>> > this was done in wily in the mid 90s, complete with an algorithm
>> > to find the shortest representation.
>>
>> What was the result? In which distribution is it available? How is
>> it used?
>
> wily was a stand-alone unix program.  iirc it relied on the frame library
> port from plan 9.

Sorry, my fault, I somehow missed "wily" in your original reply.

sl

Re: [9fans] long paths in acme tags

[Bakul Shah]

On Thu, 12 Jun 2014 00:23:20 +0200 Nicolas Bercher <nbercher@yahoo.fr> wrote:
> On 11/06/2014 23:32, Bakul Shah wrote:
> > On Wed, 11 Jun 2014 22:27:34 BST Robert Raschke <rtrlists@googlemail.com> w
> rote:
> >>
> >> Whenever they are available, I use symlinks for "shortening" paths for
> >> Acme. This is so far the only good use I've found for them ;-)
> >
> > Symlinks don't help in the tag as pwd finds the real path.
>
> Which pwd are you talking about?
> GNU's pwd does not resolve symlinks (pwd -P does), nor p9p's acme.

This could be your shell's builtin pwd command. Try /bin/pwd

Try this on MacOS in an acme window.

ln -s <some long path> foo
cd foo

The tag shows a rooted <some long path> not foo

And at least on the version of linux I am running, I see the
full path when I type /bin/pwd. The same on FreeBSD.

The pity is the BSD folks could've done symlinks right if only
they had changed kernel code to store the entire current
working dir path in the kernel instead of just an inode ptr
and added a getcwd() kernel call. It is pretty clear that once
you have more than one path to a directory, grubbing around in
successive parent directories to compute a path was not the
right thing to do. All you need to do is to understand that .
and .. simply define the following rules:

prefix/dir/.. == prefix
prefix/. == prefix
where dir is neither . nor ..

This would've taken away the surprising behavior of cding to
path containing .. and symlinks. Not only that you don't need
. and .. entries if you store the rooted path to cwd in the
kernel.  I was very glad to see that the Plan9 folks got rid
of the . and .. entries.

The weird shell behavior is also an artifact of the original
hack. You got different results in csh and sh.

Re: [9fans] long paths in acme tags

[Nicolas Bercher]

On 11/06/2014 23:32, Bakul Shah wrote:
> On Wed, 11 Jun 2014 22:27:34 BST Robert Raschke <rtrlists@googlemail.com> wrote:
>>
>> Whenever they are available, I use symlinks for "shortening" paths for
>> Acme. This is so far the only good use I've found for them ;-)
>
> Symlinks don't help in the tag as pwd finds the real path.

Which pwd are you talking about?
GNU's pwd does not resolve symlinks (pwd -P does), nor p9p's acme.

Nicolas

Re: [9fans] long paths in acme tags

[erik quanstrom]

On Wed Jun 11 17:34:33 EDT 2014, bakul@bitblocks.com wrote:
> On Wed, 11 Jun 2014 22:27:34 BST Robert Raschke <rtrlists@googlemail.com> wrote:
> >
> > Whenever they are available, I use symlinks for "shortening" paths for
> > Acme. This is so far the only good use I've found for them ;-)
>
> Symlinks don't help in the tag as pwd finds the real path.

"real path"?  hmmm.  symlinks aren't fake.  :-)

- erik

Re: [9fans] long paths in acme tags

[Bakul Shah]

On Wed, 11 Jun 2014 22:27:34 BST Robert Raschke <rtrlists@googlemail.com> wrote:
>
> Whenever they are available, I use symlinks for "shortening" paths for
> Acme. This is so far the only good use I've found for them ;-)

Symlinks don't help in the tag as pwd finds the real path.

Re: [9fans] long paths in acme tags

[Robert Raschke]

[-- Attachment #1: Type: text/plain, Size: 1116 bytes --]

Whenever they are available, I use symlinks for "shortening" paths for
Acme. This is so far the only good use I've found for them ;-)

Robby
 On Jun 11, 2014 8:54 PM, "Bakul Shah" <bakul@bitblocks.com> wrote:

> If you are editing multiple file within the same directory
> with a very long path, the long dir paths is what takes up
> most of the tag. One idea (borrowed from zsh) is to assign a
> long path to a variable and then just show the variable
> instead. Thus for example, given long paths like these:
>
>     /a/very/very/very/very/very/very/very/very/very/long/path/to/a/file1
>     /a/very/very/very/very/very/very/very/very/very/long/path/to/a/file2
>
> If one can define a variable in acme
>     foo=/a/very/very/very/very/very/very/very/very/very/long/path/to/a
>
> & if the acme tags show
>     $foo/file1
>     $foo/file2
> it would be much nicer.
>
> Has anyone considered doing this or is there a better idea?  I
> suppose on plan9 one can use bind for this but on p9p things
> get considerably clunkier (9p, fuse...) when a variable can do
> the job more simply.
>
>

[-- Attachment #2: Type: text/html, Size: 1433 bytes --]

Re: [9fans] long paths in acme tags

[Bakul Shah]

On Wed, 11 Jun 2014 22:33:07 +0200 =?UTF-8?B?QXJhbSBIxIN2xINybmVhbnU=?= <aram.h@mgk.ro> wrote:
> > & if the acme tags show
> >     $foo/file1
> >     $foo/file2
> > it would be much nicer.
>
> Real paths are plumbable and copyable, variable names are not. p9p
> acme (where this problem is more acute) has multiline tags.

Multiline tags don't help with the clutter. In any case I am
only talking about what is displayed in the tag.

I have never need to plumb the tag. Valid point about copying
but you can deal with that by defining similar variables in rc.

Thanks Erik, I will take a look at wily code.

Re: [9fans] long paths in acme tags

[erik quanstrom]

On Wed Jun 11 16:34:51 EDT 2014, aram.h@mgk.ro wrote:
> > & if the acme tags show
> >     $foo/file1
> >     $foo/file2
> > it would be much nicer.
>
> Real paths are plumbable and copyable, variable names are not. p9p
> acme (where this problem is more acute) has multiline tags.

both of these issues can be sorted.  there's no reason the cut text
or plumb'd text need equal the displayed text.  but one would need
to be very careful about it.

- erik

Re: [9fans] long paths in acme tags

[Aram Hăvărneanu]

> & if the acme tags show
>     $foo/file1
>     $foo/file2
> it would be much nicer.

Real paths are plumbable and copyable, variable names are not. p9p
acme (where this problem is more acute) has multiline tags.

-- 
Aram Hăvărneanu

Re: [9fans] long paths in acme tags

[erik quanstrom]

On Wed Jun 11 16:14:54 EDT 2014, sl@9front.org wrote:
> >> If one can define a variable in acme
> >>     foo=/a/very/very/very/very/very/very/very/very/very/long/path/to/a
> >>
> >> & if the acme tags show
> >>     $foo/file1
> >>     $foo/file2
> >> it would be much nicer.
> >>
> >> Has anyone considered doing this or is there a better idea?  I
> >> suppose on plan9 one can use bind for this but on p9p things
> >> get considerably clunkier (9p, fuse...) when a variable can do
> >> the job more simply.
> >
> > this was done in wily in the mid 90s, complete with an algorithm
> > to find the shortest representation.
>
> What was the result? In which distribution is it available? How is
> it used?

wily was a stand-alone unix program.  iirc it relied on the frame library
port from plan 9.

it worked, but the problem was that environment variables are not
understood by the kernel.

google "wily text editor".

- erik

Re: [9fans] long paths in acme tags

[sl]

>> If one can define a variable in acme
>>     foo=/a/very/very/very/very/very/very/very/very/very/long/path/to/a
>>
>> & if the acme tags show
>>     $foo/file1
>>     $foo/file2
>> it would be much nicer.
>>
>> Has anyone considered doing this or is there a better idea?  I
>> suppose on plan9 one can use bind for this but on p9p things
>> get considerably clunkier (9p, fuse...) when a variable can do
>> the job more simply.
>
> this was done in wily in the mid 90s, complete with an algorithm
> to find the shortest representation.

What was the result? In which distribution is it available? How is
it used?

sl

Re: [9fans] long paths in acme tags

[erik quanstrom]

On Wed Jun 11 15:56:59 EDT 2014, bakul@bitblocks.com wrote:
> If you are editing multiple file within the same directory
> with a very long path, the long dir paths is what takes up
> most of the tag. One idea (borrowed from zsh) is to assign a
> long path to a variable and then just show the variable
> instead. Thus for example, given long paths like these:
>
>     /a/very/very/very/very/very/very/very/very/very/long/path/to/a/file1
>     /a/very/very/very/very/very/very/very/very/very/long/path/to/a/file2
>
> If one can define a variable in acme
>     foo=/a/very/very/very/very/very/very/very/very/very/long/path/to/a
>
> & if the acme tags show
>     $foo/file1
>     $foo/file2
> it would be much nicer.
>
> Has anyone considered doing this or is there a better idea?  I
> suppose on plan9 one can use bind for this but on p9p things
> get considerably clunkier (9p, fuse...) when a variable can do
> the job more simply.

this was done in wily in the mid 90s, complete with an algorithm
to find the shortest representation.

- erik

[9fans] long paths in acme tags

[Bakul Shah]

If you are editing multiple file within the same directory
with a very long path, the long dir paths is what takes up
most of the tag. One idea (borrowed from zsh) is to assign a
long path to a variable and then just show the variable
instead. Thus for example, given long paths like these:

    /a/very/very/very/very/very/very/very/very/very/long/path/to/a/file1
    /a/very/very/very/very/very/very/very/very/very/long/path/to/a/file2

If one can define a variable in acme
    foo=/a/very/very/very/very/very/very/very/very/very/long/path/to/a

& if the acme tags show
    $foo/file1
    $foo/file2
it would be much nicer.

Has anyone considered doing this or is there a better idea?  I
suppose on plan9 one can use bind for this but on p9p things
get considerably clunkier (9p, fuse...) when a variable can do
the job more simply.