Any workarounds/solutions for long paths in acme tags?

[vbnut]

I recently started working on a project where the paths to the source
files are long (~140 characters) so the right end of the path, where
the most important part is, isn't visible unless the tag is multiple
lines. When I have a bunch of files open in a column, most of the
tags are shrunk to one line, making painful to identify which tag is
for the file I want to switch to.

IIRC, when this was discussed on the 9fans, the solution was to use
name spaces to make the paths shorter, but I'm working in a linux
environment so that alternative isn't available.

Can anyone suggest a workaround or solution to address this issue in a
normal linux environment? Would it make sense to modify P9P acme to
address this issue?

FWIW, wily (an acme clone) addressed the issue by looking for the
environment variables that matched the longest prefix of the path and
using the environment variable in the tag. As a result, I could set
environment variables to point at directories of interest. This, of
course, also required modifications to the button3 handler to deal
with the environment variables.

Thanks.

[Russ Cox]

I added wily's $ handling in p9p acme before we had
multiline tags, and it caused a bunch of problems.
Multiline tags seemed like a better solution.
But I admit I do not work with 140-character file names
(are they tweets?).

On Unix you can use symlinks to shorten the names,
instead of binds like on Plan 9.

Russ

[vbnut]

Thanks Russ.

On Feb 4, 3:19 pm, Russ Cox <r...@swtch.com> wrote:
> But I admit I do not work with 140-character file names
> (are they tweets?).

No, just the result of the file organization conventions for a project
using multiple programming languages combined with the conventions for
specific programming languages (e.g. Java) and finding myself opening
30 to 40 files in a single column. I've been using acme for years,
and this is the first time I've encounter this issue to the extent
that it was an impediment.

> On Unix you can use symlinks to shorten the names,
> instead of binds like on Plan 9.

That was what I thought of too, but I was hoping there might be
something better.

[Ethan Grammatikidis]

On Sat, 4 Feb 2012 18:19:40 -0500
Russ Cox <r...@swtch.com> wrote:

> I added wily's $ handling in p9p acme before we had
> multiline tags, and it caused a bunch of problems.
> Multiline tags seemed like a better solution.

Off the top of your head do you think stripping acme's pwd from the tag
would cause the same problems?

I'm asking because between fonts large enough for my eyes and sometimes
using a 1024x768 screen even multi-line tags sometimes look a little
large, especially when I want to keep an eye on some chat as well as,
say, 3 files.

[vbnut]

Russ, I've been looking forward to seeing your response to Ethan's
question. Did I miss it somehow?

[Russ Cox]

On Wednesday, March 21, 2012 at 9:19 AM, Ethan Grammatikidis wrote:
> Off the top of your head do you think stripping acme's pwd from the tag
> would cause the same problems?
>
> I'm asking because between fonts large enough for my eyes and sometimes
> using a 1024x768 screen even multi-line tags sometimes look a little
> large, especially when I want to keep an eye on some chat as well as,
> say, 3 files.

(Sorry for the very late reply.)

That sounds reasonable to do in a local copy, assuming there are no symlinks to make the pwd and the path prefix different. I wouldn't want it in acme proper, I don't think, because it would create two classes of paths.

Russ

[roger peppe]

I once made a version of acme that had a filename (the "current
directory") in the topmost
tag. The tags for any files under that directory were shown relative
to the current directory.
I wasn't convinced (and there were bugs I couldn't find), so I abandoned it.

Still, when I've got 30 files all open in the same deep directory, I
think it would be nice
to do a little better.

[roger peppe]

ha, just noticed the date of the original - shows how often I check
this ML!