Re: 'run ahead' execution of script

[Andrew Janke <janke@pobox.com>]

 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.