Re: [Geany-Devel] f403e7e (PR#188) - Maintain edit history on document reload

2015-06-25 Thread Thomas Martitz

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

2015-06-25 Thread Dimitar Zhekov

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

2015-06-25 Thread Matthew Brush

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

2015-06-25 Thread Lex Trotman
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

2015-06-25 Thread Lex Trotman
[...]

 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