Re: [9fans] Resizing acme tags in plan9

Re: [9fans] Resizing acme tags in plan9

[erik quanstrom]

you're talking about the layout within columns, not the layout
of the columns from left to right, right?

within columns, it would be nice if new windows were sometimes
opened below the last one touched.  perhaps i should always work
at the bottom of a column, but i don't.  zerox nearly always
chooses the wrong place for the new window -- all the way at the
bottom.

among columns, it would be nice if the column guide box (or
whatever it's called) worked like the window guide box.
clicking on it should expand the column horizontally.

one thing i would like to see added to acme is a win-like program
implementing an analog to the sam command window.  though it might
require some acme(4) rework.  currently it's quite painful to
stop everything and do a mass edit.

- erik

Re: [9fans] Resizing acme tags in plan9

[ron minnich]

OK, the person who asked for this may be afraid to ask the list. So I will.

For directory windows, they'd like a way to right-click on an item and
have the current window closed and replaced with the directory. They
don't want their acme session to get so cluttered.

I have no idea how hard this is.

BTW, thanks for the multi-line tags. Once I had that, a task I had to
do (converting several thousand lines of assembly to C) took little
time at all.

ron

Re: [9fans] Resizing acme tags in plan9

[Gregory Pavelcak]

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

I'm almost certain someone has done this.
Searching 9fans archives might solve this one.

Greg

[-- Attachment #2: Type: message/rfc822, Size: 3561 bytes --]

From: "ron minnich" <rminnich@gmail.com>
To: "Fans of the OS Plan 9 from Bell Labs" <9fans@cse.psu.edu>
Cc: 
Subject: Re: [9fans] Resizing acme tags in plan9
Date: Sat, 13 Jan 2007 07:31:25 -0700
Message-ID: <13426df10701130631t5ffd1266u8c9249751672c273@mail.gmail.com>

OK, the person who asked for this may be afraid to ask the list. So I will.

For directory windows, they'd like a way to right-click on an item and
have the current window closed and replaced with the directory. They
don't want their acme session to get so cluttered.

I have no idea how hard this is.

BTW, thanks for the multi-line tags. Once I had that, a task I had to
do (converting several thousand lines of assembly to C) took little
time at all.

ron

Re: [9fans] Resizing acme tags in plan9

[Federico Benavento]

hola,

http://9fans.net/archive/2003/03/15

...

On 1/13/07, Gregory Pavelcak <g.pavelcak@comcast.net> wrote:
>
>
> ---------- Forwarded message ----------
> From: "ron minnich" <rminnich@gmail.com>
> To: "Fans of the OS Plan 9 from Bell Labs" <9fans@cse.psu.edu>
> Date: Sat, 13 Jan 2007 07:31:25 -0700
> Subject: Re: [9fans] Resizing acme tags in plan9
> OK, the person who asked for this may be afraid to ask the list. So I will.
>
> For directory windows, they'd like a way to right-click on an item and
> have the current window closed and replaced with the directory. They
> don't want their acme session to get so cluttered.
>
> I have no idea how hard this is.
>
> BTW, thanks for the multi-line tags. Once I had that, a task I had to
> do (converting several thousand lines of assembly to C) took little
> time at all.
>
> ron
>
>
>


--
Federico G. Benavento

Re: [9fans] Resizing acme tags in plan9

[lucio]

> BTW, thanks for the multi-line tags. Once I had that, a task I had to
> do (converting several thousand lines of assembly to C) took little
> time at all.

What does the convergence of ACME and SAM actually look like?  It
seems to me that we could design the new generation Plan 9 editor from
the building blocks already provided instead of exploring the
labyrinth of possible options and unavoidable dead ends.

Typically, I think ACME's filesystem is fundamental to a Plan 9 editor
whereas window-pane placement ought to be controlled by individual
user preferences, particularly the heuristics.  To me, the expanded
tag is a SAM feature (hopefully) well integrated into ACME: I would
prefer if it resembled the SAM version a little more closely.

I also find SAM's remote editing ability very convenient, but in ACME
it may be better to implement this by separating the filesystem from
the editing commands so that remote editing can be done by applying
instructions to a remote ACME fileserver.  Not that I know what I'm
talking about, but it seems an option from a distance.

A feature that has been bothering me for a while is more applicable to
the shell, but perhaps it's worth presenting here.  Given a file
server and command interpreter, not unlike ACME's role, one could have
a virtual "bin" directory which contains scripts in the interpreted
language.  The ability to bind additional scripts to this directory
would provide something resembling "loadable modules".  Those scripts
that are compiled into the binary would in effect be "built-in".  The
idea came to me when trying to understand the various Plan 9 kernels
and my immediate thinking was "rc" and "tcl".  Has this idea ever
struck anyone else?  Has anyone implemented anything of this nature?

++L

Re: [9fans] Resizing acme tags in plan9

[Tim Wiess]

> I also find SAM's remote editing ability very convenient, but in ACME
> it may be better to implement this by separating the filesystem from
> the editing commands so that remote editing can be done by applying
> instructions to a remote ACME fileserver.  Not that I know what I'm
> talking about, but it seems an option from a distance.

    i've been thinking about this a lot lately and am planning on
    really starting to look into now as a little more free time has
    come up.

    i always thought about making the changes in the filesystem.
    to be able to have certain windows (fs directories) bound to local
    files and others bound to remote files.  reads/writes on the
    latter would be translated to a sam-like protocol and sent to
    the other host.  your first remote window could be started with
    something like 'New hostname', which would bring up a directory
    window.

    tim

Re: [9fans] Resizing acme tags in plan9

[lucio]

>     i always thought about making the changes in the filesystem.
>     to be able to have certain windows (fs directories) bound to local
>     files and others bound to remote files.  reads/writes on the
>     latter would be translated to a sam-like protocol and sent to
>     the other host.  your first remote window could be started with
>     something like 'New hostname', which would bring up a directory
>     window.

There are edits (for want of a better name) that can be applied,
sed-like, to a view of the file (or even multiple views of open files)
while there are others that need a more direct application.  It
doesn't seem possible to combine these into a single, more general
operation.

I think it is unfortunate that "brief" was based on "emacs" and that
therefore it shared in the latter's reputation, I think there were
some valuable concepts in brief that were discarded for the wrong
reasons.

A New Generation editor would consist, in my uneducated opinion, of a
presentation function responsible for interaction with the user
(display, keystrokes and mouse events, opening and closing files,
maintaining the user preferences - RIO already performs most of the
critical functions in this list), an editing engine that modifies the
given text (selection) by applying (a sequence of) atomic editing
functions to it (this, according to my reading of the ACME and SAM
documentation is a core function, but it is presently integrated with
the presentation) and an interpreter that allows scripting of all the
underlying operations (this is the bit I'd borrow from "brief", or
"emacs", if anyone feels strongly about it).  These components would
comunicate using both interprocess communication and various virtual
files provided by the file server, which may well be a totally
distinct function, quite uncoupled from the the rest.

But I'm expecting many different opinions on this score: the perfect
editor is full of conflicting requirements and its most important
property is that it must be able to satisfy the needs of one user
without sacrificing its ability to be customised to a different user's
preferences.

One can achieve an apparent degree of customisation through
configuration files, but only a scripting language can provide a
dynamic environment that deals with changing external conditions.
Specifically, I'm thinking of the user being able to specify different
execution paths depending on different circumstances.  Structured
Regular Expressions are a powerful editing tool in this context, but
their power has some very firm boundaries.

I've always appreciated Tcl's idea of embedding the scripting language
in the application, it is only its building bricks that I found a
little disappointing.

I'm expecting that all the original effort that went into ACME will be
retained in a future editor.  Also, let us not forget the plumber,
which ought to be integrated as an important communication channel.
And, having been reminded that the plumber has its roots in Inferno,
perhaps Limbo ought to be the scripting language of choice.  That, or
the language implemented by the new Inferno shell.

++L

[9fans] Resizing acme tags in plan9

[Paul Lalonde]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

The P9P version of acme has had multi-line tags for a while now, but
there is still a "bug" lurking in the implementation; it's a bit of a
semantic issue with allocating lines of pixels to the various
windows, which I'll get to below.  The bug manifests as occasional
black lines between windows in a column, and minor confusion when a
bunch of collapsed (tag-only) windows cluster at the bottom of a
column.  I'll explain the confusion in a bit.  The bug only manifests
if you mix fonts within a column.

When I implemented the resizing tags, I chose to never let a change
in the tag size change the layout of a column; doing otherwise causes
seriously non-intuitive and annoying behaviour as windows below your
current window move around.  Instead, tags are limited to using up
the current window's space.  Sounds simple enough.  But when the tag
and the body don't use the same height of font, you wind up with some
wasted lines of pixels at the bottom of the body: space left over
from expanding the tag where a line of the different-sized font no
longer fits.  And you *really* don't want to re-flow the rest of the
column to fit, as tag changes then move around other windows.

Now, as background, note that acme does a good job of allocating rows
of pixels to windows; there's only ever a surplus at the bottom of a
column in Rob's version, but my hack changes that.  And a lot of the
layout algorithm relies on that close packing, and being able to
calculate how many lines a set of windows takes up (body lines * body
font height + tag height + borders), which is no longer accurate
after I've gone and mashed the tags.  Grumble.  And that count
getting out of sync with reality (by having lots of these "void"
sections in a column) causes the bottom-of-column loss of windows.

And that makes it sound like I could just fix this code.  But the
layout code is subtle and quick to anger - it does a greedy pass
through the windows and makes a lot of assumptions interchanging line
counts with window heights - Acme's layout is definitely line-
oriented, not panel-oriented.  And that is commingled with the column
layout heuristics, which are tuned in that code and I don't believe
described anywhere else.

But I want my multi-line tags in Acme on Plan9, especially now that
it's running so sweetly on my MacBookPro.

So I'm willing over the next few months to re-build the column layout
code to handle the tags properly, but I don't know what people expect
in column layout.  I'm willing to take reports both of behaviours
people expect, like, and would like to see, as I try to make
something with expanding tags that's good enough to replace the
current Acme in the Plan9 distro.

Thoughts from anyone?  Words of wisdom?

Thanks,
     Paul

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (Darwin)

iD8DBQFFp+OupJeHo/Fbu1wRAtC6AJ0c7Qr1cJps964E4CE5dtio0oZXnwCgr87R
EamQ3kuYjnxgcKcYYlKP4OM=
=L/oM
-----END PGP SIGNATURE-----