* 'run ahead' execution of script @ 2015-02-24 19:18 Ray Andrews 2015-02-24 19:44 ` Andrew Janke 0 siblings, 1 reply; 7+ messages in thread From: Ray Andrews @ 2015-02-24 19:18 UTC (permalink / raw) To: Zsh Users 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: 'run ahead' execution of script 2015-02-24 19:18 'run ahead' execution of script Ray Andrews @ 2015-02-24 19:44 ` Andrew Janke 2015-02-24 21:41 ` Ray Andrews 0 siblings, 1 reply; 7+ messages in thread From: Andrew Janke @ 2015-02-24 19:44 UTC (permalink / raw) To: Ray Andrews, Zsh Users 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: 'run ahead' execution of script 2015-02-24 19:44 ` Andrew Janke @ 2015-02-24 21:41 ` Ray Andrews 2015-02-25 2:21 ` Bart Schaefer 0 siblings, 1 reply; 7+ messages in thread From: Ray Andrews @ 2015-02-24 21:41 UTC (permalink / raw) To: zsh-users 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: 'run ahead' execution of script 2015-02-24 21:41 ` Ray Andrews @ 2015-02-25 2:21 ` Bart Schaefer 2015-02-25 2:46 ` Ray Andrews 0 siblings, 1 reply; 7+ messages in thread From: Bart Schaefer @ 2015-02-25 2:21 UTC (permalink / raw) To: zsh-users 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: 'run ahead' execution of script 2015-02-25 2:21 ` Bart Schaefer @ 2015-02-25 2:46 ` Ray Andrews 2015-02-25 3:26 ` Andrew Janke 0 siblings, 1 reply; 7+ messages in thread From: Ray Andrews @ 2015-02-25 2:46 UTC (permalink / raw) To: zsh-users 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: 'run ahead' execution of script 2015-02-25 2:46 ` Ray Andrews @ 2015-02-25 3:26 ` Andrew Janke 2015-02-25 5:09 ` Ray Andrews 0 siblings, 1 reply; 7+ messages in thread From: Andrew Janke @ 2015-02-25 3:26 UTC (permalink / raw) To: Ray Andrews, zsh-users 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: 'run ahead' execution of script 2015-02-25 3:26 ` Andrew Janke @ 2015-02-25 5:09 ` Ray Andrews 0 siblings, 0 replies; 7+ messages in thread From: Ray Andrews @ 2015-02-25 5:09 UTC (permalink / raw) To: zsh-users 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2015-02-25 5:09 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-02-24 19:18 'run ahead' execution of script Ray Andrews 2015-02-24 19:44 ` Andrew Janke 2015-02-24 21:41 ` Ray Andrews 2015-02-25 2:21 ` Bart Schaefer 2015-02-25 2:46 ` Ray Andrews 2015-02-25 3:26 ` Andrew Janke 2015-02-25 5:09 ` Ray Andrews
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/zsh/ 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).