Re: [9fans] Resizing acme tags in plan9 - Plan9

This is a discussion on Re: [9fans] Resizing acme tags in plan9 - Plan9 ; 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 ...

+ Reply to Thread
Results 1 to 7 of 7

Thread: Re: [9fans] Resizing acme tags in plan9

  1. Re: [9fans] Resizing acme tags in plan9

    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

  2. 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

  3. Re: [9fans] Resizing acme tags in plan9


  4. Re: [9fans] Resizing acme tags in plan9

    hola,

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

    ....

    On 1/13/07, Gregory Pavelcak wrote:
    >
    >
    > ---------- Forwarded message ----------
    > From: "ron minnich"
    > 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

  5. Re: [9fans] Resizing acme tags in plan9

    > 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


  6. Re: [9fans] Resizing acme tags in plan9

    > 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


  7. Re: [9fans] Resizing acme tags in plan9

    > 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


+ Reply to Thread