Zsh Mailing List Archive
Messages sorted by: Reverse Date, Date, Thread, Author

Re: 'run ahead' execution of script



From what i understand, it's not OS level; it's "Desktop Environment" level. The level that GNOME, KDE, et al live at, a few layers up the stack from the OS per se. On the Linux side, the semantics of that isn't entirely hashed out yet. For geany specifically, check out their "Sockets support" stuff, which governs how multiple geany processes interact. Looks like it's trying to be somewhat DE-agnostic. But is still primarily targeting invocation from a GUI environment, not a shell CLI.

If you want a comparison, check out the `subl` command that's part of the Sublime Text distribution. Sublime Text is an editor that's native to the Mac OS X desktop environment, but provides a `subl` command adapter that has options for integration in to command line workflows. It's aware of how a persistent app (a graphical server, basically) would interact with individual invocations from shell sessions. In particular, it has a blocking "-w" option to "wait for files to be closed before returning" that does pretty much what you're looking for here. This might be a model for extending geany to work with shell-driven editing.

Cheers,
Andrew


On 2/24/15 9:46 PM, Ray Andrews wrote:
On 02/24/2015 06:21 PM, Bart Schaefer wrote:
On Feb 24,  1:41pm, Ray Andrews wrote:
}
} I'm thinking that maybe the fact that zsh calls geany, tho
} in another window, might give it some sort of 'handle' on it

Zsh doesn't call geany in the other window.  Zsh calls geany in the same
window where zsh is, and then that geany calls the other geany using a
private protocol and hands off the file.  Zsh doesn't know about any of
this, all it can tell is that the local geany started and then stopped.

Ok, it sounds like the sensible thing.  There must be some OS level
mechanism whereby geany #2 discovers geany #1, but it sounds
like none of zsh's business.



Messages sorted by: Reverse Date, Date, Thread, Author