9front - general discussion about 9front
 help / color / mirror / Atom feed
From: sirjofri <sirjofri+ml-9front@sirjofri.de>
To: 9front@9front.org
Subject: [9front] wloc - rc doesn't work because of pid
Date: Wed, 11 May 2022 08:44:17 +0000 (UTC)	[thread overview]
Message-ID: <94b96400-a26e-4fda-9c38-942c2ec0cf62@sirjofri.de> (raw)

Good morning,

> contains several window commands generated by wloc.

- rio(1)

However, wloc uses the window labels to construct the commands, and rc 
labels contain the pid by default. Thus it's impossible to restore 
existing rc windows without relabelling them manually before running 
wloc.

Imo using labels to reconstruct windows isn't a good design. The only way 
to accurately restore windows is by labelling the windows when running 
applications, therefore using the windows label as some kinda 'dump' 
place (like acme Dump/Load). This can conflict with user intentions for 
custom labels.

Restoring rc windows can currently only work by running a command 
beforehand, e. g. the label command or a shell script/program controlling 
the label. However, the label is also used for display in winwatch, which 
can cause issues with workflows (e. g. I use labels in winwatch to 
describe the namespace of that window, which breaks the workflow for 
wloc).

The only out-of-the-box-solution I can currently think of is, removing 
the pid from a default rc session label.

(If you don't want to read a different design idea, you can skip to the 
end at this point.)

If I were to design a better way around that, I'd probably give rio 
windows another file (dump) which can be controlled by an application and 
is used instead of the label. The dump line would be a complete command 
to partially restore the full session, including namespace, label, and 
potentially state.

A gridchat rc session could for example put the string

   rc -c 'label gridchat; 9fs net!chat.9p.zone!9999 /n/chat'

inside the dump file, which is then used by wloc to construct the line

   window -r x y a b rc -c 'label gridchat; 9fs ...'

... you get the idea.

The design would work, but would probably also break compatibility with 
other 9 systems. However, it would also work as an addition (don't use 
wloc, but name it differently, original 9 tools can just ignore the dump 
file).

sirjofri

             reply	other threads:[~2022-05-11  8:46 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-11  8:44 sirjofri [this message]
2022-05-11  9:49 ` umbraticus
2022-05-11 11:06   ` sirjofri
2022-05-11 11:08     ` sirjofri
2022-05-11 11:45       ` mkf9

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=94b96400-a26e-4fda-9c38-942c2ec0cf62@sirjofri.de \
    --to=sirjofri+ml-9front@sirjofri.de \
    --cc=9front@9front.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).