Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#648 --wait switch for command line

open
nobody
5
2013-12-19
2013-02-24
Cameron Wright
No

It would be helpful to implement a --wait switch for invoking Geany from the command line. TextMate and other editors have this feature to allow VCS's like git to open Geany without having to create a new instance.

Discussion

  • Cameron Wright
    Cameron Wright
    2013-02-24

    • labels: --> Interface Improvements (example)
     
  • Matthew Brush
    Matthew Brush
    2013-02-24

    Can you elaborate on what `--wait` does?

     
  • Cameron Wright
    Cameron Wright
    2013-02-25

    --wait would prevent Geany from returning an exit status immediately upon being called. Currently, if no instance of Geany is running and I call it from the command line, it doesn't return an exit status until I close Geany. However, if there is already an instance running, Geany immediately returns an exit status. --wait would prevent Geany from exiting without the need to pass the -i switch to create a new instance.

     
  • Cameron Wright
    Cameron Wright
    2013-02-25

    --wait would prevent Geany from returning an exit status immediately upon being called. Currently, if no instance of Geany is running and I call it from the command line, it doesn't return an exit status until I close Geany. However, if there is already an instance running, Geany immediately returns an exit status. --wait would prevent Geany from exiting without the need to pass the -i switch to create a new instance.

     
  • memeplex
    memeplex
    2013-12-06

    Thumbs up for this. Geany is lightweight but not as featherweight as to be popping up disposable instances.

     
  • memeplex
    memeplex
    2013-12-06

    Also temporarily open a single file with all widgets hidden could play bad with your working session layout depending on timing issues, although in general it's not expected that these temporary instances survive the main one. There is the possibility to use two different config dirs, of course, albeit a bit cumbersome.

     
  • Matthew Brush
    Matthew Brush
    2013-12-06

    I use this for Git editor and it works really good:
    core.editor=geany -c ~/.config/geany-git-editor -imnst

     
  • memeplex
    memeplex
    2013-12-06

    Me too, mostly, but it's rough with older machines and low-end portable devices, as netbooks. Also it requires keeping two configurations in sync.

    There are plenty of use cases besides the git one. Just to name a couple: ipython %ed, r fix()/edit(). Of course, you can always get blocking behavior with something as simple as:

    geany "$@" &
    echo Press Enter after saving...
    read
    

    But it would be more elegant, safer, and would require one less key press, to just wait on a tab to close. I'm not sure if this can be implemented with a plugin.

     
    • Matthew Brush
      Matthew Brush
      2013-12-07

      <insert expletives="" about="" source="" forge="" eating="" another="" one="" of="" my="" messages="">

      Is it really slow on those less powerful machines? You might like to make a bug report about that since we do claim to be fast and lightweight, but it's entirely likely there are opportunities to significantly speed-up startup time that we just haven't worked on or noticed from using faster machines. I can say that it starts up instantly from my solid state drive into my 8GB of DDR3 RAM using my multi-core CPU :)

       
  • Lex Trotman
    Lex Trotman
    2013-12-06

    Both solutions require a second copy of Geany to stick around.

    So the only extra cost of Matthews solution over --wait is that it opens a second window rather than intruding on your current session.

    Geany only loads filetypes that the session uses so a second instance would only load filetypes.common for git editing, or R or Python filetypes if you used them.

    It is also a good idea to have separate configurations for each of these uses so the settings are preserved (like indent 4 spaces and other PEP8 rules can be set for python).

     
  • memeplex
    memeplex
    2013-12-06

    Afaics the proposal is to open a new tab in a running instance and wait for it to close. In what sense there is a second copy in Cameron's solution?

     
    Last edit: memeplex 2013-12-06
  • Lex Trotman
    Lex Trotman
    2013-12-06

    It runs a second copy of Geany to wait for the first to finish with the window and then return the exit status.

     
  • memeplex
    memeplex
    2013-12-06

    Sure but the point is that the second process is a small do-nothing client instead of a full blown geany launch.

     
  • Lex Trotman
    Lex Trotman
    2013-12-06

    Well, sure its possible to have a separate command that knows the protocol to talk to a running Geany instance, and which knows how to start it if it isn't running. Possibly it will be smaller than the data of a second copy of Geany which is likely to share the executable with the running copy.

    And it would still need the modifications in Geany to signal back when the window is closed.

    But "somebody" has to do it, and keep it in sync with the Geany protocol as well.

    With Matthews solution I should have noted that the extra cost is only the top level window and menus, the cost of the editing tab would of course be incurred in the running copy in the other case.

     
  • Although I believe suggestions here (launching a second instance with different configuration and maybe with plugins and other disabled) prefectly fit the use case, you can implement what you're searching for with a small script using only current Geany features:

    #!/bin/sh
    
    file=$(readlink -f "$1")
    geany "$file"
    while geany --list-documents | grep -q -F -x -e "$file"; do
      sleep 1
    done
    

    I believe it is somewhat confusing that the caller waits for a document to close, but maybe it's only because I'm used to typical UNIX process lifetimes. Anyway, the script above should do what you want (its basically untested though, I just wrote it).

     
  • memeplex
    memeplex
    2013-12-06

    @Colomban, that's great! It's similar to my workaround above, just that I didn't know of the --list-documents option. Simple and pragmatic solution. I could add the recipe to the wiki, after testing it a bit.

    @Lex, the main goal here is to reduce startup time, specially in older or low-end machines (believe me, it becomes noticeable when my netbook is popping up geanies from my r session all the time), while keeping the blocking behavior most console applications assume and rely on. The client could skip almost all initialization.

     
  • memeplex
    memeplex
    2013-12-06

    Just in case I checked that the list of documents was being built and returned early during initialization and it indeed is. So even polling is pretty efficient, resource usage for the loop is low and the list of documents is returned in about 0.02 seconds.

    Regarding the "somebody" above, I'm confident that I could patch main.c in order --wait to do a similar polling but without launching a new process each time (as in the bash implementation). OTOH, I don't know anything about the geany API at this moment, so implementing the same thing but as a signal handler will require some time, patience and help. I noticed there is a Signals plugin, maybe it's a starting point. But, anyway, I don't see the point of going that way.

     
  • memeplex
    memeplex
    2013-12-06

    I've been testing the Colomban workaround. There is a problem that has to do with geany --list-documents launching a new full-fledged geany instance when there isn't another one currently running. In fact, it doesn't even return the list of documents after closing the new instance, it behaves as if it were a no args geany invocation. The problem with this is that you can't wait for the tab or the entire editor to close with something like:

    while pgrep geany && \
         geany --list-documents | grep -qFx "$filename"
    do
        sleep 0.5
    done
    

    Sometimes pgrep finds a geany instance that is closing but still alive, then at the point geany --list-documents is called that instance doesn't exist anymore and a new one is launched instead. As you can't make the entire test atomic, the only way out of this I can figure out is to make geany --list-documents return "\n" and immediately finish when no other geany instance is currently running.

    That sounds consistent with POLS also. Geany man page states "This [--list-documents] can be used to read the currently opened documents in Geany from an external script or tool...". But the current behavior is not very amenable to automation because it depends on a context (another geany running or not) that can't be reliably checked (because of non atomicity).

     
    Last edit: memeplex 2013-12-06
  • memeplex
    memeplex
    2013-12-07

    On Fri, Dec 6, 2013 at 11:03 PM, Matthew Brush

    Is it really slow on those less powerful machines?

    With this computer:

    Model name: Intel(R) Atom(TM) CPU N450 @ 1.66GHz
    MemTotal: 2057652 kB

    it takes geany about 2 seconds to start. It's not really slow for an editor of its capabilities. Indeed it's pretty fast. It's just the "quick edit" use case, which is not the main target of geany anyway. But I think that making --list-documents return an empty list when no other instance is running will enhance Colomban's suggestion and, all in all, make for a good solution at almost zero cost. Also, it doesn't look that hard to implement the same in C, it's just about querying a list repeatedly to the running instance and searching for a string in it. You can do this a number of times per second without sacrificing performance. The bash script plus the --list-documents minor change is fine for me. But I could write a patch for both --list-documents and polling in C if there is some interest in this.

     
    Last edit: memeplex 2013-12-07