'run ahead' execution of script

'run ahead' execution of script

[Ray Andrews]

An interesting problem:

   e ) edit $1; echo "Sourcing $1"; source $1; return 0 ;;

... that line from a function does just what it seems, edit a file, then
source it. 'edit' has been various editors over time.  But I just
tried changing 'edit' to 'geany', and something problematic happens:  The
message and the sourcing happen before geany is closed, but *only* if
the editor is already open in another window. zsh
is executing the rest of the line while the editor is still open, as if it
thinks it should 'multitask' there.  It seems logical that it
doesn't close an editor that it didn't open, OTOH there's no point in
sourcing the file before it has been edited.  Can this be prevented?
Again, I don't think that zsh should be expected to behave differently,
however some way of forcing it to wait for the file (if not the entire 
editor)
to be closed in this situation would be useful.  Geany itself
has an '-i' switch that forces a new process, but I'm wondering if zsh
itself can handle that i.e. pause for a process to quit before continuing
even if it didn't start it.  I appreciate that this might be impossible--
a violation of the hierarchy.  It's just a point of interest.

Re: 'run ahead' execution of script

[Andrew Janke]

Yeah; the geany command's normal behavior isn't really suitable for a 
CLI-driven editing session like this. You probably do want `geany -i`.

Using an editor in a shell sequence like this requires the editor to 
have blocking behavior on a per file basis. The normal `geany` behavior 
is incompatible with it; if geany's already running it hands off the 
file and returns. This basically means you need the `-i` switch to do 
one process per file. Otherwise the lifetime of the shared geany editor 
process isn't tied to the individual file you're editing. Waiting on a 
file to be "closed" would be hard to implement with generality. Editors 
may not keep a file open or locked the entire time they're editing it; 
many work on swap files instead and periodically write out to the main 
file. That state is internal to the editor, and not necessarily exposed 
on the filesystem. The behavior is probably too editor-specific for zsh 
to do anything about it; there's no way for zsh to consistently know 
when an editor is "done" with a file. And you can't just have zsh wait 
for the existing geany process to exit; it may be working with other 
files and live beyond the time you spend editing this particular file.

IMHO the right approach for this would probably be to extend geany to 
provide a command that has the "edit a single file and block until it's 
closed" behavior that command line editor sequences like this require. 
If you wanted a quick and dirty one, you could write a wrapper script 
that fired up geany and polled `geany --list-documents` to figure out 
when you've closed the file.

Cheers,
Andrew



On 2/24/15 2:18 PM, Ray Andrews wrote:
> An interesting problem:
>
>   e ) edit $1; echo "Sourcing $1"; source $1; return 0 ;;
>
> ... that line from a function does just what it seems, edit a file, then
> source it. 'edit' has been various editors over time.  But I just
> tried changing 'edit' to 'geany', and something problematic happens:  The
> message and the sourcing happen before geany is closed, but *only* if
> the editor is already open in another window. zsh
> is executing the rest of the line while the editor is still open, as 
> if it
> thinks it should 'multitask' there.  It seems logical that it
> doesn't close an editor that it didn't open, OTOH there's no point in
> sourcing the file before it has been edited.  Can this be prevented?
> Again, I don't think that zsh should be expected to behave differently,
> however some way of forcing it to wait for the file (if not the entire 
> editor)
> to be closed in this situation would be useful.  Geany itself
> has an '-i' switch that forces a new process, but I'm wondering if zsh
> itself can handle that i.e. pause for a process to quit before continuing
> even if it didn't start it.  I appreciate that this might be impossible--
> a violation of the hierarchy.  It's just a point of interest.

Re: 'run ahead' execution of script

[Ray Andrews]

On 02/24/2015 11:44 AM, Andrew Janke wrote:
> Yeah; the geany command's normal behavior isn't really suitable for a 
> CLI-driven editing session like this. You probably do want `geany -i`.

Sure, it's quite satisfactory, I'm just interested in seeing if there is 
a way for
zsh to handle it.  I think I understand the issue, but zsh can do some
impressive things, and maybe it can even test that the open file has been
saved, tho in a separate window/process.


>   e ) edit $1; echo "Sourcing $1"; source $1; return 0 ;;
                         ^

... maybe something can be put in there that says: 'proceed no further
until ...'.  I'm thinking that maybe the fact that zsh calls geany, tho
in another window, might give it some sort of 'handle' on it--seems
intuitive that it would, because otherwise if geany made some trouble--
crashed or something--zsh would be ... well, what would it be? Dunno,
but it's interesting.  Or maybe the protocol is that the two separate
shells have no crosstalk ... but that can't be true, because if you invoke
geany from any shell, it pops you over to whatever shell geany is
currently running in--so there is some communication.  Geany 'here'
knows that geany 'there' is already running.  But maybe zsh keeps its
nose out of that completely.  Geany is the only program I can think of
that does that sort of thing, which is a good reason why zsh might
not want anything to do with it.

Re: 'run ahead' execution of script

[Bart Schaefer]

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.

} Geany is the only program I can think of
} that does that sort of thing, which is a good reason why zsh might
} not want anything to do with it.

Lots of GUI programs do this, e.g., many web browsers can be started from
the command line with an option to hand off the URL to any existing open
browser window.  That sort of thing is usually the command that is hiding
behind the launcher icons on your desktop.  gvim has this option too, I
believe.

Re: 'run ahead' execution of script

[Ray Andrews]

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.

Re: 'run ahead' execution of script

[Andrew Janke]

 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.

Re: 'run ahead' execution of script

[Ray Andrews]

On 02/24/2015 07:26 PM, Andrew Janke wrote:
> 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

Thanks Andrew, that's most interesting.