Re: [Geany-Devel] f403e7e (PR#188) - Maintain edit history on document reload
Hello, I hacked up a document message to inform the user about this new behavior, see attached screenshot. However, as we entered string freeze, I don't suppose a new dialog like this is acceptable at this point? What else can we do for *this* release? Best regards ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Spawn module API
On 24.6.2015 г. 03:12, Lex Trotman wrote: On 24 June 2015 at 10:06, Colomban Wendlinglists@herbesfolles.org wrote: Le 24/06/2015 01:57, Lex Trotman a écrit : Colomban, Correct me if I'm wrong, but despite my loudly voiced misgivings :) doesn't the spawn_* series do command quoting and g_spawn* not? No. It uses quoting only internally, (a) when creating a Windows command line from argv, for obvious reasons, and (b) if your Windows CL program name contains spaces, to make sure that you won't run C:\Program.exe or C:\Program Files\Foo.exe if your C:\Program Files\Foo\Bar.exe does not exist. Yes, CreateProcess() will really try them, if you miss the quotes by mistake. [g_]spawn*() via argv produce identical results. Well, those support an additional command parameter that indeed is read in a platform-dependent manner. (this was a discussion point and ended like this). They however also support argvs just fine, so you can use those too and they would work the same. With this, you can also imagine using g_shell_parse_argv() on all platforms if you like, just like you would do with g_spawn(). Then Geany should be changed to do that too, for all commands (IIRC build commands already do it). Unless one is using \ as escape character or ' for quoting under Windows, the commands will work. The default filetypes always contain %x and never '%x', so they will work. Note by user I mean the end user, not the plugin programmer. Having the end user need to know if they should quote commands or not is bad (tm). If that is already the case then it should be fixed. They only need to quote a %x which may contain spaces, as usual, using double quotes, as in the default filetypes. The documentation examples also show double quotes, and unless I'm not missing something, we don't guarantee that \ and ' will work under Windows like in Unix. The new spawn is more Windows friendly, as it'll never treat the Windows directory separator \ as an escape character, and I think that will benefit the end users. The forward slashes will work as well (they work since MS-DOS 5.0). -- E-gards: Jimmy ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Spawn module API
On 2015-06-20 08:12 PM, Matthew Brush wrote: Hi All, I just noticed that the new spawn code exposes almost every single bit of API possible. Do we really want to do that, or should we limit it only to what is currently needed by any plugins? A quick survey of Geany-Plugins shows no usage of any of this yet. IMO, we shouldn't expose anything which is not needed by plugins, especially if it's not related to the plugin API. One further thought before we get locked into the exposed API. Shouldn't all the spawn stuff be in the utils_* namespace? From the plugin developer perspective it's just some more utility functions like the ones it improves upon already in the utils_ namespace and that seems to be the place where we dump all the general purpose convenience functions and stuff that makes up for GLib short-comings, and that's effectively what this is. If we wanted to keep the file-wise isolation of the spawn code, we could just tweak the Doxygen comments a bit to put the functions under that section of the API docs, rather than giving a handful of helper functions their own whole module (API-wise, ex. namespace and docs). Any opinions? Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Spawn module API
On 26 June 2015 at 11:11, Matthew Brush mbr...@codebrainz.ca wrote: On 2015-06-20 08:12 PM, Matthew Brush wrote: Hi All, I just noticed that the new spawn code exposes almost every single bit of API possible. Do we really want to do that, or should we limit it only to what is currently needed by any plugins? A quick survey of Geany-Plugins shows no usage of any of this yet. IMO, we shouldn't expose anything which is not needed by plugins, especially if it's not related to the plugin API. On IRC Colomban had me look at what spawning G-P plugins did (I looked at C code only). The result is that there are twelve g_spawn* calls which should be migrated to spawn_* equivalents. At least for those that use commands input by the user so the quoting is the same as Geany. There are five that use utils_spawn (which uses spawn_* internally) and they also should be migrated if they do their own command decoding. The above migrations will allow plugins that do their own decoding of commands to be simplified and become consistent. There is also a custom spawn in geanyctags, I didn't look at what it did differently. One further thought before we get locked into the exposed API. Shouldn't all the spawn stuff be in the utils_* namespace? From the plugin developer perspective it's just some more utility functions like the ones it improves upon already in the utils_ namespace and that seems to be the place where we dump all the general purpose convenience functions and stuff that makes up for GLib short-comings, and that's effectively what this is. It was proposed to make spawn a library, that would mean a separate namespace would be better. If we wanted to keep the file-wise isolation of the spawn code, we could just tweak the Doxygen comments a bit to put the functions under that section of the API docs, rather than giving a handful of helper functions their own whole module (API-wise, ex. namespace and docs). Is there a misc section? :) But otherwise yeah, the utils section of the manual seems ok. Any opinions? Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] f403e7e (PR#188) - Maintain edit history on document reload
[...] Right, makes some sense too. However, what to do in this case: the file is saved (clearing the red) and immediately reloaded? Make it red again or keep it clear? Well reload syncs file and buffer, so its cleared again. Seems right. [...] There is a various pref for the keep edit history on reload as of git master (on by default). Always clear undo would set this to off. Ok, maybe it should refer to this pref instead of using different terminology, keep edit history on unload and always clear undo are not immediately obvious as equivalent things. [...] Too bad for those 10%, What a nice response :( but red is universal for be careful here / something needs your attention, like traffic lights. But traffic lights have an alternative indication, the position of the light. I think the color can be changed though gtkrc/css, too. Not in the manual so it doesn't exist. Raised #531 for that, won't hijack this discussion further. Best regards. ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
