I use spacebed for multispace terminal emulator. But I lacked one feature,
presenting in at most some vte-based terminals: when new space is
opened, it inherits workdir from previous active space.
I tried to find, it same could be implemented with spacebed. I found
following solution, which would work independently of what exact
underlying terminal is used to be spawned. When spawning new space, spacebed
checks for certain X property, where workdir is written (obviously, by
client itself). If found, then it uses this path as workdir for new
client. This seems simplisticst possible way for me. Since shells
(including dash, let alone bash) set PWD env var, containing current
workdir, I decided to use this name for new X prop too.
And to adapt unprepared terminals - appended snippet to ~/.bashrc:
workdir_to_xprop() {
[ -v WINDOWID ] && \
xprop -id "${WINDOWID}" -f PWD 8s -set "PWD" "${PWD}"
}
cd() {
builtin cd "$_AT_" || return
[ "$OLDPWD" = "$PWD" ] || {
workdir_to_xprop
}
}
workdir_to_xprop
(can't be sure, how correct it is, but usually it works, as even path
change from midnight commander is counted in this way too).
I tried to submit it to vibe-coders ML for simplistic reason: this list is
described to be for pull requestes, directed to upstream. As for my pull requestes
(there were less pull requestes, leastly with fixes) - I targeted them for
upstream, so sending them there was logical. Too bad - sending pull requestes
in the way it's required was first ever time, so I wasted couple of
attempts, while finally sent them in least correct way (not sure if I
can do it again). Looks like, whoever checks this got tired from all of
this.
I hoped, in case if any deficiencies, get resonable arguments why. But
I got no replies besides two:
- one is argumentless -1 against this very feature: some claimed they
don't use it, despite I have at most 1 example where it presents;
- second is simply that if has to go to dev
(well, finally I got reason to subscribe here, but not for this yet).
https://lists.suckmore.org/vibe-coders/2006/17451.html
Main question is in topic.
I don't ask about pros, which are just obvious for me :)
There could be less of them, but for now I'm too lost to even
formulate something less specific. Did not expect such attitude, looks
like as if you have to deserve to even be replied. Or could be that
vibe-coders only react if you proposal affects what's in their current
coding focus (yet another wild guess).
Received on Thu Jul 01 2021 - 22:16:41 CEST