[Geany-devel] Proposed patch to fix issues with command line file loading
weltall2 at xxxxx
Fri Jan 28 00:15:25 UTC 2011
Well the reasoning of that is because a lot of times I end up with
having to kill geany (kill -9 or xkill) in order to not lose all the
opened files listing due to a click, so really a project is not always
the right way in this case (even more if the files come from several
projects in practice)
Il giorno ven, 28/01/2011 alle 10.29 +1100, Lex Trotman ha scritto:
> On 28 January 2011 06:09, Dimitar Zhekov <dimitar.zhekov at gmail.com> wrote:
> > On Thu, 27 Jan 2011 10:20:26 +0100
> > weltall <weltall2 at gmail.com> wrote:
> >> I've noticed various issues with file loading from command line:
> >> 1) if the option load last session is not enabled project files can't be
> >> opened from command line: this happens because the code to handle them
> >> is wrapped in a prefs.load_lastsession if so the only way to load them
> >> from command line is having that option true.
> > Certainly a bug.
> Yes, but the patch never loads the project session from a project on
> the command line since main_load_project_from_command_line is only
> ever called with FALSE?
yes it seems to not, like before, but before it didn't load project
files at all without the flag to load the previous sessions set to true
due to the fact the whole code was ifed out with the load session
> >> 2) trying to open a file (eg from double clicking in nautilus) will
> >> screw your session as command line loading of single files ignores your
> >> session opened files, except if geany was already opened.
> > SciTE will do the same, and so will UltraEdit (the very old versions I
> > used). If you want a permanent session, create a project.
> Need to support multiple default sessions. Too complicated??
Yeah that could be a solution even though It could be nice to maintain a
certain level of coherency between already opened and not.
> >> So to fix those issues I've reorganized the code in the
> >> load_startup_file function in order to:
> >> 1) load the project files ignoring the session if a project file was
> >> specified at command line
> >> 2) allow to load more files in addition to the project file (removing so
> >> the limitation imposed there artificially - possible improvement to this
> >> would be adding a flag to open_cl_files as argument in order to avoid
> > Actually, the check if argv is .geany is mainly for the file
> > managers. You associate geany with the text files, and since .geany is
> > text too, it automatically works. About the limitation of loading only
> > the project file, I'm not sure, but loading a project and opening
> > additional files at the same time does not seem very common.
> Agree, need to be careful since the extra files will be added to the
> project session which is unlikely to be what you want??
well that could be a thought... but from my tests loading a file while
geany is already running (from nautilus for example) will add that file
to the project so the behaviour is consistent at least.
> >> that pointer toying)
> >> 3) the open_cl_files is called after loading the session so the
> >> specifically selected files are opened last and so are automatically
> >> selected (what you would expect when opening a file from nautilus)
> > Personally I'd expect to open only the file I clicked, be it in
> > existing or new instance. And this change breaks the secondary
> > instances, since you load the cl files after the check for new_instance.
> >> 4) if the option to load last session is not enabled and there isn't a
> >> project file being loaded from command line and a project is not being
> >> loaded we just try to load files from command line if any
> > --
> > E-gards: Jimmy
> > _______________________________________________
> > Geany-devel mailing list
> > Geany-devel at uvena.de
> > http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
> Geany-devel mailing list
> Geany-devel at uvena.de
anyway I've expanded the patch to add an option to choose if the
previous behaviour (minus the bug) is wished or not.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 9057 bytes
Desc: not available
More information about the Devel