acme: Getting the address of dot

[Jamie Hall]

Hi all,

I'm trying to work out the best way to get the address (ideally as character offsets into the window) of the current selection. Using 9fans.net/go/acme, I would have thought the following code would return the address of the selection:

err := win.Ctl("addr=dot")

// handle error

start, end, err := win.ReadAddr()

// handle err

However, this always returns 0, 0, nil. I've tried taking the same actions manually by reading the filesystem, but get the same results. The manual page for the acme filesystem (https://man.cat-v.org/plan_9/4/acme) suggests this is the right approach. Am I missing something?

[Jacob Vosmaer]

I've run into the same problem. It seems that 'addr=dot' correctly updates w->addr.q0 and q1, but then something somewhere resets them to 0, 0.

Op zo 25 mei 2025 om 15:39 schreef Jamie Hall <the.sl...@gmail.com>:

--

---
You received this message because you are subscribed to the Google Groups "plan9port-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to plan9port-de...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/plan9port-dev/e41c18ab-c5ba-4fd0-b584-743c9289acf5n%40googlegroups.com.

[Mathieu Bivert]

I've ran into this as well a while ago. a (the?) trick is to have

both files opened at once:

    → echo -n 'addr=dot' | 9p write acme/686/ctl
    → 9p read acme/686/addr
              0           0

fails, but not:

    → set $(echo -n 'addr=dot' | 9p write acme/686/ctl & 9p read acme/686/addr)
    → echo $1:$2
    134:140

To view this discussion visit https://groups.google.com/d/msgid/plan9port-dev/CAHG0V4c1iFSvZc%2BfOb3MxBasExX%2BtMk4cWY2nCE83hktOAsKCg%40mail.gmail.com.

[Jamie Hall]

Ah, fantastic. I've managed to achieve the same thing using 9fans.net/go/acme by reading the address (and discarding the result) before setting addr=dot. Thanks!

[Connor Taffe]

Hi folks,

Apparently ctl acts similarly to Plan 9’s /net/tcp/clone; there’s a pattern in rc shell that works with files, the <>[fd]/path/to/file { … }

However if using plan9port without FUSE, there is not an equivalent <>[fd]{9p rw path/to/file}, that syntax simply returns two named pipes and silently ignores the fd number.

My reading of the acme library code is that the new/ctl file is opened on acme.New() and not closed until win.CloseFiles(); so win.ReadAddr() should act accordingly?

Best,

Connor Taffe

On May 25, 2025, at 10:36, Mathieu Bivert <mathieu...@gmail.com> wrote:



To view this discussion visit https://groups.google.com/d/msgid/plan9port-dev/CAENqR%3DyCe0aCHrER6rhquRjWG26z%3Dhf0mXxPw7tHYm409i%3DxyA%40mail.gmail.com.

[Jacob Vosmaer]

Is this because the 9P protocol uses some sort of "session" concept (the fid?) and the effect of "dot=addr" is local to the session?

Op ma 26 mei 2025 om 03:19 schreef Jamie Hall <the.sl...@gmail.com>:

To view this discussion visit https://groups.google.com/d/msgid/plan9port-dev/11c2388f-16a1-4d2b-891d-f6bb623fb55fn%40googlegroups.com.

[Anthony Sorace]

The “session” is the file being held open. This is trivial to do in C (or go, or most non-script programming languages), but is tricky from the shell (and many other scripting languages). Hence the clone dance to hold the file open.

(Note: http, hot https, on that clonedance link.)

On May 26, 2025, at 00:13, Jacob Vosmaer <con...@jacobvosmaer.nl> wrote:



To view this discussion visit https://groups.google.com/d/msgid/plan9port-dev/CAHG0V4epRcOhv-rmz9-cVeC%3DsGmDY9bH6%3DFGrOsai%3DmFx1nacw%40mail.gmail.com.

[Jacob Vosmaer]

Right, but there are two files here: acme/$winid/addr and acme/$winid/ctl. What binds them together?

I don't mean to be pedantic; I'm a regular user of plan9port but I have no experiene with actual plan9. I'm curious about the original concepts that plan9port is emulating.

Op ma 26 mei 2025 om 19:25 schreef Anthony Sorace <a...@9srv.net>:

To view this discussion visit https://groups.google.com/d/msgid/plan9port-dev/B41B7AB4-349D-4CF7-9501-13A2CD7AA877%409srv.net.