From: sirjofri <firstname.lastname@example.org> To: email@example.com Subject: [9front] wloc - rc doesn't work because of pid Date: Wed, 11 May 2022 08:44:17 +0000 (UTC) [thread overview] Message-ID: <firstname.lastname@example.org> (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 \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: [9front] wloc - rc doesn'\''t work because of pid' \ /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
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).