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
next 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).