[Geany-Devel] End of Line

[Dimitar Zhekov]

Hi, All,

I see that the Scope plugin is marked in autotools as gtk+2 only,
and rightly so. At some point, gtk+3 broke GtkTextView: instead
of a reasonable default size, a view without text is 0 pixels
high (actually 1, gtk+ does not support zero). One of these views
is critical for the Scope UI. Interestingly, even after typing
some text in it (I managed to do that somehow), the view remains
1 pixel high. :)

I can find some workaround for this, though there doesn't seem to
be any good ones [1]. And create a PR to fix the insane statusbar
padding [2]. And find some non-tabletish theme, and fix it for
Windows Medium fonts [3], and...

Enough. If the gtk+3 developers want to target the mobile market
or something, so be it. I'm switching to another editor. It has
disadvantages, but is stable, and gets the job done.

It'll be nice if somebody makes the vte and headers checks in
scope.m4 as unix-only (there's already a "case" for the non-unix
platforms). Personally I'll dump a TODO list for the plugin, and
mark it as "Orphaned", along with geanyinsertnum and
geanyextrasel.

Please, spare me any reproaches, I feel unpleasant as it is.

*** I wish Geany, and all of you, the best of luck. ***

--

[1] For example, set height request 80, as somebody did for the
Project Description field, though using a fixed height is against
everything gtk+. That Description is broken for me BTW, neither
the arrows nor Enter scroll it, and the cursor happily disappears
below the lower border after entering a few lines. YMMV.

Another approach is to put some text in the textview, prefferably
with new lines, but that worked for me with mixed success.

[2] "gtk 3.16 statusbar size under Win~1" in the maining list.

[3] That doesn't appear as easy as setting a smaller default font
for all views, and the gtk+3 programs can't be marked as "DPI
unaware" by Windows 7 "Troubleshooting" feature.

--
E-gards: Jimmy

___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] Geany-Plugins rework -- RFC

[Dimitar Zhekov]

On 11/21/2015 15:42, Frank Lanitz wrote:


2) Cleaning off NEWS, Changelog etc. from individual plugin folders


Personally I world prefer to keep Scope NEWS and ChangeLog. The global 
NEWS contains only the most important changes in short format, and the 
git change log, common to all plugins, is a poor substitution for the 
standard text file in widely used change log format.


That being said, I may soon turn into one of the "not really responsive" 
maintainers you are talking about, if I can't find a way to turn gtk+3 
under Windows /medium text size/ into something decent looking. It never 
looked great, but the latest versions are completely tabletish, with 
nonsense settings as the ones I described in "gtk 3.16 statusbar size 
under Win~1".


--
E-gards: Jimmy
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] WAFarewell

[Dimitar Zhekov]

On 11/18/2015 02:41, Lex Trotman wrote:


Who is gonna make the PR (for milestone 1.27, after a whole 1.26
release deprecated) ready to remove Waf, not forgetting the
documentation, README, INSTALL etc and the website (hint Enrico ;)


Farewell then. It served us well.

Due to the slow process creation under Windows, and the relatively slow 
handling of text files under MSYS2, building Geany with autotools took 
up to 30 minutes on my old machine, several times slower than Linux _or 
Waf under Windows_. I've got a new machine recently.


(makefile.win32 still exists, but for Geany only, not the plugins)

--
E-gards: Jimmy
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

[Geany-Devel] gtk 3.16 statusbar size under Win~1

[Dimitar Zhekov]

Hi, all,

I upgraded my home computer, and am now using msys2 (which was very slow 
on the previous machine). So, I installed msys2 gtk+ 3.16.x and tweaked 
the funny default theme to make it usable, but encountered a slight 
problem with the status bar: it's too big, at least on "Medium" fonts. A 
screenshot is attached, with GtkHBox in yellow and GtkStatusbar in cyan, 
to make it more clear.


Now, I read the source, asked uncle Google, and found [1]. The yellow 
border is indeed 10x6, and setting all status bar margins to 0 via 
Geany.glade removes it. My question is, how to remove it with CSS? I 
tried the obvious things, like margin: 0, but they had no effect.


[1] https://github.com/GNOME/gtk/blob/master/gtk/ui/gtkstatusbar.ui

--
E-gards: Jimmy
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

[Geany-Devel] Use GStatBuf for g_[l]stat, not struct stat

[Dimitar Zhekov]

Hi, all,

Can somebody please review and apply PR #677?
I'm having constant problems with this...

--
E-gards: Jimmy
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] SPAWN_LEAVE_STDIN_OPEN

[Dimitar Zhekov]

On 22.9.2015 г. 17:23, Dimitar Zhekov wrote:


It seems that one more spawn flag will be useful: SPAWN_LEAVE_STDIN_OPEN.
[...]


Since there were no comments, I created a PR for it.

Also, PR #666 get! :)

--
E-gards: Jimmy
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] spawn_kill_process TERM or KILL?

[Dimitar Zhekov]

On 23.9.2015 г. 01:42, Lex Trotman wrote:


On 23 September 2015 at 00:35, Dimitar Zhekov  wrote:


Should spawn_kill_process send a SIGTERM or SIGKILL to the child under *nix?

- SIGTERM lets the child exit gracefully, removing temporary files etc.


This says it all, blasting a process and possibly leaving the build
system in an unknown state is a "bad thing" (tm).

[...]

Does Windows have a sigterm equivalent?  We should not make Linux
worse to match Windows.


The standard API doesn't AFAIK. Being "Windows", it's assumed that the 
used will close the program window for a graceful exit.


It's actually better that way. Tons of misbehaving crap lives under 
Win~1, and I'd imagine all of it will reject a request for termination 
if given the chance. :)



- the API name is "kill", not terminate.


Its too late to change it now if its in the API.


On 23.9.2015 г. 03:15, Matthew Brush wrote:

> For now we could do something like:
>
> /** @deprecated @see spawn_terminate_process() */
> gboolean spawn_kill_process(GPid pid, GError **error) {
> return spawn_terminate_process(pid, error);
> }

The name is half-right - it does kill the process under Windows, and 
actually *asks* it to terminate under POSIX... Also, since both kill(1) 
and kill(2) are "kill", but you can send any signal, I see no compelling 
reason to change the name.


--
E-gards: Jimmy
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

[Geany-Devel] spawn_kill_process TERM or KILL?

[Dimitar Zhekov]

Hi, all,

Should spawn_kill_process send a SIGTERM or SIGKILL to the child under *nix?

- SIGTERM lets the child exit gracefully, removing temporary files etc.

- the original build.c:kill_process from Geany <= 1.24 sends SIGTERM

- the child may refuse to terminate on SIGTERM (or be unable to respond 
to it because of blocking I/O)


- under Windows, TerminateProcess() is an equivalent of SIGKILL, not SIGTERM

- the API name is "kill", not terminate.

--
E-gards: Jimmy
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

[Geany-Devel] SPAWN_LEAVE_STDIN_OPEN

[Dimitar Zhekov]

Hi, all,

It seems that one more spawn flag will be useful: SPAWN_LEAVE_STDIN_OPEN.

Suppose that you need to send data to your child not constantly, but 
only from time to time (possibly after sending some startup data). You 
should to discard the initial stdin callback/source, to prevent it from 
being called when there is no data to send (and since the stdin channel 
is free, the callback is invoked constantly and raises high CPU usage).


Normally you would reference the channel, remember it, return FALSE to 
discard the initial callback, and create a new callback/source each time 
you have data to send (glib does not allow re-attaching a removed 
source). The problem with the current implementation is, as soon you 
return FALSE, spawn shutdowns (closes) the channel completely.


You may assume that g_io_channel_set_close_on_unref() will handle 
everything gracefully, but at least under Windows, if the child reads 
it's stdin until EOF (for example cat), so the channel must be closed 
explicitly on our end, glib will fail to auto-close it on unref (or even 
block? because the child is alive? I'm not sure about that).


So, SPAWN_LEAVE_STDIN_OPEN tells spawn not to shutdown the stdin 
channel, because you may hold a reference to it. Unfortunately, I see no 
official way to verify the ref_count of a GIOChannel.


Now, one can dup(g_io_channel_unix_get_fd(channel)), create and setup a 
new channel, and leave the original one to be closed (it works, I've 
checked), but that's seems unnecessarily complicated.


Thoughts? Maybe I'm missing something?

--
E-gards: Jimmy
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] CDK Plugin

[Dimitar Zhekov]

On 30.7.2015 г. 02:32, Matthew Brush wrote:


On 15-07-29 08:46 AM, Pavel Roschin wrote:

Is GTK3 really unavoidable dependency?


I could spend effort trying to make stuff compatible with both GTK2 and
3 but since GTK+ 2 is obsolete and even Geany will be depending on GTK+
3 by default soon, it seems pointless to write code that is deprecated
before it's even complete.


Hopefully gtk+3 will be the default only on *nix. The latest binaries 
for Win~1 are still 3.6.4, and they _slow_, to the point that simply 
scrolling with the down arrow causes jumps, or buffers the key. They 
rewrote the drawing stack in 3.10 IIRC...


--
E-gards: Jimmy
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] Failed to build 1.25-release with the makefile.win32 build system

[Dimitar Zhekov]

On 16.7.2015 г. 01:35, Enrico Tröger wrote:

On 13/07/15 18:35, Dimitar Zhekov wrote:

On both my older and newer MinGW-s, make -f makefile.win32 ended up with:

[...]


Lacking -lgeany perhaps?


Yes, and some more things which are not up2date.
[...]


(Personally I'm not a fan of makefile.win32, since you can't build
geany-plugins with it.)


Is there a reason why you used it?


I wanted to test build geany only for the win32defines cleanup, so 
copying localwin32.mk and starting make directly somehow seemed faster 
than Waf... turned out not to be.



Waf should do basically and thanks to Thomas' work, building with MSYS2
is very easy and probably the future.


Waf does it completely, and is my favorite. Works under Win~1 and Linux, 
does not make any problems, and requires only a python.


As of MSYS2, autotools autogen/configure starts a lot of processes, 
which is slow under Win~1, and I'm not sure whether it'll bring some 
unwanted shared library dependency.


--
E-gards: Jimmy
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

[Geany-Devel] Failed to build 1.25-release with the makefile.win32 build system

[Dimitar Zhekov]

On both my older and newer MinGW-s, make -f makefile.win32 ended up with:

make[1]: Entering directory '.../geany/plugins'
gcc -O2 -Wall -pipe -mms-bitfields -DHAVE_CONFIG_H -DGTK -I..
-I../src -I../scintilla/include -I../tagmanager/src
-Id:/opt/gtk+/include/gtk-2.0 -Id:/opt/gtk+/lib/gtk-2.0/include
-Id:/opt/gtk+/include/atk-1.0 -Id:/opt/gtk+/include/cairo
-Id:/opt/gtk+/include/gdk-pixbuf-2.0 -Id:/opt/gtk+/include/pango-1.0
-Id:/opt/gtk+/include/glib-2.0 -Id:/opt/gtk+/lib/glib-2.0/include
-Id:/opt/gtk+/include -Id:/opt/gtk+/include/gettext
-o htmlchars.o -c htmlchars.c gcc -shared htmlchars.o
-L"d:/opt/gtk+/lib" -lgtk-win32-2.0 -lgdk-win32-2.0 -latk-1.0
-lgdk_pixbuf-2.0 -lpangowin32-1.0 -lgdi32 -lpango-1.0
-lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lglib-2.0 -lintl
-liconv  -o htmlchars.dll

htmlchars.o:htmlchars.c:(.text+0x2a): undefined reference to 
`utils_str_equal'
htmlchars.o:htmlchars.c:(.text+0x3e): undefined reference to 
`utils_str_equal'
htmlchars.o:htmlchars.c:(.text+0x68): undefined reference to 
`document_get_curre

nt'
htmlchars.o:htmlchars.c:(.text+0x7c): undefined reference to 
`sci_has_selection'
htmlchars.o:htmlchars.c:(.text+0xa8): undefined reference to 
`sci_get_selection_

contents'


Lacking -lgeany perhaps?

(Personally I'm not a fan of makefile.win32, since you can't build 
geany-plugins with it.)


--
E-gards: Jimmy
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] Windows installer snapshots with GTK 2.24

[Dimitar Zhekov]

On 03.7.2015 г. 22:55, Enrico Tröger wrote:

On 03/07/15 18:27, Dimitar Zhekov wrote:

objdump of my Geany 1.25 "built on or after Apr 25 2015" with WAF, MinGW
gcc-4.8.1 and binutils/ld 2.24:  [...]


The versions look like those I had until I upgraded my Mingw setup
yesterday.
Where did you get your Mingw from?


Got the installer from their official site, and used it to download 
everything else. No MSYS components, pure MinGW.


Haven't updated it recently. No *winpthread* in the MinGW tree.

--
E-gards: Jimmy
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] Windows installer snapshots with GTK 2.24

[Dimitar Zhekov]

On 03.7.2015 г. 02:03, Matthew Brush wrote:

On 2015-07-02 01:36 PM, Enrico Tröger wrote:

On 02/07/15 01:17, Matthew Brush wrote:

Another alternative might be `-static -lwinpthread-1` with or without
the `-1`.


Thanks. I already tried static -lpthread and now also your variants but
all without success :(.
The geany.dll on my system is always linked against libwinpthread-1.dll,
even after updating my Mingw environment.

I'll keep testing and trying...



I remember having this problem before, though I forget how I solved it :(

This looks kind of promising:
http://stackoverflow.com/a/28001271


objdump of my Geany 1.25 "built on or after Apr 25 2015" with WAF, MinGW 
gcc-4.8.1 and binutils/ld 2.24:


DLL Name: comdlg32.dll
DLL Name: kernel32.dll
DLL Name: msvcrt.dll
DLL Name: msvcrt.dll
DLL Name: ole32.dll
DLL Name: shell32.dll
DLL Name: user32.dll
DLL Name: wsock32.dll
DLL Name: libcairo-2.dll
DLL Name: libgdk-win32-2.0-0.dll
DLL Name: libgdk_pixbuf-2.0-0.dll
DLL Name: libgio-2.0-0.dll
DLL Name: libglib-2.0-0.dll
DLL Name: libgmodule-2.0-0.dll
DLL Name: libgobject-2.0-0.dll
DLL Name: libgthread-2.0-0.dll
DLL Name: libgtk-win32-2.0-0.dll
DLL Name: intl.dll
DLL Name: libpango-1.0-0.dll
DLL Name: libpangocairo-1.0-0.dll

Two links to msvcrt, but no winpthread.
Hope that helps somehow...

--
E-gards: Jimmy
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

[Geany-Devel] Requesting ui_setup_open_button_callback to be exported

[Dimitar Zhekov]

Hi, all,

Taking point from:

On 28.6.2015 г. 06:14, Matthew Brush wrote:
> It can easily be made available on-demand, as normal.

I'm renewing my request for ui_setup_open_button_callback to be made 
available for the plugins. By the time I first requested it, there were 
plugins with their own versions (inferior - no native Win32 dialogs), 
and currently, it seems that geanylua, spellcheck and scope imitate it.


To save you some browsing of the mailing list archives, the following 
points were raised at the time:


"GtkFileChooserButton should be used" - however, Scope requires file and 
directory names which may not exist at the moment of choice, and if 
memory serves me, the file chooser button / dialog does not support 
names in $PATH either.


"It should be properly g-object-ified" - well, nobody was willing to do 
that, much less add Glade support.


(@Matthew: yes, I have plans to use it, had them from >= 2 years. :) 
Currently, my hope is to use it from the stable 1.25 release, if 
possible, or whenever it becomes available.)


There are other things I need, but let's see how this will it turn out...

--
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

[Dimitar Zhekov]

On 27.6.2015 г. 23:50, Lex Trotman wrote:

On 28 June 2015 at 05:46, Dimitar Zhekov  wrote:

On 27.6.2015 г. 04:40, Lex Trotman wrote:


spawn_write_data



This one looks "platform independent", but it's actually very easy to create
a stdin-write function that blocks under Windows...


Better document it then :)


from spawn.c:853:
"The @a stdin_cb may write to @c channel only once per invocation, only 
if @c G_IO_OUT is set, and only a non-zero number of characters."


Though I haven't tested (or don't remember) whether writing more than 4K 
under Win~1 may block... If that's the case, your stdin_cb will better 
be identical to spawn_write_data.



spawn_get_exit_status_callback


I understood it as a convenient default callback, hardly worth not
exporting it if everybody is going to define the same one-liner
themselves.  And I'm sure you will document it so nobody is confused
:)


and from spawn.c:853:
"Convinience @c GChildWatchFunc callback that copies the child exit 
status into a gint pointed by @a exit_status."


It took me a considerable time to solve a seemingly simple task, so it 
would have been a shame not to document everything. :)


--
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

[Dimitar Zhekov]

On 27.6.2015 г. 04:40, Lex Trotman wrote:


My concern is that, for a given platform, all commands a user enters
into Geany or plugins should use the same meta chars and quoting.
[...]


Well, after we could not agree on universal syntax, the next best thing 
would be to at least have consistent syntax on each platform.



Many plugins currently do their own command parsing to get an argv and
others use g_spawn_command (which is hard wired to unix rules, it uses
g_shell_parse_argv).  On windows these plugins will now use different
rules to the build commands because the build commands use spawn_* and
get platform dependent rules.


They will, though not that different. Most important when specifying a 
windows command with the *nix rules is you need to use either \\ or / as 
directory separator. Both will work, Win~1 supports that.



These plugins should be encouraged to switch to the same rules as
Geany, ie to use spawn_* calls with a cmd not an argv.  That means the
appropriate spawn_* API should be available.


As of me, they should be encouraged to use the native Windows rules for 
the benefit of the users. Unless we design Geany for *nix users which 
run Win~1 from time to time. :)


(I assume be "cmd" you mean "command line", not cmd.exe).


The API we need to expose for this is the API that allows an unparsed
command to be used, not versions that only allow argv.


All spawn calls support both a CL and an argv. If both are passed, argv 
is appended to CL.



So the spawn API that is a drop in replacement for g_spawn is only
needed where g_spawn doesn't work, and then it should only be used as
a temporary workaround __until the plugins move to using the cmd
version__.


Sometimes it's native to use argv (scope: , "--quiet", 
"--interpreter=mi2"). Having only CL would mean that one needs to create 
it from argv, and we currently have no platform independent mechanism 
for that (it's not hard to write one, but still).



So to me that means:

/* platform dependent checking */

spawn_get_program_name


Do we actually have a use case for this one?..


spawn_check_command

/* platform dependent running */

spawn_with_callbacks
spawn_async
spawn_sync

/* associated support functions */

spawn_kill_process


This one is "platform dependent killing".


spawn_write_data


This one looks "platform independent", but it's actually very easy to 
create a stdin-write function that blocks under Windows...



spawn_get_exit_status_callback


If you mean spawn_get_exit_status_cb, that only copies int status into 
gint *exit_status. You can check the status using the WIF* macros. With 
spawn.h included, the basic ones are defined on both *nix and Win~1.


--

Well, if spawn_sync and spawn_async remain public, for easier plugin 
migration, and the functions that Scope needs remain public, that means 
only spawn_get_program_name, spawn_async_with_pipes and 
spawn_get_exit_status_cb will be hidden.


Personally I'm for making spawn_async_with_pipes static until somebody 
requests it. It's powerful, but very hard to use properly.


And spawn_get_exit_status_cb should be static as well. That's just a 
one-liner, and somebody may confuse it with a function that processes 
the child exit status in some way.


--

An updated list of the API-s asked to remain public:

me  WIF*
lex spawn_get_program_name
lex spawn_check_command
me/lex  spawn_kill_process
spawn_async_with_pipes
lex spawn_async
me/lex  spawn_with_callbacks
me  spawn_write_data
lex?spawn_get_exit_status_cb
lex spawn_sync

--
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

[Dimitar Zhekov]

On 24.6.2015 г. 02:05, Colomban Wendling wrote:


BTW, I just noticed that on Windows spawn_async_with_pipes() requires
the GLib main loop to be running if child_pid=NULL (well, it registers a
watch func, not sure what happens if it doesn't execute -- zombie?).
We probably don't care much though.


Fixed child_pid=NULL with PR 536.

Also defined GEANY_API_SYMBOL as empty when compiling the spawn testing 
program.


--
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

[Dimitar Zhekov]

On 26.6.2015 г. 01:47, Lex Trotman wrote:


Hi Dimitar,


Hi, Lex.


On 26 June 2015 at 03:13, Dimitar Zhekov wrote:


It uses quoting internally [...bla-bla-bla unneeded tech details...]


I'm now totally confused, so let me ask the important question directly:


I should have been more terse, sorry. :)


A user is entering a command into Geany, if the command is going to be
run by spawn_* will they enter it the same way as they would if the
command is going to be run by g_spawn*?  In all versions,
sync/async/pipes or not.


Short answer: yes.

(Long answer: spawning under Unix and Windows was never exactly the 
same. When splitting a command line into an argument vector with 
g_shell_parse_argv(), and then running it with g_spawn(), or using 
g_spawn('/bin/sh', command), which are the standard practices under 
Unix, \ will work as escape character, and ' as argument quoter, as 
expected under *nix. That doesn't work under Windows, didn't work in 
1.23/1.24 either, and I haven't checked any earlier versions.)


--
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

[Dimitar Zhekov]

On 24.6.2015 г. 03:12, Lex Trotman wrote:

On 24 June 2015 at 10:06, Colomban Wendling  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

[Dimitar Zhekov]

On 24.6.2015 г. 02:05, Colomban Wendling wrote:


IMO, spawn_with_callbacks() is *the* key API from spawn, what makes it
great.


It is, indeed.


spawn_async_with_pipes() can be nice, but most people probably shouldn't
use them as they have same IO trickery most IO layers have, where you
have to take care of not filling up any pipes (write) or forget to empty
them (read).


It's doccomment specially says "use spawn_with_callbacks() unless you 
need to setup specific event sources". Equivalent to glib 
g_spawn_async_with_pipes - shoot yourself in the foot. I'm not opposed 
to hiding it completely.



BTW, I just noticed that on Windows spawn_async_with_pipes() requires
the GLib main loop to be running if child_pid=NULL (well, it registers a
watch func, not sure what happens if it doesn't execute -- zombie?).
We probably don't care much though.


I should check that, and either document it, or remove support for 
child_pid = NULL - especially if the function is hidden.



spawn_async() doesn't seem so much useful to me, [...]

spawn_sync() is nice because it allows to easily pipe through a process
(send some data to stdin and and read the output).  How often is this
useful for everyone I don't know [...]


I wrote those for completeness, as equivalents to g_spawn_[a]_sync. 
Though the prototypes are different, and spawn_sync supports binary I/O. 
The reasons I mentioned before apply - no helper process, native command 
line, better locale support, and likely improved security.



spawn_get_exit_status_cb() seem useless to the API IMO.  It's a trivial
function currently only used by spawn itself.  It might even be sensible
to make it completely internal.


I'm not against it.


I would have said that spawn_write_data() wasn't really required because
it's relatively simple and not used by Geany outside of spawn, but it's
indeed probably handy in combination with spawn_with_callbacks() to
anyone wanting to feed a simple buffer to stdin.


spawn_write_data() can be used either directly as a callback, or invoked 
by a more complex callback, which would probably be the case with Scope. 
It's indeed simple (if you know that the optimal read size under Windows 
is 2K), but do we need to repeat it, or write something similar, each 
time we want to write something to child's stdin?



spawn_get_program_name() is only used in spawn itself and doesn't seem
to be a strict requirement.


May be handy to get the program name from a command line... but most 
people would probably need spawn_check_command().



spawn_check_command() seem nice to validate a user command before
actually running it, so it might be useful to anyone wanting to run
user-supplied commands through the spawn API, to e.g. check for issues
right when the user defines the command (like how we do it in the custom
commands dialog).


Any plugin that lets you define a command line may benefit from it.
For now, I plan a per-program gdb executable setting in Scope, but 
without any gdb options, and thus don't need it...


--
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

[Dimitar Zhekov]

On 24.6.2015 г. 01:18, Matthew Brush wrote:

On 2015-06-23 09:04 AM, Dimitar Zhekov wrote:


[...]

 From you're previous email you mentioned the stuff checked with [x] below:

[x] spawn_kill_process()
[x] spawn_with_callbacks()
[x] spawn_write_data()
[x] SpawnFlags
[x] SpawnReadFunc
[x] SpawnWriteData

Is that sufficient, or is there other stuff? I will remove the /** from
anything that is not expected to be needed, if nobody objects.


Well, I can't be 100% sure before the implementation, but since 
everything in spawn is stateless, I can simply copy anything else, 
should need be, as a temporary measure.



About the WIF* macros, those (at present) are not "officially" part of
the plugin API as they have no Doxygen comments


They are documented in POSIX wait [1]. Though, as being defined by Geany 
under Windows, a short Doxygen comment may be needed.


> Well you know my opinion :) [...] I think we all
> also agree it's stupid for plugins to have to copy&paste code that
> exists already or else use an inferior version.

On that note, scope/src/plugme contains functions that I need exported 
from Geany since forever. Especially 
plugme_ui_setup_open_button_callback(), which is defined in several 
plugins under different names with varying quality. IIRC, the original 
Geany functions support Windows native file selection dialogs, but no 
plugin does. "Inferior version"-s.


> regardless if something possibly better[1] like GProcess comes
> available to us, and we don't even use it internally anymore.
> [1]: I have no idea if it's better, just an example.

If it's based on the glib spawning functions, it'll be no better than 
them. And as long as the glib developers want to support 
G_SPAWN_LEAVE_DESCRIPTORS_OPEN under Windows and convert anything to 
UNICODE, the glib functions will not improve.


[1] http://pubs.opengroup.org/onlinepubs/9699919799/functions/wait.html

--
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

[Dimitar Zhekov]

On 23.6.2015 г. 02:25, Matthew Brush wrote:


[...]


One thing I forgot: the plugin API currently exports 
utils_spawn_[a]sync, and a few plugins use utils_spawn_sync. These 
functions were (partially correct) wrappers around the old glib/win32 
spawn, and are now wrappers around spawn_[a]sync. Someday, in the 
distant future, they should be obsoleted...


> I get what you're saying but I also
> feel uneasy about blanket exporting of APIs with no current users of it,
> so we don't know exactly what really needs to be exported.

Well, with nothing from spawn exported, we can be pretty sure that all 
plugins _will_ be using utils_spawn and g_spawn instead. :)


> We should make Colomban decide :)

The leading developers should decide - including you.

--
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

[Dimitar Zhekov]

On 21.6.2015 г. 20:39, Matthew Brush wrote:

On 2015-06-21 04:25 AM, Dimitar Zhekov wrote:

On 21.6.2015 г. 06:12, Matthew Brush wrote:


[...]


Spawn neither requires not uses anything from Geany (except i18n), and
does not change anything in Geany state, so it's functions are not



Yeah, it almost should be a "separate" library (at least like TM or
MIO). Personally I don't like the tendency of Geany's plugin API to be
getting bloated with stuff that has nothing to do with Geany or plugins,
but rather general purpose stuff making up for shortcomings in GLib, or
general-purpose convenience functions. But I think maybe this is a
conversation for another day.


+1 on that. Any generic purpose functions, not really dependent on 
Geany, should be separated in a library, and used by Geany and the 
plugins on equal basic. Perhaps in a next version...


Some reasons for the plugins to use the spawn API, in no particular order:

- supports native CL under Win~1 (not \-is-escape *nix parsing)
- does not spawn helper processes (creating a process is costly under 
Win~1, though that's only notable for > several)

- handles locale arguments better (the former FiF locale error)
- may provide better security, depending on how glib starts processes

But I will not try to force the API on anybody, and do not want anyone 
else to do so. If the reasons are not compelling, so be it.



In the next plugins (after this release), Scope will require at least
WIF*, spawn_kill_process, SpawnFlags, SpawnReadFunc,
spawn_with_callbacks, SpawnWriteData and spawn_write_data.
It'll be good if 'debugger' uses them as well...



I figured there would be some use in at least Scope. Do you have any
problem if we make all the API private for now and then as you need it
in Scope (or any other plugins requesting it) we can export precisely
what is needed, at that time?


I want the next Scope to depend on Geany-1.25 stable-release. If the 
functions are hidden now, it'll have to depend on Geany-git-date, which 
I'd rather avoid...


[A note to myself: the README for this release should state that Scope 
depends on glib-2.18 now, not only Geany-1.22.]


--
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

[Dimitar Zhekov]

On 21.6.2015 г. 06:12, Matthew Brush wrote:


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.


The API is designed not only to ease/fix the spawn pipe I/O, but as a 
possible replacement for all glib spawn functions - and these may be 
invoked by any plugin. (There is no replacement for g_spawn_close_pid, 
which works fine, and for g_spawn_check_exit_status, because it's 2.34+ 
only - instead, the WIF* macros are defined system-independently.)


Spawn neither requires not uses anything from Geany (except i18n), and 
does not change anything in Geany state, so it's functions are not 
strictly "Geany" - it could be a separate library just as well.


In the next plugins (after this release), Scope will require at least 
WIF*, spawn_kill_process, SpawnFlags, SpawnReadFunc, 
spawn_with_callbacks, SpawnWriteData and spawn_write_data.

It'll be good if 'debugger' uses them as well...

--
E-gards: Jimmy
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] Msys2 to compile on win32

[Dimitar Zhekov]

On 14.6.2015 г. 15:21, Thomas Martitz wrote:


Why do you say self-compiled GTK? It is readily packaged for msys, I
think we should be able to use that.

Even geany is packaged already, which is great for plugin developers to
test on Windows. It's not suitable for end-user distribution though, I'd
say, therefore we still want our own installer.


We should be careful with these, since we don't want Geany or our gtk+ 
to be msys-dependent. The grep example shows that msys/2 has problems 
with \ as path separator (not surprising, since it's primary an unix 
emulation layer), and interpreting /x/path as x:\path won't be nice, 
except if we ship a "Geany-for-msys-not-win32-native".


--
E-gards: Jimmy
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] Msys2 to compile on win32

[Dimitar Zhekov]

On 05.6.2015 г. 19:52, Enrico Tröger wrote:

On 29/05/15 11:00, Thomas Martitz wrote:


Msys2 is a successor to msys which offers a unix-like environment on
Windows combined with a pacman-based package manager. [...]


My standard test:

[D:]grep 00A0 uni\*.uni
grep: uni*.uni: No such file or directory

[D:]grep 00A0 uni\\*.uni
grep: uni\*.uni: No such file or directory

Why?..

[D:]grep 00A0 uni/*.uni
uni/10646-1.uni:00A0
...

It's actually an *improvement* over MSYS, which required UNI/*.UNI (i.e. 
a short name if the short and long names are identical).


I don't know about pacman, but the 20MB maintenancetool.exe does not 
look like something that can be used to manage the MSYS2 components. Out 
of the box, only "Remove all components" works; the "Default 
repositories" are empty and read-only, and I can't even see a list of 
the installed MSYS2 components. Not very impressive, compared against 
mingw-get, which is < 200KB (.exe + guimain.exe).



Hopefully, this enables us to eventually remove the Waf build system in
the longterm.


I'm using waf under Linux as well, since it keeps the source tree clean, 
and allows compiling only selected plugins without a super-long list of 
--disable-plugin-s.


Also note that MSYS2 by itself does not include any development stack. 
Not even a make, like MSYS.


--
E-gards: Jimmy
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] [geany/geany] 826f65: Merge pull request #441 from zhekov/spawn

[Dimitar Zhekov]

On 15.5.2015 г. 19:54, Colomban Wendling wrote:


Merge pull request #441 from zhekov/spawn

Add a spawn module for Geany


If you have any questions, notice bugs, or have ideas about API 
improvements, do not hesitate to [fill a bug and] drop me a note.



Thanks a lot for Dimitar's hard work, commitment and endless patience!


Thanks to b4n, elextr, techee, and the others who helped.

The final spawn was improved quite a bit compared to 1.01.

--
E-gards: Jimmy
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] [geany/geany-plugins] 73ae49: waf: Fix the checks for openpty() on FreeBSD

[Dimitar Zhekov]

On 19.4.2015 г. 16:43, Enrico Tröger wrote:

On 17/04/15 21:42, Dimitar Zhekov wrote:


Alright, I finally got it.
To whoever might be interested:

1. The default theme for gtk+ 2.24 under Windows has been changed [...]

2. The horizontal (only) notebook tabs backgrounds under "MS-Windows" is
unchangeable with any gtkrc settings. [...]


So, how do we want to proceed?


Warn the users that the default theme has been changed, and they need 
gtk-theme-name = "Raleigh" in etc/gtkrc to get the previous behavior 
(unless they already have set a theme, in which case there will be no 
difference). Using .gtkrc-2.0 in their home path will also work, for the 
people who prefer/need to run Win~1 as a regular user.



Provided that Thomas' underline trick works with the MS-Windows theme,
we could maybe add this to the Wiki by providing a copy&paste ready
gtkrc snippet for Windows users who want to a better visual indication
of the active tab?


That would be nice, I have seen editors under Win~1 providing bold as an 
option for the active tab. However, I don't know a way to address the 
editor notebook specifically under gtk+ 2, without affecting the sidebar 
(and any other notebooks at the same hierarchy level). Setting the 
editor notebook widget name to "GeanyEditorNotebook" does the trick, but 
breaks compatibility: the current


widget "GeanyMainWindow.GtkVBox.GtkVPaned.GtkHPaned.GtkNotebook*"

addressing does not match GeanyEditorNotebook any more.

So, instead of setting the widget name in Geany, it may be better to 
write a small plugin that ui_lookups for specified widget id-s, and sets 
their widget names. That'll make every single geany.glade widget 
addressable, and let the user decide on what (s)he wants.


--
E-gards: Jimmy
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] [geany/geany-plugins] 377322: Scope: Fix a typo

[Dimitar Zhekov]

On 22.4.2015 г. 21:19, Frank Lanitz wrote:

Am 22.04.2015 um 20:14 schrieb Dimitar Zhekov:


-Show =li_brary
messages
+Show li_brary
messages


That's not a typo, they are =library-...
"library" alone does not carry enough info.


OK. With = it really doesn't make sense to me. But I'm fine to revert as
I really thought it's just a typo.


I accidentally fixed it while removing support for gtk+ 2.16...

I'll change the text so something more clear, and add a TL-node.

--
E-gards: Jimmy
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] [geany/geany-plugins] 377322: Scope: Fix a typo

[Dimitar Zhekov]

On 20.4.2015 г. 20:09, Frank Lanitz wrote:

Log Message:
---
Scope: Fix a typo

-Show =li_brary messages
+Show li_brary messages


That's not a typo, they are =library-...
"library" alone does not carry enough info.

--
E-gards: Jimmy
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] [geany/geany-plugins] 73ae49: waf: Fix the checks for openpty() on FreeBSD

[Dimitar Zhekov]

On 16.4.2015 г. 23:36, Colomban Wendling wrote:


I can't seem to really change the colors when using the "MS-Windows"
theme, but I guess it's kinda expected some things aren't really
overridable with a "native" theme that uses the Windows theming API or
something.


But the vertical tabs still respect bg[ACTIVE]. Gee...


However, using "Raleigh" (the one you seem to use given the look) it's
relatively easy (well, not to guess what to change, but to change it).
[...]


Alright, I finally got it.
To whoever might be interested:

1. The default theme for gtk+ 2.24 under Windows has been changed to 
"MS-Windows". Raleigh/gtk-2.0/gtkrc still says "This theme is the 
default theme if no other theme is selected", but that's wrong. The 
bundle README still contains instructions on how to set the theme to 
"MS-Windows", which is now unneeded - it would have been better if they 
changed it with "how to set Raleigh if you want the previous look".


2. The horizontal (only) notebook tabs backgrounds under "MS-Windows" is 
unchangeable with any gtkrc settings. That applies to 2.24, _2.22_, and 
probably the previous versions. The backgrounds are taken from the 
Windows theme, but seem to ignore the settings in Display -> Appearance 
-> Advanced, or there might be no appropriate setting. And on XP, that 
may be dependent on Appearance -> Windows XP style vs. Windows Classic 
style.


Thanks to everyone in the mailing list who was willing to help.
It was a waste of time, but at least if someone in the users list 
complains, we know the answer.


(At some point, I changed the theme to "Emacs" - but only under 2.22, to 
see how it looks. Have I done that under 2.24, this thread would have 
been much shorter.)


--
E-gards: Jimmy
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] [geany/geany-plugins] 73ae49: waf: Fix the checks for openpty() on FreeBSD

[Dimitar Zhekov]

On 16.4.2015 г. 14:41, Colomban Wendling wrote:

Le 15/04/2015 19:15, Dimitar Zhekov a écrit :

That's exactly what I'm talking about. The white horizontal line, which
normally gives nice outline [vertical_tabs], but is almost lost [...]
the white editor background, combined with the identical unchangeable
background for the tabs. Not completely indistinguishable, but much
worse than 2.22, and hard on many tabs.


FWIW I get the real Windows GTK theme straight out of the GTK2 bundle (
no modification, no nothing, for some reason I didn't even have to set
it), and it has a clear separation of the current tab (and feels more
native/less ugly).


Huh... What version of gtk+ is this? I was unable to set the tabs 
background to anything different than the default gray using .gtkrc-2.0, 
but maybe it takes the background color(s) from some element(s) of the 
Windows theme, or the rendering is different depending on the Windows 
version.



Wouldn't this address your issue? (even better than avoiding using GTK
2.24 altogether) Or do you have another problem with the integrated theme?


The problem is, it doesn't look much different than the Enrico's 
example, no matter the theme, though I have not tested extensively under 
7even. Well, if XP is the problem, I wonder how it'll look under 10? I 
plan it as my next Windows version.


If that's really dependent on the Windows version, it can break any 
moment, and I'd prefer the ability (mentioned by Thomas) to have an 
option for underlining the current tab text (or bold / italic it).


Or should I get the heavy guns and write a plugin that displays line(s) 
of styled buttons that behave as tabs? The default tabs can be hidden in 
the interface preferences.


BTW, having tabs on the left/right "solves" the problem, since the 
background color *is* applied to the vertical tabs. But that would be a 
bit unusual recommendation for all Win~1 users...


--
E-gards: Jimmy
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] [geany/geany-plugins] 73ae49: waf: Fix the checks for openpty() on FreeBSD

[Dimitar Zhekov]

On 16.4.2015 г. 12:37, Thomas Martitz wrote:

Am 15.04.2015 um 19:15 schrieb Dimitar Zhekov:

That's exactly what I'm talking about. The white horizontal line,
which normally gives nice outline [vertical_tabs], but is almost [...]
due to the white editor background, combined with the identical
unchangeable background for the tabs. Not completely
indistinguishable, but much worse than 2.22, and hard on many tabs.


In my splitwindow2 patches I underline the text label in active tab. So
that the user can tell which of the 2 notebooks is active currently (the
tabs alone don't show that).

Would that be a worthy fix to your problem?


Yes. The ability to have the current tab underlined, italic or bold 
seems like a good thing to have, irrespective of my problems with 2.24 + 
Win~1. It probably should be done programmatically?


--
E-gards: Jimmy
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] [geany/geany-plugins] 73ae49: waf: Fix the checks for openpty() on FreeBSD

[Dimitar Zhekov]

On 16.4.2015 г. 03:41, Matthew Brush wrote:

On 15-04-15 10:15 AM, Dimitar Zhekov wrote:


That's exactly what I'm talking about. The white horizontal line, which
normally gives nice outline [vertical_tabs], but is almost lost [...]


We could re-parent the Scintilla widget into a frame (or whichever is
the proper widget) and set its border shadow to "in" or "etched in",
which would probably look more appropriate on Windows[0][1][2], and
likely still look fine on most non-Windows themes.


The Win~1 users are a minority. Maybe if it can be done depending on the 
OS...



Alternatively, we could probably tweak the default windows theme
(engine) to make it look more "native".


I was unable to set the active/inactive tab backgrounds with any theme 
settings. In particular, the settings from gtk+ <= 2.22 did not work.


--
E-gards: Jimmy
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] [geany/geany-plugins] 73ae49: waf: Fix the checks for openpty() on FreeBSD

[Dimitar Zhekov]

On 14.4.2015 г. 22:37, Enrico Tröger wrote:

On 13/04/15 19:33, Dimitar Zhekov wrote:


In 2.24, the horizontal tabs under Win~1 have this "flat" or "modern" or
whatever look, and you can only distinguish the current tab via a slight
3D effect. And unlike 3.x, where you can easily set the active tab


I don't get it.
For me it looks like as in the attached screenshot. I don't have a GTK
2.16 build at hand for a direct comparison but the notebook tabs look OK
to me in the GTK 2.24 build.


That's exactly what I'm talking about. The white horizontal line, which 
normally gives nice outline [vertical_tabs], but is almost lost due to 
the white editor background, combined with the identical unchangeable 
background for the tabs. Not completely indistinguishable, but much 
worse than 2.22, and hard on many tabs.


--
E-gards: Jimmy
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] [geany/geany-plugins] 73ae49: waf: Fix the checks for openpty() on FreeBSD

[Dimitar Zhekov]

On 14.4.2015 г. 01:56, Lex Trotman wrote:

On 14 April 2015 at 03:33, Dimitar Zhekov  wrote:

On 13.4.2015 г. 04:11, Matthew Brush wrote:

Wow, that may be not a very good news for the Windows users.


Well, the GTK windows guys on the GTK list basically seem to agree
that the next good windows version after 2.16 is 2.24, there were
various major problems with the versions in between.


Judging from the broken notepad tab coloring in 2.24, and the extremely 
slow 3.6.4, which comes without sub-pixel hinting by default, I doubt 
than any of them uses Windows for more than a 10 minute test.



So it was chosen because it may be the least worst version for windows.


Well, it's not a problem *for me*. I'm compiling from source, and Geany 
actually depends on 2.22, so replacing the number takes only a minute.


--
E-gards: Jimmy
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] Blank completion popups on Windows

[Dimitar Zhekov]

On 14.4.2015 г. 02:00, Lex Trotman wrote:

On 14 April 2015 at 07:32, Colomban Wendling  wrote:

Hi everyone,

I don't use my Windows VM very often, but I realized today that the
completion popups were broken there during the 1.25 cycle [1].

Could everyone using a development version of Geany under Windows tell
me whether it works for them or not, and their Windows and GTK versions?
I myself tried on XP SP3 with GTK 2.24.10.


XP is no longer supported
http://windows.microsoft.com/en-AU/windows/end-support-help so it
doesn't matter.


That was heavy. :) Should we declare half of the Linux distributions 
unsupported, because they never had any official support in the first 
place? Or discard Windows 8.x, since it's less popular than XP? [1]


[1] 
http://www.netmarketshare.com/operating-system-market-share.aspx?qprid=10&qpcustomd=0


--
E-gards: Jimmy
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] [geany/geany-plugins] 73ae49: waf: Fix the checks for openpty() on FreeBSD

[Dimitar Zhekov]

On 13.4.2015 г. 04:11, Matthew Brush wrote:


While on configuring, the README file still lists gtk+ 2.16 as a minimum
requirement for Geany - but it's actually 2.18 with GtkInfoBar now,
right?


I just merged PR #245[0], so 2.24 should be good version to use.


On 13.4.2015 г. 04:12, Lex Trotman wrote:

> 2.18!!! c'mon, get with it, Geany is now 2.24 :)

Wow, that may be not a very good news for the Windows users.

In 2.24, the horizontal tabs under Win~1 have this "flat" or "modern" or 
whatever look, and you can only distinguish the current tab via a slight 
3D effect. And unlike 3.x, where you can easily set the active tab 
background with CSS, in 2.24 the (in)active horizontal tabs are always 
with the same background AFAICT.


In fact, I have not found a way to change neither the active nor the 
inactive horizontal tab background in 2.24 - even with all backgrounds 
for all widgets set to red, the horizontal tabs are still light gray.


Using color to distinguish the tabs does the job, albeit worse, but 
conflicts with Geany red for modified and green for read-only tab. If 
somebody knows how to change the (in)active horizontal tab background, 
please drop me a note...


On 13.4.2015 г. 04:05, Matthew Brush wrote:

> Remove pre-GTK+ 2.24 preprocessor checks and related code

Looking at the changes, the lowest gtk+ version checked is 2.20, which 
suggests that for Geany there is no difference between 2.22 and 2.24. 
Would it be possible to keep the minimum version 2.22? I have heard it 
has some problems under Windows, but never actually seen any.


--
E-gards: Jimmy
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] [geany/geany-plugins] 73ae49: waf: Fix the checks for openpty() on FreeBSD

[Dimitar Zhekov]

On 10.4.2015 г. 18:36, Colomban Wendling wrote:


waf: Fix the checks for openpty() on FreeBSD


ACK. Please, be sure to use the same check for debugger, it probably 
needs it.


While on configuring, the README file still lists gtk+ 2.16 as a minimum 
requirement for Geany - but it's actually 2.18 with GtkInfoBar now, 
right? I can cut an entire module (gtk216.[ch]) from Scope if 2.18 is 
the minimum required version...


--
E-gards: Jimmy
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] Placeholder replacement in (build) commands

[Dimitar Zhekov]

On 03.4.2015 г. 03:52, Lex Trotman wrote:


To find proper quoting for Windows, you'll need to look no further than
spawn_append_argument() in the new spawn. :)


Well, thats obviously the name of a quoting function, perhaps it
should be spawn_append_argument_win_quoted() so I might have noticed
it :)

Its fine for appending an argument, but when replacing a placeholder
you can't be certain it isn't inside quotes already.  [...]


Sure.


But it doesn't put arguments containing tabs inside " either.


If you mean spawn_append_argument, it checks for at least one " or 
g_ascii_isspace(), and if so, quotes the entire argument. There's no way 
it'll miss a tab.



The only thing I'm not sure about are \n \v ... - the official VS 2013 msdn
says "arguments are delimited by white space, which is either a space or
a tab", [...]


It puts arguments containing \n and \v inside " which sounds
reasonable but yeah unexplained why.


Actually, I confused the blanks which *may* cause quoting with the ones 
should delimit the program name. The former set must be permissive to 
cope with stupid RTL-s, while the latter must be restrictive to avoid 
Win~1 to avoid running unexpected things.


So the actual blog error is that '\f' and especially '\r' are not 
included. But I'm not much better: after checking g_ascii_isspace(), it 
turns out that '\v' is not a spacing character for glib, despite both C 
and C++ standards saying it is. *facepalm*


"Everyone quotes command line arguments the wrong way" - truer words 
have never been said. I'll switch to isspace(), and even if it considers 
some non-ascii characters to be spaces, that'll do no harm.
(I can even quote unconditionally - the resulting CL will be a bit ugly, 
but it's internal to spawn anyway.)


--
E-gards: Jimmy
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] Placeholder replacement in (build) commands

[Dimitar Zhekov]

On 02.4.2015 г. 03:40, Lex Trotman wrote:

On 31.3.2015 г. 03:16, Lex Trotman wrote:



- In all default Geany commands, the placeholders are unquoted, meaning
that
any file name with space(s) currently breaks. Shame on us. :)


Well some of the default commands are double quoted, but not all IIRC
(filetypes.c uses all double quotes for eg).



Really... with double quotes, very nice for Windows. :)


Are you sure they don't?  see
http://blogs.msdn.com/b/twistylittlepassagesallalike/archive/2011/04/23/everyone-quotes-arguments-the-wrong-way.aspx

Says they work, no better than they work on sh though :)


To find proper quoting for Windows, you'll need to look no further than 
spawn_append_argument() in the new spawn. :)


The only thing I'm not sure about are \n \v ... - the official VS 2013 
msdn [1] says "arguments are delimited by white space, which is either a 
space or a tab", but the correct(?) solution in this blog includes \n 
and \v without any explanation. And it may slightly different under the 
various C RTL-s for Win32.


I was aware of this problem, and that's why, even in the oldest spawn 
versions, the blank characters in a Windows command line are #define-d, 
and may be easily changed.



I should have clarified: if the original command, before any placeholder
expansion, does not contain any quotes. If there is at least a single quote,
we assume the user knows what (s)he is doing.


Well, its a simple rule, but on win, paths ending in backslash will
break because you get prog "c:\dir with spaces\" and the closing quote
is escaped.  So its no improvement on the current situation.


What I did not consider is that our placeholders may end in directory 
separator (pretty obvious actually, \ is the root Win~1 directory).

In that case, spawn_append_argument() will do the job.


Note that the quotes on the C filetype build commands may be because
of the system() hack, since it passes stuff through cmd before
creating the process and cmd has *another* set of quotes, see the link
above.


I know, and have no intention to support the cmd rules, neither in spawn 
nor anywhere else.



Also if I read the win rules right, quoting %d would prevent you doing
"%d\filename with spaces" or "%d\%f" to get absolute paths, since it
doesn't do the catenation of separately quoted parts that sh does (as
I read it).  On sh you would do %d'\filename with spaces' or %d\\%f.


spawn execute
command line: showargs "foo""b a r""qux"
[...]
output:
argv[0] = showargs
argv[1] = foob a rqux

The command line is passed 1:1.


For Posix sh you simply can't put single quotes inside single quotes
because backslash is not an escape inside single quotes.  You have to
end the single quotes just before the single quote, double quote the
single quote and then single quote the rest. eg cmd 'no $ \ ` special
chars here except '"'"' or here'


I know... :) We have working natively quoting and escaping and breaking 
and whatever else is required for native quotation functions for Unix 
(g_shell_quote) and Windows (spawn_append_argument), so maybe we can 
stop discussing these details?



It'll be a good thing to do IMHO, but won't help in this case. We split the
non-shell commands under Unix with glib's g_shell_parse_argv(), which uses
the shell syntax. So quoting with 'name' and escaping ' is always right.


Not under sh, see above.  But if we threw away sh and did our own
thing then maybe.


Under Unix, we either spawn the command with /bin/sh, which uses the 
shell syntax, or break it into argv with g_shell_parse_argv, which uses 
the shell syntax (without subshells, but let's be realistic).

There is no difference.

So, in my understanding, you want to drop the shell syntax, and that is 
why you want to drop /bin/sh. But what stops "our own thing" from 
producing command line suitable for g_shell_parse_argv, and thus /bin/sh?



'$amounts'. Our current double-quoted placeholders make it "$amounts", so
the users users of Geany can have fun.


As the shell substitutes whatever amounts is defined to be :) But
maybe I *want* to substitute $CFLAGS into the command.


File and directory placeholders.

Now, if you *want* a file or directory placeholder to result in $CFLAGS, 
and then $CFLAGS to be expanded as a shell variable, the current 
double-quoted Geany build commands should be perfect for you, because 
they do exactly that. :)



So I still think we should either do nothing, or get it RIGHT.

Adding lots of code to just swap the current issues for a different
set doesn't sound sensible, but I'm not sure we have quite hit on
"right" yet.


It's not "lots", the proper quoting functions already exist. Remember 
that we must rewrite the placeholders replacement to *at least* do all 
replacements at once, and maybe add %% for literal % (though it may be 
currently escaped as \% under Unix and quoted with "%" under Windows).



For me right means:

- that it "just works" most of the time,
- there are no situations where the user is sc

Re: [Geany-Devel] Placeholder replacement in (build) commands

[Dimitar Zhekov]

On 01.4.2015 г. 04:33, Lex Trotman wrote:

On 1 April 2015 at 04:45, Dimitar Zhekov  wrote:

On 31.3.2015 г. 03:16, Lex Trotman wrote:



- In all default Geany commands, the placeholders are unquoted, meaning that
any file name with space(s) currently breaks. Shame on us. :)


Well some of the default commands are double quoted, but not all IIRC
(filetypes.c uses all double quotes for eg).


Really... with double quotes, very nice for Windows. :)


- The quotes are different under Unix/Win~1: single vs. double.


So in fact we should have two sets of filetype files, one for
linstalls and one for winstalls with different quotes on their
commands.


Or remove them if we do minimal native quotation.





I think there is an absolute minimum we can do about it: quote the
file/directory name placeholders natively, but if, and only if, the entire
command does not contain any single or double quotes. I don't see a way this
can fail, but maybe elextr can prove me wrong.


Only for the commands run under the shell, if you mean "no quote
character in the command *and* all the replacement texts"[1] then it
would work on Linux but that makes its behaviour depend on the command
text and the replacement text so I forsee much confusion.  Better to
be consistent.


I should have clarified: if the original command, before any placeholder 
expansion, does not contain any quotes. If there is at least a single 
quote, we assume the user knows what (s)he is doing.



And if we use double quotes on Linux, then $ and ` (at least) will
have special powers[2] which you may not want in a filename, but may
want elsewhere.  So again we don't know if we should escape the
special chars or not.


Quote it *natively*. That is "name" under Windows (can not contain "), 
and 'name' under Unix, with ' escaped. For file and directory name 
placeholders only. I don't think any child program will want to receive 
file names with spaces split into several arguments.



Maybe we should throw away running under the shell, who's silly idea
was it anyway :)


It'll be a good thing to do IMHO, but won't help in this case. We split 
the non-shell commands under Unix with glib's g_shell_parse_argv(), 
which uses the shell syntax. So quoting with 'name' and escaping ' is 
always right.



[1] think of %f being "fred's data" inside single quotes


'fred'\''s data' (I guess you don't mean " as part of the name, but they 
won't be problematic either)



[2] think of the %f being "$amounts", that will confuse the shell, and
will be real fun if amounts is defined :)


'$amounts'. Our current double-quoted placeholders make it "$amounts", 
so the users users of Geany can have fun.


--
E-gards: Jimmy
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] Placeholder replacement in (build) commands

[Dimitar Zhekov]

On 31.3.2015 г. 03:16, Lex Trotman wrote:

On 31 March 2015 at 11:14, Colomban Wendling  wrote:

Le 31/03/2015 02:10, Lex Trotman a écrit :

[…]

Perhaps we should be more explicit in the manual that on *ix build
commands are run in the shell and the user is responsible for either
quoting the substitutions correctly, […]


The user currently *cannot* do it "correctly" so it works with any
possible replacement, that's actually the problem :]


See the second part of the sentence which you elided :-D


There is 1 case where the user can't do it correctly: Context Action.

if (sci_has_selection(doc->editor->sci))
word = sci_get_selection_contents(doc->editor->sci);
...
utils_str_replace_all(&command, "%s", word);
spawn_async(... command, ...)

This can be fixed by removing the %s specified and passing the text as 
an argv after the command (the now spawn allows that), with the slight 
disadvantage that the selection will always be at the end.


--

In all other cases, except if somebody uses a file or directory name 
with ' under Unix for build or printing, the right thing *can* be done 
by quoting. But:


- In all default Geany commands, the placeholders are unquoted, meaning 
that any file name with space(s) currently breaks. Shame on us. :)


- The quotes are different under Unix/Win~1: single vs. double.

I think there is an absolute minimum we can do about it: quote the 
file/directory name placeholders natively, but if, and only if, the 
entire command does not contain any single or double quotes. I don't see 
a way this can fail, but maybe elextr can prove me wrong.


Of course, that's not perfect by any means. But if it'll unquestionably 
improve the most realistic scenarios (file / directory names with 
spaces), with a very small effort, I think it's worth.


--
E-gards: Jimmy
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] Placeholder replacement in (build) commands

[Dimitar Zhekov]

On 30.3.2015 г. 20:18, Colomban Wendling wrote:


To offload the discussion from PR#441 [1] from this partly off-topic
discussion and give it more visibility, I'm moving it here to the ML.
[...]


One thing I forgot to mention is that it would be good to have some kind 
of OS-variable (single|double) quotes for the static text. Under Unix, 
one would normally use ' to avoid file name and variable expansion, but 
under Windows, the normal quotes are double (unless using bash.exe or 
something).


That is, if the user specifies a build or printing command containing, 
say, «cx$dat.tmp», the Unix text must be single-quoted to avoid the 
expansion of $dat. But under Win~1, the single quotes are literal. And 
"cx\$dat.tmp" won't work either, \ under Win~1 will be literal[1].


Maybe %"cx$dat.tmp%", since we already use % as metacharacter?

In the case of solution 3.1,

> 3.1. Insert quoted replacement as needed where they appear

the variable quote replacement must be done before any placeholders.

[1] Win~1 escaping rules in short: " is escaped with \, any literal \-es 
before a " must be duplicated, all other \-es are literal.


--
E-gards: Jimmy
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] New plugin loader mechanisms

[Dimitar Zhekov]

On 26.3.2015 г. 01:16, Thomas Martitz wrote:


Now, do we really want the plugins to run arbitrary resource checking
code, and display their own error messages, only because they are
queried (or registered, as you put it), each time the list is build?



Yes plugins should be able to run arbitrary checking code because that's
necessary for proxy plugins. Whether Geany can provide APIs to report
results to a the user in a consistent manner is on another piece of
paper, one that's IMO slightly out of scope for my proposal.


From your initial proposal:

"The plugin defines a single global function, 
geany_load_module(GeanyPlugin *, GModule *). This is the only function 
that geany learns about using g_module_symbol(). And the only thing this 
function ought to do is to call geany_plugin_register()."


As a non-Englisher, I read this as "the only thing must / should / is 
supposed / is preferable", and am not sure which one. Some of the 
meanings contradict "should be able to run arbitrary checking code".



But nobody can guarantee that it exists and is valid on init. [...]
how am I supposed to react - just crash? If init remains void,
then it would be no better than the current void plugin_init(), and
I'll simply check anything in load - why bother, if I *still* need to
manually disable scope on initialization failure?


What do you do currently?


Emit a message in Status() + g_warning() and stop further init, plus 
check in cleanup(). A popup or status bar message would be acceptable 
too, since it's only if the plugin is actually activated, unlike any 
possible check in geany_load_module().



Besides, I didn't mean to make init() any better than the current
plugin_init() w.r.t. to its semantics. The only difference is more/other
parameters.


Indeed. That's why I asked "please make this gboolean".


Geany does not handle failing init() currently, and I don't want to
change that now because I think that's out of scope for my proposal.


OK then, that's it.


I also tend to think that a failing init is misdesigned.  [...]

> However keep in mind that init can be called without prior call to
> geany_load_module(), if the user toggles plugins in the PM dialog.

Under the current loading mechanism, a plugin is re-loaded with 
g_module_open() on each toggle. If you intend to change that, you'll 
break any global variable initializations in all plugins, most 
importantly the assumption that a global C variable is automatically set 
to zero.


If you are going to open the module each time, but call load only the 
first time, the "loadable" state may be wrong if something has changed 
between the open-s.


(And if you assume that init may be called without load, how can a 
falling init be misdesigned? We can mask it as void, but failure is 
still a failure.)


> And that init might not be called at all, so
> plugins shouldn't be wasteful with resources in geany_load_module()
> if might never be needed.

(yes, that's why I said "load the glade file and then unload it")

As a conclusion, a gboolean load is better than nothing. The resource 
errors in Scope were due to the fact that the resource directories 
defined by Geany were wrong. AFAICT, this is fixed in the latest gits, 
but a g_file_test() in init will still be helpful.


--
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] debug output on win32

[Dimitar Zhekov]

On 23.3.2015 г. 13:44, Enrico Tröger wrote:


This is because on Windows you have to decide at compile time whether
you want to have a console application or a graphical application.
Console applications can print directly to the terminal but not
graphical applications.


To be precise, when started from a console application, such as the 
shell, graphical applications can attach to their parent's console:


AttachConsole(ATTACH_PARENT_PROCESS);
WriteConsole(GetStdHandle(STD_OUTPUT_HANDLE), "boza", 4, &n, NULL);

It may be possible to create a file descriptor with _open_osfhandle() 
and replace stdout (and the others) with dup2(), I haven't tested.


The mpv player (a fork of MPlayer) under Windows uses it's parent 
console, if any.


--
E-gards: Jimmy
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] New plugin loader mechanisms

[Dimitar Zhekov]

On 18.3.2015 г. 23:15, Matthew Brush wrote:


Scope contains 20 source files and 22 headers. Using static is not an
option, and marking everything global as hidden will be cumbersome,
ugly, and easy to miss (inexperienced plugin developers are sure to miss
symbols).



Why does it need so many globals? Shouldn't the only globals really be
the stuff Geany requires? I'm wondering because one day it would be cool
to able to do stuff like having multiple "instances" in-process and to
allow a plugin per in-process "instance" or some stuff like this. With
the additional userdata pointer, in theory one could make a big huge
structure containing all their global (instance) state and have that
passed around, and then there's less issue with symbols and multiple
instances and such.


Because, if I have foo.c and bar.c, and foo needs to call a function 
from bar, the obvious way is to use a non-static function. And the 
normal way to guarantee that bar_function() will not cause any 
collisions is not to record it in some global pointer function list 
(you'll need a bar_init() for that anyway), but define it 
non-exportable. That will automatically enable per-instance usage.


The scope modules are separated by purpose, and they need to call each 
other no less than the Geany modules. I can declare everything static, 
create an "all.c", and #include all .c files, but why?


The global variables are:
- the global plugin configuration
- the current program (name, working dir, env, options...)
- the thread count, current thread and frame.

Of these, the first two categories may be reasonably put in structs, 
like in Geany, but I'm using name prefixes instead.


--
E-gards: Jimmy
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] New plugin loader mechanisms

[Dimitar Zhekov]

On 18.3.2015 г. 22:51, Thomas Martitz wrote:

Am 18.03.2015 um 21:23 schrieb Dimitar Zhekov:

On 18.3.2015 г. 18:42, Thomas Martitz wrote:



Do you generally like or support my proposal?


Yes, because the final goal is to be able to support different languages 
with gtk+ bindings, like/with libpeas that you mentioned.


(Of course, a loader for each new language would still be required (peas 
has loaders C/C++, Python and JavaScript IIRC), but it would be much 
easier if gtk+ bindings are used.)


--
E-gards: Jimmy
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] New plugin loader mechanisms

[Dimitar Zhekov]

On 19.3.2015 г. 00:05, Thomas Martitz wrote:

Am 18.03.2015 um 22:15 schrieb Matthew Brush:



[...]
void (*init) (GeanyPlugin *plugin, gpointer pdata);


Please make this gboolean. A plugin may have the correct API and ABI,
but be unable to startup / initialize for some reason. For example,
Scope requires scope.glade in the plugin data directory).



+1, I've always wanted a way to signal Geany "don't bother, it's just
going to crash you if you keep going". [...]

Another useful thing might be to provide a way to return a reason
message as well, then when Geany gets the failure return it can open
an error dialog and show the user a message that the plugin couldn't
be loaded, and show the reason string and maybe some bug-reporting
info or something.


It would be nice to unify such notifications. Of course, the plugins 
will need to return translated strings - we can't put their messages in 
Geany translation.




Thinking about it, if the plugin can't run because it's missing resource
files required for its operation, then I think it should be treaded like
incompatible plugins.


There seem like two different things to me.

The first thing a loader needs to do is query each plugin for 
compatibility. Incompatible plugins should not be listed at all, and 
it'll be good if the loader emits status messages for them in the Status 
tab. As an alternative, they may be listed disabled, with a message why 
the module can't be used.


Now, do we really want the plugins to run arbitrary resource checking 
code, and display their own error messages, only because they are 
queried (or registered, as you put it), each time the list is build?



I'm thinking if the plugin loaded successfully, then it should be
operational too.


I can check if scope.glade exists, but is it valid XML, compatible with 
the current version of gtk_builder? The only way to be 100% sure is to 
actually load it. And them immediately unload it, because Scope is being 
queried only, not activated. And then load it again on init...


But nobody can guarantee that it exists and is valid on init. What if 
the Plugin manager is open, scope.glade is removed or altered, and then 
"[ ] Scope Debugger" is checked? It's low probability, of course, but 
how am I supposed to react - just crash? If init remains void, then it 
would be no better than the current void plugin_init(), and I'll simply 
check anything in load - why bother, if I *still* need to manually 
disable scope on initialization failure?


--
E-gards: Jimmy
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] New plugin loader mechanisms

[Dimitar Zhekov]

On 18.3.2015 г. 18:42, Thomas Martitz wrote:


- Global symbols. Plugins binaries have to export a number of global
symbols (geany_{functions,data,plugin}, plugin_{init,...,cleanup}). This
kind of sucks, because they pollute the global namespace (in theory).
Luckily on unix or win32 systems this is not a problem because they can
restrict the symbol visibility of shared libraries. It's still bad
practice. Ideally plugins should have zero global symbols, everything
being static or hidden to the plugin binary.


Scope contains 20 source files and 22 headers. Using static is not an 
option, and marking everything global as hidden will be cumbersome, 
ugly, and easy to miss (inexperienced plugin developers are sure to miss 
symbols).


The only practical option seems to be compiling with hidden visibility, 
and geany_load_module() should be pre-defined as exported.



[...]
void (*init) (GeanyPlugin *plugin, gpointer pdata);


Please make this gboolean. A plugin may have the correct API and ABI, 
but be unable to startup / initialize for some reason. For example, 
Scope requires scope.glade in the plugin data directory).


--
E-gards: Jimmy
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] Switched to Win~1

[Dimitar Zhekov]

On 12.10.2014 г. 19:04, Tim Tassonis wrote:


On 10/11/2014 12:12 PM, Dimitar Zhekov wrote:

On 22.9.2014 г. 18:34, Kernc wrote:


 If I'm going to distro-hop, why not Windows? A working desktop, if
 nothing else.


Have fun, then. Just fixed a few Windows Machines and again knew one
reason to never, ever move to windows: The real-life requirement to
install a third-party commercial virus scanner eating up half of my
computer's resources just to be able to survive a few days on this
platform. Never in my life will i move to that horrible world.


Very true. I never praised Win~1 in the first place, and the lack of 
package manager is it's main system fault until W8. It'll take many 
years to see all applications migrate to Windows Store, and to have 
running random code from Internet blocked forever.


With the Linux distributions, the situation quite different, but not any 
better. You can (a) use the distribution packages only, and put up with 
things like K4, G3 and systemd; (b) compile packages from source, which 
is time consuming, and due to dependencies, you need to compile more and 
more of them; (c) block the unwanted updates - but again, due to 
dependencies, you have to block more and more. For a regular user, the 
only choice is (a), or install once and never update anything. Linux 
praises itself as a "free" operating system, but I can hardly imagine 
more totalitarian installation approach.


I used mainly distribution packages, of course, with some things 
compiled, some blocked, and even a 3rd party .deb or two, but managing 
the whole thing became too time consuming. As much as I hate them, the 
antivirus scanners at least work automatically.


--
E-gards: Jimmy
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] Switched to Win~1

[Dimitar Zhekov]

On 11.10.2014 г. 13:12, Dimitar Zhekov wrote:


here [1] is an illustrated collection of more than 150. :)


Missed the link. Here:

http://thecodelesscode.com/contents

--
E-gards: Jimmy
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] Switched to Win~1

[Dimitar Zhekov]

On 22.9.2014 г. 18:34, Kernc wrote:


If I'm going to distro-hop, why not Windows? A working desktop, if
nothing else.

Yeah, good luck with that.

http://catb.org/esr/writings/unix-koans/returning.html


A mirror may only show what it reflects. A branch is judged by it's 
fruits, not the leaves, and the fruit of Linux desktop became sour. A 
koan can be found for any situation or opinion; here [1] is an 
illustrated collection of more than 150. :)


That being said, Win~1 is not good for everything. As expected, I have 
to boot Linux from time to time, but am using Geany less that before. 
Unsubscribing, then, is only a matter of time.


--
E-gards: Jimmy
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] Switched to Win~1

[Dimitar Zhekov]

On 23.9.2014 г. 03:22, Matthew Brush wrote:


On 14-09-22 08:23 AM, Dimitar Zhekov wrote:


If I'm going to distro-hop, why not Windows? A working desktop, if
nothing else.


In no particular order, off the top of my head...

- Sandboxing
- Windows Store
- .NET
[...]
- etc...


- Not designed to be used by non-administrator. Fixable by writing some 
utility programs.
- A zoo of user interfaces. Blood-red, poison-green or Turkish-blue for 
main backgrounds...

- Crappy 3rd party drivers, even from respected companies.
- 80% of the programs run properly in "96 DPI" :) only. Of the ones that 
"support" high DPI, half would better not, including FF and Opera. 
Somewhat fixable with 7even.



That being said, if you cram enough FOSS onto Windows it can be made
nearly usable, and also Linux usually runs great in a virtual machine :)


750MB of MinGW + MSYS, with it's own package manager. Though I probably 
installed too much stuff, especially autotools.


Several end-user programs are the same as in Linux. What do you know, 
even Transmission kind of runs on Win~1 these days.


--
E-gards: Jimmy
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] Switched to Win~1

[Dimitar Zhekov]

On 22.9.2014 г. 14:12, Nick Treleaven wrote:


Now, Geany under Win~1 has some deficiencies, due to gtk+, so I'll


Such as?


Compared to a regular programmers editor for Win~1:

+++ It's an IDE, not simply an editor, and is still light.
++ I have experience with it.
+ Nice plugins.
+ Real code page convertor, not "Interpret as code page foo" only.

- Non-native interface. Pretty much a norm these days, and can be fixed 
to some extend.
- With gtk+2, randomly starts to eat several % of CPU time. Not a real 
problem, except for laptops. With gtk+ 3.8, see "Geany with gtk+ 3.6.4 
under Windows".

- Does not work with all monospaced TrueType fonts.
- Find in Files for locale texts is broken (passing locale file names to 
tools is almost surely broken too, but the locale file names support in 
glib is terrible anyway). [1]

- Filtering more than 4K of text may block. [1]
- Sync building, the resulting stdout and stderr are completely 
separated. [1], though they still may be mixed, if the spawned program 
emits lots of stdout and stderr texts fast enough. Haven't seen any real 
program do that.


[1] OK with the spawning fix.


GTK 4 :-o Hadn't heard of that. If it's anything like the GTK 3
transition: be afraid!


The Big Depreciation of gtk+3 becomes The Big Removal. Don't know about 
anything else, and don't care any more.


--
E-gards: Jimmy
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] Switched to Win~1

[Dimitar Zhekov]

On 22.9.2014 г. 08:46, Thomas Martitz wrote:

Am 21.09.2014 um 15:48 schrieb Dimitar Zhekov:


Since Debian is leaning more and more towards systemd, especially with
gvfs installed, and since systemd-init breaks my system, I finally sat
on my back and migrated to Windows. It's not a good system either, but
gets the job done.


This is a joke right?


I wish it was.


Seriously, I can understand that systemd is controversial, but not to
the extend to abandon *Unix* altogether. There are many many ways to
avoid systemd without going Windows, for example using a distro that
doesn't use systemd (Gentoo, Slackware, etc) or one of the BSDs.


I could not care less for being controversial - it's *broken* for me.

If I'm going to distro-hop, why not Windows? A working desktop, if 
nothing else.



Or, as you are on debian already, install the legacy sysvinit. It will
be fully supported at least throughout Jessie (so 5+ years). Or use
Ubuntu 14.04, which is still using upstart and will also be supported
until 2019. I'm sure all controversial points are solved by 2019, either
by systemd or a fork.


I said I kept a minimal Linux system, and it's with sysv-init of course 
(systemd-init is almost unusable for me). But I had to downgrade + block 
the updates of about 10 other packages due to dependencies, and sooner 
or later, udev, gvfs or something else will start to require the latest 
systemd, which *insists* on being init. So "fully supported" is for very 
low values of "full".


"Supported until 2019" normally means "will be fine if you don't upgrade 
anything until 2019, except for security fixes". Thanks - but no thanks.



I think it's just you leaning towards Windows. This is OK but don't
blame systemd for it.


After 15 years of using Linux desktop, 3 of which as maintainer of a 
source-based distribution? :)


But you are right that systemd is not the only reason. KDE 4, GNOME 3, 
FF[1], the list goes on, and recently even gtk+ 2.24.23+ (IIRC the 
revision) is slightly broken. Guess I finally lost faith in the Linux as 
desktop. I hope, for all of you, that Xfce 5 will be just fine.


[1] It's cross platform, of course, but the gtk+ version for Linux was 
very nice.


--
E-gards: Jimmy
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

[Geany-Devel] Switched to Win~1

[Dimitar Zhekov]

Hi,

Since Debian is leaning more and more towards systemd, especially with 
gvfs installed, and since systemd-init breaks my system, I finally sat 
on my back and migrated to Windows. It's not a good system either, but 
gets the job done.


Now, Geany under Win~1 has some deficiencies, due to gtk+, so I'll 
probably use it as a debugger only, and limit myself to the official 
releases. But if somebody decides to apply the spawning fix, or parsing 
the columns in compiler messages, or the small patch that adds virtual 
column to the status bar, I will be glad to help.


Also, if Scope has any problems building with or running under gtk+3, 
I'll fix them (some Linux programs are not replaceable, so I kept a 
small Debian system in dual boot). But there will be no gtk+4 support, 
at least not from me.


--
E-gards: Jimmy

___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] Proxy Plugins Update

[Dimitar Zhekov]

On Wed, 09 Jul 2014 10:40:20 -0700
Matthew Brush  wrote:

> On 14-07-09 10:01 AM, Dimitar Zhekov wrote:
> > On Tue, 08 Jul 2014 20:16:49 +0200
> > Thomas Martitz  wrote:
> >
> >> My whole libpeas fork is (currently) imported into the geany repo so
> >> it's a bit academic.
> >
> > I'd like to have a libpeas fork, or at least our own copy of the
> > library (the code is actually quite small). The latest libpeas
> > requires glib/gobject/gmodule/gio all >= 2.30, and the Debian package
> > even has gtk+3 as requirement because of libpeas-gtk, which is actually
> > optional and will not be used in Geany.
> 
> You could use that point to recommend forking all of our dependencies, 
> for example the latest GLib/GObject/GModule/GIO is >= 2.30 too, the 
> latest GTK+ is 3.12 and requires GLib >= 2.39, the latest Pango requires 
> GLib >= 2.32. We can't fork everything :)

These are shipped together as an official Windows binary, while libpeas
is not AFAIK (havent't searched too deeply). We don't want all Windows
users to compile peas to be able to use Geany.

> IMO, it'd be better just to depend on an older version than the latest 
> like we do for everything else, and maybe open a bug report for the 
> Debian package if it wrongly makes libpeas depend on libpeas-gtk instead 
> of the other way around.

To use an unmodified package, we'll have to go back to version 1.2.0
or so, and check for any important bugfixes until the current 1.10.0.
We may end up with a de-facto fork.

libpeas-gtk is a subdirectory of libpeas, it's normally compiled with
the package, so the dependency is not wrong. The maintainer could have
chosen to make it a separate package, but did not.

I strongly suspect that libpeas (at least without the gtk+ widgets)
does not really require the g* >= 2.30. There haven't been any major
changes in the type system since glib _2.4_, and GTypePlugin is stable
even before that. It could be the developers simply place the current
g* versions as requirement.

-- 
E-gards: Jimmy
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] Proxy Plugins Update

[Dimitar Zhekov]

On Tue, 08 Jul 2014 20:16:49 +0200
Thomas Martitz  wrote:

> My whole libpeas fork is (currently) imported into the geany repo so 
> it's a bit academic.

I'd like to have a libpeas fork, or at least our own copy of the
library (the code is actually quite small). The latest libpeas
requires glib/gobject/gmodule/gio all >= 2.30, and the Debian package
even has gtk+3 as requirement because of libpeas-gtk, which is actually
optional and will not be used in Geany.

-- 
E-gards: Jimmy
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] Proxy Plugins Update

[Dimitar Zhekov]

On Mon, 07 Jul 2014 18:48:00 +0200
Thomas Martitz  wrote:

> Hello,
> 
> I'm still working on proxy plugins, sorts of. I thought it would be 
> useful to give you an update.
> 
>  [...]
> 
> 1) backward-compat: Libpeas is fundamentally based on describing plugin 
> metadata with a separate .ini-style file ($plugin.plugin). It cannot 
> load plain .so files on its own.
>   -> I solved this by extending the libpeas parser such that it can 
> parse the plugin description of Geany plugins, and generate a 
> PeasPluginInfo from it. This way we can load existing plugins before 
> they transitioned to the .plugin file.

Well, if we decide on libpeas, we can move the descriptions from .so
to .plugin at some future point. Hope you havent hardcoded the file
type to ".so", since it's ".dll" under Win~1.

> 2) backward-compat again: libpeas' existing C parser cannot load the C 
> plugins because they do not implement a gobject interface.
>   -> For this I wrote a trivial custom loader which instantiates a 
> "PeasGeany" interface instance (it has the traditional init(), 
> configure(), help(), cleanup() methods) on behalf of the existing plugins.

This one should be part of Geany (there is no requirement to put the
custom loaders in separate libraries).

-- 
E-gards: Jimmy
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] The (mostly windows) spawning fix

[Dimitar Zhekov]

Hi,

To whoever might be interested, I updated the spawning fix for "include
what you use".

https://github.com/geany/geany/pull/274
http://sourceforge.net/p/geany/bugs/943/?page=3

-- 
E-gards: Jimmy
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] Geany with gtk+ 3.6.4 under Windows

[Dimitar Zhekov]

On Tue, 17 Jun 2014 17:34:22 -0700
Matthew Brush  wrote:

> On 14-06-17 09:28 AM, Dimitar Zhekov wrote:
> >
> > 5. The waf build of geany plugins does not currently support gtk+3.
> 
> Not a problem with GTK3, just a matter of those using/responsible for 
> Waf to update the build system. [...]

Attached is a simple diff with gtk+3 support for waf build of plugins.
Apply with -p0, specify --enable-gtk3, and also --enable-plugins=list,
since it does not check which ones support gtk+3.

On Sat, 21 Jun 2014 12:48:40 +0300
Dimitar Zhekov  wrote:

> I wrote simple gtk+3 support for geany plugins wscript, but have only
> tested it under windows so far, not linux.

Now tested under Win~1 and Linux. If you give me a green light, I can
push it to plugins git.

-- 
E-gards: Jimmy
--- wscript.orig	Sun Apr 27 13:56:40 2014
+++ wscript	Thu Jun 19 13:11:11 2014
@@ -62,6 +62,9 @@
 APPNAME = 'geany-plugins'
 VERSION = '1.25'
 LINGUAS_FILE = 'po/LINGUAS'
+MINIMUM_GTK_VERSION = '2.16.0'
+MINIMUM_GTK3_VERSION = '3.0.0'
+MINIMUM_GLIB_VERSION = '2.20.0'
 
 top = '.'
 out = '_build_'
@@ -79,12 +82,16 @@
 conf.load('compiler_c')
 
 # common for all plugins
-check_cfg_cached(conf,
-   package='gtk+-2.0',
-   atleast_version='2.16.0',
-   uselib_store='GTK',
-   mandatory=True,
-   args='--cflags --libs')
+# GTK / GLIB version check
+gtk_package_name = 'gtk+-3.0' if conf.options.use_gtk3 else 'gtk+-2.0'
+minimum_gtk_version = MINIMUM_GTK3_VERSION if conf.options.use_gtk3 else MINIMUM_GTK_VERSION
+conf.check_cfg(package=gtk_package_name, atleast_version=minimum_gtk_version, uselib_store='GTK',
+mandatory=True, args='--cflags --libs')
+conf.check_cfg(package='glib-2.0', atleast_version=MINIMUM_GLIB_VERSION, uselib_store='GLIB',
+mandatory=True, args='--cflags --libs')
+# remember GTK version for the build step
+conf.env['gtk_package_name'] = gtk_package_name
+
 check_cfg_cached(conf,
package='geany',
atleast_version='1.24',
@@ -98,7 +105,7 @@
 conf.define('REVISION', revision, 1)
 # GTK/Geany versions
 geany_version = conf.check_cfg(modversion='geany') or 'Unknown'
-gtk_version = conf.check_cfg(modversion='gtk+-2.0') or 'Unknown'
+gtk_version = conf.check_cfg(modversion=gtk_package_name, uselib_store='GTK') or 'Unknown'
 
 load_intltool_if_available(conf)
 setup_configuration_env(conf)
@@ -205,6 +212,9 @@
 # Options
 opt.add_option('--no-scm', action='store_true', default=False,
 help='Disable SCM detection [default: No]', dest='no_scm')
+opt.add_option('--enable-gtk3', action='store_true', default=False,
+help='compile with GTK3 support (experimental) [[default: No]',
+dest='use_gtk3')
 # Paths
 opt.add_option('--libdir', type='string', default='',
 help='object code libraries', dest='libdir')
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] Geany with gtk+ 3.6.4 under Windows

[Dimitar Zhekov]

On Sat, 21 Jun 2014 19:27:16 +0200
Colomban Wendling  wrote:

> Le 21/06/2014 11:48, Dimitar Zhekov a écrit :
> > [...]
> > 
> > With gtk+3, pressing "down" to scroll in a source file gives CPU usage
> > of 50% (that is, 100% on a single cores), and the scrolling is a bit
> > jumpy. For reference, gtk+2 uses 22% CPU, and SciTE for Win32 only 9%
> > (due to the fact is uses Win32 API directly).
> 
> I just stumbled upon
> http://blogs.gnome.org/alexl/2013/11/04/the-modern-gtk-drawing-model/
> which seems to say that with GTK 3.8+ widgets doing scrolling "the old
> way" (e.g. the GTK < 3.8 way) will likely be just slow, as IIUC the old
> optimization for it was dropped.

But the binary used is 3.6.4, so that's not the cause.

BTW, gtk+2 scrolling is buggy: if there is a window above the text,
it's "scrolled" as well. For example, with a Find dialog and scrolling
down, it's title is duplicated N times above of the dialog. The non-gtk
windows are affected as well, for example Win~1 Task Manager, which is
on Top of the other windows by default. I'm beginning to suspect how
the gtk+2 scrolling under Win~1 works. :) The first full redraw of the
scintilla widget fixes everything, so it's not much of a problem.

I won't check anything else on the $subject until an official Win~1
binary with the new drawing model is released, it's simply not worth.

-- 
E-gards: Jimmy
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] Geany with gtk+ 3.6.4 under Windows

[Dimitar Zhekov]

Hi,

Some more informatin on $subject and related topics.

--

At the time when gtk_widget_get_window(main_widgets.window) is invoked,
there is indeed no main window (GetActionWindow() returns NULL).

Since this is about reopening files on startup, their shortcuts, if
any, were already resolved when the files were open in the first place.
The right thing to do is probably instruct document_open_file_full()
not resolve them again.

--

There are lots of warnings about implicit declaration of function
'win32_...', probably a result of "include what you use" (and not
specific to gtk+3).

--

With gtk+3, pressing "down" to scroll in a source file gives CPU usage
of 50% (that is, 100% on a single cores), and the scrolling is a bit
jumpy. For reference, gtk+2 uses 22% CPU, and SciTE for Win32 only 9%
(due to the fact is uses Win32 API directly).

--

With gtk+3, when I have a selected tree view row in an unfocused tree
view, it's displayed in gray as usual (with the default theme), but
positioning the mouse over it alters the display, showing any check
boxes (GtkCellRendererToggle) as unchecked. gtk+2 is OK.

--

The plugins do not build with the latest Geany, due to a bug in Geany
wscript: 'localedir': '${datarootdir/locale' is missing "}".

--

I wrote simple gtk+3 support for geany plugins wscript, but have only
tested it under windows so far, not linux.

--

Scope does not currently build with gtk+3; I wrote a fix and will send
it when I can [1]. GtkTextView works without problems, so the blocking
of Geany About Dialog is not because of GtkTextView per se.

--

[1] Last, there was a large storm at my town (g:varna flood), and the
internet is unstable, so I'll probably use mail only for a few days,
not svn or git.

-- 
E-gards: Jimmy
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] Geany with gtk+ 3.6.4 under Windows

[Dimitar Zhekov]

On Tue, 17 Jun 2014 17:34:22 -0700
Matthew Brush  wrote:

> On 14-06-17 09:28 AM, Dimitar Zhekov wrote:
> >
> > Program received signal SIGSEGV, Segmentation fault.
> > 0x006e4340 in gdk_window_has_impl () from c:\tmp\scp\gtk+\bin
> > ...
> >
> > ...
> >
> > I coudn't get a proper HWND for Geany main window. Using
> > gdk_win32_window_get_handle(gdk_get_default_root_window()) works,
> > but the link UI may (or may not?) be displayed below the Geany
> > window, looking as if we blocked.
> >
> > A possible solution would be to use some Windows API directly, for
> > example GetActiveWindow().
> >
> 
> There's tons of bug reports about crashers on a number of different 
> platforms when you search Google for "gdk_window_has_impl" (with and 
> without leading underscore), seems like it does/did miss a NULL check or 
> such. My first thought is that we try to access the native window handle 
> before it has actually been allocated (eg. before a map event or 
> whichever event fires once window resources have been allocated), but 
> it's just an idea.

Well it works on gtk+2... Whether the window actually exists can be
easily tested by GetActiveWindow(). Personally I see no reason to use
GDK macros, when we need exactly the active window.

> Maybe trying to do `gtk_widget_map(win)` (or 
> whichever is the correct function) before trying to access the HWND 
> would fix/hide the bug?

That's the main Geany window... I'm not sure it's a good idea.

> > 3. The items under cursor are not always highlighted. For example,
> > when I open Edit and move the mouse, the menu items are highlighted
> > fine, except for Preferences, which may or may not be highlighted.
> >
> 
> I never noticed this when using GTK3 on Windows, but it's possible it 
> happened and I just didn't notice. Maybe there's something weird about 
> that particular menu item, like that we have one below it who's 
> sensitivity changes depending on runtime conditions, or the current UI 
> language/translation string, etc. It'd be interesting to move the menu 
> item up to the top of the menu, try changing the stock/icon/labels, 
> removing accelerator, etc. to see why only one item acts weird.

I gave this as a more or less stable example. Sometimes a button is not
highlighted, but it's rare and random.

> > 4. The second and especially the third tab in the About dialog cause
> > 100% CPU load and blocking.
> >
> 
> IIRC we have some weird stuff in those tabs, custom wrapping widgets 
> which are no longer needed for GTK3, etc. Even on Linux the "Credits" 
> tab is fairly broken, it doesn't allow selection, context menu, etc. IMO 
> we should move this whole dialog to Glade, just use a plain GtkTextView 
> and add all the names into the Glade file instead of loading from static 
> arrays and doing all the markup formatting using string/markup 
> functions, etc or just use GtkAboutDialog (properly).

The second tab is mostly two labels with markup, and the third is
exactly a GtkTextView, which is disturbing for my Scope plugin.

> > 5. The waf build of geany plugins does not currently support gtk+3.
> >
> 
> Not a problem with GTK3, just a matter of those using/responsible for 
> Waf to update the build system.

Not a gtk+3 problem, of course, just a note. I'll try to add gtk+3
support to test Scope.

> > Wikipedia calls gtk+3.4 "the first version of GTK+ 3 that works well
> > on Windows", but that seems to be an overstatement. Maybe 3.10+ with
> > the changed event loop and drawing will be better. Or worse...
> 
> It might be assuming the "works well" is for applications coded against 
> GTK3, fully using the framework supporting the toolkit, not trying to 
> support gtk2 and 3 at the same time, and that don't have almost a decade 
> of cruft built up to work around issues which may or may not even exist 
> anymore in the toolkit or/on the supported Windows versions :)

Hello world? :) I haven't seen any large and popular application started
with gtk+3. Of course, some may be partially rewritten to take full
advantages of it.

> > For now, we'd better stick to gtk+2 under Windows.
> 
> Even better would be to find out what is causing the problems and fix 
> the issues, most likely the stuff is going to be things we did slightly 
> weird in GTK2 that is no longer needed or doesn't work exactly the same 
> with GTK3. If we hold off switching to bundled version to GTK3, nobody 
> will use it and it won't get tested or fixed.

The event loop and drawing were changed considerably in 3.10. It may be
reasonable to wait a bit, and see 

[Geany-Devel] Geany with gtk+ 3.6.4 under Windows

[Dimitar Zhekov]

Hi,

Taking point from "[Geany-Users] I can't see highlighted item in menu",
here are some results of compiling and running Geany under Windows
with the official gtk+3.6.4 binary:

1. Compiles and install normally (waf build system).

2. On start, if at least 1 file was open, crashes with:

Program received signal SIGSEGV, Segmentation fault.
0x006e4340 in gdk_window_has_impl () from c:\tmp\scp\gtk+\bin
\libgdk-3-0.dll (gdb) bt
#0  0x006e4340 in gdk_window_has_impl ()
   from c:\tmp\scp\gtk+\bin\libgdk-3-0.dll
#1  0x006e4388 in _gdk_window_has_impl ()
   from c:\tmp\scp\gtk+\bin\libgdk-3-0.dll
#2  0x0071898e in gdk_win32_window_get_handle ()
   from c:\tmp\scp\gtk+\bin\libgdk-3-0.dll
#3  0x0045e998 in win32_get_shortcut_target ()
#4  0x00428992 in document_open_file_full ()
#5  0x00408758 in open_session_file ()
#6  0x00408886 in configuration_open_files ()
#7  0x0045ff75 in load_startup_files ()
#8  0x0046047f in main ()

The problem is in GDK_WINDOW_HWND(gtk_widget_get_window
(main_widgets.window)), used to compute HWND to serve as parent
window when resolving a link, if this happens to require UI. On link
target missing, Win~1 searches for "similar" files, displaying a small
dialog, and sometimes asks whether file X is the missing link.

I coudn't get a proper HWND for Geany main window. Using
gdk_win32_window_get_handle(gdk_get_default_root_window()) works,
but the link UI may (or may not?) be displayed below the Geany
window, looking as if we blocked.

A possible solution would be to use some Windows API directly, for
example GetActiveWindow().

3. The items under cursor are not always highlighted. For example,
when I open Edit and move the mouse, the menu items are highlighted
fine, except for Preferences, which may or may not be highlighted.

4. The second and especially the third tab in the About dialog cause
100% CPU load and blocking.

5. The waf build of geany plugins does not currently support gtk+3.

Wikipedia calls gtk+3.4 "the first version of GTK+ 3 that works well
on Windows", but that seems to be an overstatement. Maybe 3.10+ with
the changed event loop and drawing will be better. Or worse...

For now, we'd better stick to gtk+2 under Windows.

-- 
E-gards: Jimmy
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

[Geany-Devel] Geany uses g_signal_handlers_disconnect_by_data from glib 2.32

[Dimitar Zhekov]

Hello, all,

While attempting to compile the latest Geany snapshot, I received a
compiler warning and then a linked error:

src\document.c.5.o:document.c: (.text +0x5b97): undefined reference to
`g_signal_handlers_disconnect_by_data'

g_signal_handlers_disconnect_by_data() is since glib 2.32.

Our current requirements are for glib 2.20 or later.

The official windows binaries for gtk+2.24 include glib 2.28.8.

-- 
E-gards: Jimmy
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] Geany/plugins win32 waf build/install

[Dimitar Zhekov]

On Sat, 24 May 2014 11:55:47 +0200
Enrico Tröger  wrote:

> On 18/05/14 19:08, Dimitar Zhekov wrote:
> > On Sun, 18 May 2014 15:30:21 +0200
> > Enrico Tröger  wrote:
> > 
> >> On 16/05/14 18:41, Dimitar Zhekov wrote:
> >>>
> >>> The prefix problem is workarounded. Since geany.pc is installed in
> >>> \geany\path\lib\pkgconfig now, win32 pkg-config automatically
> >>> uses /geany/path, replacing \ with / and ignoring the prefix setting.
> >>> [...]
> >>
> >> Not sure whether I completely understand the problem here.
> > 
> > With a prefix with backshahes in geany.pc (unlike the other variables,
> > and any other .pc files), my gcc decides than c:\geany\path/include is
> > c:geanypath/include. The same goes for c:\geany\path/lib et cetera,
> 
> Ah got it, finally :).
> Should be better in 1bacf869e076ef37caa768196d21d941a657d1e7,

Broke it completely. :)

> I changed the code from hard-coded forward slashes to os.path.join().
> Still, there are tons of forward slashes in the build system. If these
> cause problems at any stage, let me know.

Again: the problem is that the _backward_ slashes in the prefix (and
now the other variables) in geany.pc are treated as escape characters by
cpp, gcc or whatever. With geany.pc in "c:\what\ever\lib\pkgconfig" (in
1.24+), win32 pkg-config ignores $prefix and uses "c:/what/ever". That
doesn't any more, because $includedir became "c:/what/ever\include",
processed as "c:/what/everinclude" ("\i" does not stand for anything
particular, thus simply "i").

The fix is to revert 1bacf869e076ef37caa768196d21d941a657d1e7.
It would nice to have the prefix in geany.pc with forward slashes,
but not really important - all glib/gtk+ .pc files contain prefixes
like c:/devel/target/059c48de6b739307c37648aba3005b29, and pkg-config
ignores them as described above.

> Some applications can handle the forward slashes even on Windows,
> others not. And IIRC also Windows sometimes handle the forward
> slashes properly, sometimes not.

The Windows API-s handle forward slashes as separators since DOS 5.
The only thing I'm not sure is whether server names ("//server/path"
instead of "X:/path") work, and that may cause problems.

> >>> The plugin installation, however,
> >>> creates a \lib directory on the installation drive, with all
> >>> lib.dll.a files
> > 
> Yeah but I don't know yet where this path (\lib) is set in Waf and how
> to change it. I didn't consider it a real problem yet apart from the
> fact that it sort of clutters the file system.
> I might will have a look at it if time permits.

I tried to find that as well, but couldn't. The entire installation of
lib*.dll.a is useless, nobody will link against our plugin DLL-s.

-- 
E-gards: Jimmy
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] The (mostly windows) spawning fix

[Dimitar Zhekov]

On Wed, 21 May 2014 11:19:40 -0700
Matthew Brush  wrote:

> On 14-05-21 11:02 AM, Dimitar Zhekov wrote:
> > Hi,
> >
> > Now that Geany 1.24[.1] is out, will we apply $subject? [1] [2]
> >
> > [1] https://github.com/geany/geany/pull/274
> > [2] http://sourceforge.net/p/geany/bugs/943/?page=3
> 
> I like it overall, and especially deleting 1000 lines of code :), 
> although it's really massive - and so hard to review - since the whole 
> thing is in one commit (maybe for good reason, I don't know).

That's logically one change. I guess it can be split into spawn.[ch]
plus the changes to the build systems to include the spawn module, and
the changes to the other .c modules, but am not sure what good will that
do... It's simply big.

Now, anyone can test split.[ch] separately by downloading the SF zip,
unpacking it into a separate directory and compiling it with 'make spawn
emit' (for *nix) - that'll generate test program 'spawn' (look at
spawn.c:main() to see what tests are available), and a helper 'emit'
which reads from stdin (option, -i) and writes to stderr and to stdout
(option, -o). For win32, you need to set the glib/gtk+ directory in the
Makefile and run 'make' without arguments. Geany is *not* required.

> One thing I couldn't figure out is why the Makefile.am and wscript (but 
> not makefile.win32) adds files called spawn.[ch] but they don't show up 
> in the commit/repo. Did you miss a `git add` command?

My mistake, I haven't used makefile.win32 from a long time. Fixed it
(not tested, hopefully I can write 8 characters without an error),
and also moved spawn to the last position in src/Makefile.am and
wscript, since it doesn't depend on anything (tested, builds).

-- 
E-gards: Jimmy
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

[Geany-Devel] The (mostly windows) spawning fix

[Dimitar Zhekov]

Hi,

Now that Geany 1.24[.1] is out, will we apply $subject? [1] [2]

[1] https://github.com/geany/geany/pull/274
[2] http://sourceforge.net/p/geany/bugs/943/?page=3

-- 
E-gards: Jimmy
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] RFC: Proxy plugins

[Dimitar Zhekov]

On Mon, 19 May 2014 15:10:27 +1000
Lex Trotman  wrote:

> The only questions I have on libpeas is:
> 
> 1. what changes it requires in Geany to make Geany keybindings usable
> from libpeas loaded plugins

For the current C plugins, replacing PLUGIN_KEY_GROUP() [deprecated
since 0.19] with calls to plugin_set_key_group() and
keybindings_set_item(). That's 9 plugins (including my geanyinsertnum,
gee), trivial change, doesn't break anything.

For geanypy, you should know better than me. The documentation mentions
that "Currently using keybindings requires [...] hackery, due to Geany
expecting all plugins to be shared libraries written in C".

For the plugins to come, it's a matter of how we pass keyboard callbacks
to the core, not how we load them.

> 2. the effort to incorporate it into the existing PM.

Depends on what you call "incorporate". Replacing the loader is
probably a matter of two days at most. After that, plugin_help() should
be replaced with automatic helper (peas plugins have help URL), and the
other g_module_symbol()-loaded functions should be replaced with
function calls from the plugin, or with peas extensions
(g_module_symbol() won't work for non-C languages anyway).

-- 
E-gards: Jimmy
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] Geany/plugins win32 waf build/install

[Dimitar Zhekov]

On Sun, 18 May 2014 15:30:21 +0200
Enrico Tröger  wrote:

> On 16/05/14 18:41, Dimitar Zhekov wrote:
> > 
> > The prefix problem is workarounded. Since geany.pc is installed in
> > \geany\path\lib\pkgconfig now, win32 pkg-config automatically
> > uses /geany/path, replacing \ with / and ignoring the prefix setting.
> > [...]
> 
> Not sure whether I completely understand the problem here.

With a prefix with backshahes in geany.pc (unlike the other variables,
and any other .pc files), my gcc decides than c:\geany\path/include is
c:geanypath/include. The same goes for c:\geany\path/lib et cetera,
though I'm not sure that gcc is to blame.

We discussed this briefly, but that was nearly a year ago ("Geany 1.23
Waf install under win32"), and apparently didn't happen on your system.

> > The plugin installation, however,
> > creates a \lib directory on the installation drive, with all
> > lib.dll.a files

> I'll post soon a tutorial how I build the release binaries on Windows.
> Apart from this, the whole build stuff on Windows is quite fiddled and I
> never considered it production-ready.

Once the X:\lib problem is fixed, it'll be fine, unless one decides to
move geany.pc to another location. Will be be nice to have the same
build system working under *nix and windows-without-autotools, and we
may be able to get rid of all these makefile.win32 files, which are not
supported for the plugins anyway.

-- 
E-gards: Jimmy
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] RFC: Proxy plugins

[Dimitar Zhekov]

On Fri, 16 May 2014 16:59:17 +0200
Thomas Martitz  wrote:

> I have a question regarding libpeas. There doesn't seem to be a public 
> (nor documented) API to add loaders. From what I can see the current 
> language support of libpeas is quite poor (only python and seed (that's 
> JS isnt it?)). Also, they don't seem to very committed to maintaining 
> their loaders[1].
> 
> I think we want to maintain the ability to add loaders on our own, 
> without depending on a 3rd party project. Especially for potentially 
> creating a compat-loader for our existing plugins. It doesn't seem 
> libpeas readily supports this. Unless I'm missing something.

The loaders (except for C) are plugins, and the build-in ones are
installed in /usr/lib/libpeas-/loaders/ as .so libraries.
For example, peas-plugin-loader-python.c contains:

G_MODULE_EXPORT void
peas_register_types (PeasObjectModule *module) <-- as a regular plugin
{
  peas_object_module_register_extension_type (module,
PEAS_TYPE_PLUGIN_LOADER,
PEAS_TYPE_PLUGIN_LOADER_PYTHON);
}

And for the next probable question, there is no search for .py files,
instead the plugin .ini file (foo.plugin) specifies which loader should
be used (C if missing).

-- 
E-gards: Jimmy
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

[Geany-Devel] Geany/plugins win32 waf build/install

[Dimitar Zhekov]

Hi,

I tested $subject again with 1.24, and it's improved significantly.
Geany now installs geany.pc and the development headers properly, so
the plugins build without problems. The plugin installation, however,
creates a \lib directory on the installation drive, with all
lib.dll.a files, which is completely pointless. It was the
same with 1.23, but I forgot to mention it.

The prefix problem is workarounded. Since geany.pc is installed in
\geany\path\lib\pkgconfig now, win32 pkg-config automatically
uses /geany/path, replacing \ with / and ignoring the prefix setting.
If you move geany.pc into \geany\path\lib, as in 1.23, the setting
becomes used, and you'll quickly see "geanypathinclude: no such file
or directory" on build. Unfortunately, waf does the opposite of
pkg-config, replacing / with \, so --prefix=/geany/path does not help.
But the installation works, since it's done by waf, and the plugins
don't care (AFAIK) what slashes are used on runtime.

BTW, the paths to Python are with  :)

-- 
E-gards: Jimmy
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] RFC: Proxy plugins

[Dimitar Zhekov]

On Tue, 13 May 2014 09:54:09 +0200
Thomas Martitz  wrote:

> Am 11.05.2014 20:31, schrieb Dimitar Zhekov:
> > On Sat, 10 May 2014 21:56:30 +0200
> > Thomas Martitz  wrote:
> >
> > On Sat, 10 May 2014 14:47:17 -0700
> > Matthew Brush  wrote:
> >
> >> +1 for some form of introspection/code generation.
> > Just to be clear: by "introspection", I don't mean *replacing* struct
> > GeanyDocument with GObject GGeanyDocument and so on for the entire API.
> > We may have a GGeanyDocument which represents (a) the GeanyDocument
> > structure, (b) all document_*() functions as geany_document_*() and (c)
> > all "document-" signals as "geany-document" with a GGeanyDocument
> > argument. We can't generate signals for GGeanyDocument "fields" being
> > changed directly from C, but we don't support such signals anyway.
> 
> That's two GeanyDocument APIs to maintain.

You don't want to maintain a mapping of GeanyDocument, but are have not
problems with maintaining 5 manually written introspections for it?..

> >> and it requires a lot of changes to Geany (doesn't it?).
> > It will require some changes, for example GGeanyDocument will not be
> > straight-forward because of our organisation of the document list.
> > Most will be additions though, with few (if any) API breaks.
> 
> So it does require non-trivial changes to the core, too?

Anything except manually written introspections for each language
requires changes in the core. I suggested a way to minimize them.

> > GeanyPy proxy = ~150 KB.
> > 5 language proxies = ~750 KB, code that will have to be written and
> > maintained. For comparision, geany/src/* = 1.9 MB.
> >
> > peas loader = ~15 KB, language support is in the core, and doesn't
> > change with the new Geany versions, so you don't have to worry about
> > any language(s) becoming unsupported/unmaintained.
> >
> 
> Don't be ridiculous. This calculation is severely flawed and you know that.

I don't know anything like that. 150 KB per proxy is the best estimate
we have at the moment.

> > To make an omelette, you have to break the eggs.
> 
> No, you don't. This can be implemented without breakage (at least for C 
> plugins, probably for existing python ones too).

Since you have the enthusiasm to write additional language support, not
me, and you are not willing to accept any suggestions, this discussion
is pointless.

-- 
E-gards: Jimmy
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] RFC: Proxy plugins

[Dimitar Zhekov]

On Sat, 10 May 2014 21:56:30 +0200
Thomas Martitz  wrote:

On Sat, 10 May 2014 14:47:17 -0700
Matthew Brush  wrote:

> +1 for some form of introspection/code generation.

Just to be clear: by "introspection", I don't mean *replacing* struct
GeanyDocument with GObject GGeanyDocument and so on for the entire API.
We may have a GGeanyDocument which represents (a) the GeanyDocument
structure, (b) all document_*() functions as geany_document_*() and (c)
all "document-" signals as "geany-document" with a GGeanyDocument
argument. We can't generate signals for GGeanyDocument "fields" being
changed directly from C, but we don't support such signals anyway.

> Am 10.05.2014 21:06, schrieb Dimitar Zhekov:
> >> After that I'd say that LibPeas is perhaps something to be considered
> >> for new application but not for our existing codebase. I think we want
> >> something that enables proxy plugins while maintaining API and ABI
> >> stability.
> > peas does does you describe, and provides build-in loaders for Python
> > 2/3 and JavaScript, i.e. standard languages. Please don't throw it away
> > before even trying to adapt it.
> 
> As you have mentioned, even for C plugins it's a major change,

I said moving a few strings to .ini, and adding a few macros.

> and it requires a lot of changes to Geany (doesn't it?).

It will require some changes, for example GGeanyDocument will not be
straight-forward because of our organisation of the document list.
Most will be additions though, with few (if any) API breaks.

> So why adapt peas when it requires a lot of changes *too* but also 
> severely breaks plugin API?
> 
> I must be missing something, but it essence it appears to me that 
> adapting peas requires no less effort than what I propose...

GeanyPy proxy = ~150 KB.
5 language proxies = ~750 KB, code that will have to be written and
maintained. For comparision, geany/src/* = 1.9 MB.

peas loader = ~15 KB, language support is in the core, and doesn't
change with the new Geany versions, so you don't have to worry about
any language(s) becoming unsupported/unmaintained.

We must have Geany API (structures and functions) introspected for all
new languages somehow. We can do that with large, manual, bug-prone
per-language introspection, or with one GLib introspection.

> ...but also implies a major plugin API breakage (while my proposal
> can be implemented without API breakage).

There will be small breakage for the .C plugins, but basicly all API
function calls and structures will be the same. For Python, the object
names will change. To make an omelette, you have to break the eggs.

-- 
E-gards: Jimmy
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] RFC: Proxy plugins

[Dimitar Zhekov]

On Fri, 09 May 2014 22:18:41 +0200
Thomas Martitz  wrote:

> Am 08.05.2014 02:33, schrieb Matthew Brush:
> > Hi Thomas,
> >
> > Disclaimer: I'm not a LibPeas expert or even user but from what I've 
> > read about it (the docs, tutorials) it sounds like pretty much exactly 
> > the end-goal we want for Geany plugins.

Read the documentation. It's only 6 base classes, 2 interfaces and 2
widgets. The widgets form simple plugin manager, but they are
completely optional, we can write our own using the current UI.

> Right, LibPeas was repeatedly suggested already. However, the first 
> reply was always "uhm it would probably require a massive rewrite" which 
> is kind of showstopper given how hard it is to get changes into the core.
> 
> Anyway, I have still looked into it and came to the conclusion that it's 
> not a good fit either way, for several reasons. Please correct me if I'm 
> wrong.
> 
> a) All API entry points have to be gir-introspectable, .i.e. 
> gobjectified. This is probably the massive rewrite that was suggested. 
> This also implies massive plugin API/ABI breakage

For C plugins, we just need to pass geany_data and geany_functions.
See peas-demo-window.c: peas_extension_set_foreach(),
g_signal_connect("extension-added") and the demo plugins.

For python, maybe we can include geanypy/src/*.c in Geany or in
a .so library. But if we don't want to end up with more 150+ KB proxies
like geanypy, we'd better use introspection. I really admire Matthew
and Lex for writing this thing, but that's hardly the best approach,
and I don't expect many people to repeat it and maintain such proxy.

> b) It would breaks the plugin API in more ways. For example, plugin 
> metadata shall be supplied via an .ini-style file.

Moving a few strings from foo.c to foo.ini will hardly be a problem. :)

> c) Plugins need to implement and expose a new gobject in order to be 
> even recognized as plugins (PeasEngine recognizes plugins/extensions by 
> their GType)

For C, it can probably be handled by 2 macros, REGISTER_PLUGIN and
REGISTER_PLUGIN_WITH_CONFIGURE. Our current plugins don't support
Activate, and the Help in peas is an URL, not a function.

> After that I'd say that LibPeas is perhaps something to be considered 
> for new application but not for our existing codebase. I think we want 
> something that enables proxy plugins while maintaining API and ABI 
> stability.

peas does does you describe, and provides build-in loaders for Python
2/3 and JavaScript, i.e. standard languages. Please don't throw it away
before even trying to adapt it.

-- 
E-gards: Jimmy
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] RFC: Proxy plugins

[Dimitar Zhekov]

On Fri, 09 May 2014 20:34:18 +0200
Thomas Martitz  wrote:

> Am 09.05.2014 19:15, schrieb Dimitar Zhekov:
> > On Fri, 09 May 2014 12:29:58 +0200
> > Thomas Martitz  wrote:
> >
> > Unless we are trying to enable scripting in more than a few languages,
> > I see no reason for all these complications. [...]
> 
> I accept that the status-quo is fine for you, but not for me and others. 
> IRC discussions repeatedly indicated that proxy plugins are the way to 
> go (the alternative is automagic bindings through gobject introspection 
> which isn't feasible right now).

I don't know the way to go, but there are two things we should not do:

1. Change the interface radically, gedit-style.

2. Introduce serious code changes that won't benefit the users. Proxy
plugins may be beneficial at some future point, or we may end up with
several poorly-supported languages, and later with unmaintained proxies
we dare not remove because that'll kill their sub-plugins.

> I suspect we would support 1 (or at most 2) proxy plugins ourself.

I hope by "we" you mean the core plugins. Otherwise, that's no "support"
at all.

> Other 
> proxy plugins can be maintained by third parties out of tree or in 
> geany-plugins. I do not want to hard-limit the language choice to our 
> blessed one though.

The other proxy plugins will be DOA, except for mini-plugins (macros,
scripts) that suit single users. Why should one bother to write a
serious, mass-distributable sub-plugin in a 3rd party language, when
there are official ones? To risk the proxy plguin being unmaintained?

-- 
E-gards: Jimmy
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] RFC: Proxy plugins

[Dimitar Zhekov]

On Fri, 09 May 2014 12:29:58 +0200
Thomas Martitz  wrote:

> >> The basic idea is that proxy plugins initially call a Geany API to
> >> register themselves as proxies, providing criterias to select potential
> >> plugins (for now, this is only a list of file extensions)
> >> Geany will match files against these criterias and, on match, call into
> >> the plugin for the first time.
> 
> What???
> 
> No, this isn't about loading plugins on demand. This is about 
> implementing APIs so that plugins (probably selected in the PM dialog) 
> can act as a proxy to plugins written in other languages (also selected 
> in the PM dialog). I do not intend to change the user experience w.r.t. 
> to plugins: All plugins, regardless of the language, are user-selected 
> in the PM dialog and loaded only then and on subsequent startups.

So then, the only remaining option seems that Geany will search the
plugin paths, and match the found file extensions. It's unclear what
call returns the sub-plugin metadata (name, version etc.), but that's
solvable.

Unless we are trying to enable scripting in more than a few languages,
I see no reason for all these complications. Let the master Foo plugin
search for and probe the found .foo files, display a list of them, and
save the list of selected ones in it's own configuration, without
involving Geany. I'd like to have 100 useful python (lua, js, ...)
scripts or macros, and will probably write my own, but certainly don't
want them as first class plugins.

As another option, we can declare one scripting language as official,
support the language binding for it, and provide the command console.
Vim, emacs and gdb have one, so why should the light IDE Geany
support N of them? And whoever wants to write a plugin to supports his
or her favorite REXX/VBScript/younameit is still free to do so.

Personally I'd choose a language that supports GTK+, *nix and Windows,
for obvious reasons.

-- 
E-gards: Jimmy
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] RFC: Proxy plugins

[Dimitar Zhekov]

On Wed, 07 May 2014 23:58:11 +0200
Thomas Martitz  wrote:

> Am 07.05.2014 19:59, schrieb Dimitar Zhekov:
> > On Wed, 07 May 2014 08:40:13 +0200
> > Thomas Martitz  wrote:
> >
> >> I'm (as of now) motivated to implement proxy plugins (to my amusement,
> >> until splitwindow2 gets finally reviewed...). Therefore I would like to
> >> receive comments on my proposed concept and APIs (further below).
> >
> > Feasible, but... why? Looks a bit like GTypePlugin to me, with it's
> > proxied "dynamic" classes, and nearly zero implementations.
> >
> 
> I'm not sure what GTypePlugin has to do with it. This isn't about 
> loading new GObject classes dynamically (proxy plugins aren't GObjects). 

It's not directly technically related, of course, just seems smiliar as
a mechanism, and as something without purpose.

> Perhaps you can elaborate a bit?

1. KISS.

2. Most plugins have UI. Loading plugins on demand means that the UI
will change dynamically, which is hardly a reason for celebrate.

3. Why can't one simply mark the plugins (s)he needs statically? If
there are any compatibility or resource usage problems, they should be
fixed in the original code, instead of relying that Geany will work
better by loading a smaller set of plugins on demand.

4. If we need dynamic loading (though I don't know of any reason for
that), why not extend the standard plugin API with criterias, and let
the "plugin enabled" checkbox in the PM dialog have a "half-checked"
position for plugins with criterias? Why proxiyng?

5. How do we choose which sub-plugins of a proxy plugin should be
enabled - a tree structure N levels deep? Obviously, one may not be
satisfied with the activation criterias, and may want specific 
sub-plugins explicitly enabled or disabled.

It seems to me that your idea mixes dynamic loading and proxying. These
are not actually related (except for the fact that the criterias, if
implemented, should be appliable to the sub-plugins, if implemented).

> The basic idea is that proxy plugins initially call a Geany API to 
> register themselves as proxies, providing criterias to select potential 
> plugins (for now, this is only a list of file extensions)

> Geany will match files against these criterias and, on match, call into 
> the plugin for the first time.

What exactly will it match - the extensions from the files in the
current session? So the PM dialog will contain a different list of
plugins each time it's open? And yet different list on startup, since
plugin_init() is before any files are loaded? Perpahs I don't
get your idea at all.

> Then when Geany generates the plugin list (i.e. when the user opens 
> plugin manager (PM) dialog) it'll call a second time into the proxy. 
> This time the purpose is to load the actual plugin, and install 
> plugin-specific init(), configure(), help() and cleanup() hooks.

An what happens if the user simply doesn't open the PM dialog - the
actual (sub-?)plugin is never loaded?..

I'm not against specific proxies - loading the interpreter or runtime
Foo once, instead of a copy for each plugin written in/with Foo, makes
sense. But that seems different from what you described, and the
sub-plugin search and choosing should be done by the master Foo plugin,
using the Foo language and/or runtime. Unless we are trying to build
language bridges for the sake of it, there will hardly be more than two
or three of those plugins.

-- 
E-gards: Jimmy
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] RFC: Proxy plugins

[Dimitar Zhekov]

On Wed, 07 May 2014 08:40:13 +0200
Thomas Martitz  wrote:

> I'm (as of now) motivated to implement proxy plugins (to my amusement, 
> until splitwindow2 gets finally reviewed...). Therefore I would like to 
> receive comments on my proposed concept and APIs (further below).

Feasible, but... why? Looks a bit like GTypePlugin to me, with it's
proxied "dynamic" classes, and nearly zero implementations.

-- 
E-gards: Jimmy
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] Implementing stdlib/glib in Geany

[Dimitar Zhekov]

On Sun, 27 Apr 2014 23:05:46 +0200
Colomban Wendling  wrote:

> Le 27/04/2014 22:28, Pavel Roschin a écrit :
> > I found interesting function in utils.c:
> > 
> > gboolean utils_str_equal(const gchar *a, const gchar *b)
> > 
> > - GLib has similar g_strcmp0 function since 2.16
> 
> Ouch indeed.  I just replaced the loop with a strcmp(), which performs
> roughly 5.4 times better (on a 64bits Linux) for dummy average strings.

g_strcmp0() checks for NULL strings, like utils_str_equal().
strcmp() will give you a segfault on NULL argument(s).

-- 
E-gards: Jimmy
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

[Geany-Devel] multiterm should be disabled if no valac is found

[Dimitar Zhekov]

$ ./autogen.sh
...
checking for valac... valac
configure: WARNING: no proper vala compiler found
configure: WARNING: you will not be able to compile vala source files
...
Plugins:
MultiTerm: yes

$ make
...
make[3]: Entering directory
`/home/build/projects/plugins/testing/multiterm/src'
VALAC multiterm_la_vala.stamp
/bin/bash: valac: command not found
make[3]: *** [multiterm_la_vala.stamp] Error 127

I fetched a clean git, just to be sure there's no some older
configuration left.

-- 
E-gards: Jimmy
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] Geany 1.23 Waf install under win32

[Dimitar Zhekov]

On Fri, 11 Apr 2014 00:16:41 +0200
Enrico Tröger  wrote:

> prefix=geany-1.24

I forgot to mention that I actually tried different prefixes for Geany
and Geany-plugins some time ago. :) That can never really work, because
we don't have a directory to serve as "plugins prefix" at runtime, only
the directory Geany is installed into and started from. Thus, the only
important thing is that the plugins should use this $prefix at
install, but not at runtime (like DESTDIR). Which seems to be fixed in
your "Add the installation prefix only to installed files" patch.

-- 
E-gards: Jimmy
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] Geany 1.23 Waf install under win32

[Dimitar Zhekov]

On Fri, 11 Apr 2014 00:16:41 +0200
Enrico Tröger  wrote:

> On 16/06/13 20:37, Dimitar Zhekov wrote:
> > On Sun, 16 Jun 2013 15:59:14 +0200
> > Enrico Tröger  wrote:
> > 
> >> On 06/16/13 15:11, Dimitar Zhekov wrote:
> >>>
> >>> - no header fiels are installed, or maybe they are copied somewhere
> >>> outside the $prefix. Copying the headers manually is OK.
> >>
> >> This is on purpose.
> >> For development, I use a custom script to copy the headers. However, we
> >> could add a custom action to Waf to copy/install the headers somewhere.
> >> The question is where is 'somewhere' on Windows?
> > 
> > Everything else is under $prefix, so why not in $prefix/include?
> > Moreover, that's what the .pc file says.
> > 
> >> IMO it doesn't make any sense to install the headers by default into the
> >> resulting directory, as this is usually used to create a release
> >> installer and this doesn't need headers.
> > 
> > Any installer allows to specify what should be included and what not...
> > 
> >> Would be a custom build action and maybe a destination path argument
> >> helpful?
> > 
> > ...but yes, such an action (install-devel?) will spare a few minutes.
> > 
> >> Btw, the geany.pc is also not installed, so probably this should be done
> >> in the same custom action.
> > 
> > Wasn't it installed in $prefix/lib/pkgconfig or something? If not,
> > install[-devel] should copy it.
> > 
> >>> - geany.pc contains paths with single backslashes, and plugins build
> >>> fails with "c:path1path2...: no such file or directory". Replacing
> >>> with forward slashes works. All other .pc files I've checked under
> >>> win32 use forward slashes.
> >>
> >> Are these paths used at all on Windows? At least for me the generated
> >> .pc file worked fine so far.
> > 
> > waf under win~1 requires pkg-config and really uses geany.pc, no doubt
> > about that.
> > 
> > If the headers are installed in/under some standard include directory,
> > or a directory mentioned in another .pc file, that may work... or the
> > backslash handling, or whether geany.pc file contains single or double
> > backslashes, may depend on the python version... I don't know, really.
> > In all cases, '/' is the safe bet, and all glib/atk/gdk/gtk...pc files
> > use forward slashes under win~1.
> 
> I committed a few changes to install header files and geany.pc also on
> Windows into $prefix when using Waf.
> 
> Additionally, I added a new section to the installer to optionally
> install these files also, disabled by default.
> 
> The generated geany.pc file doesn't container any backslashes on my
> system, only forward slashes.

Thanks. I will test that soon.

-- 
E-gards: Jimmy
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] Request to merge PR #226

[Dimitar Zhekov]

On Fri, 28 Mar 2014 12:06:24 -0700
Shankhoneer Chakrovarty  wrote:

> Last and least, pull request #191 and SF patch #11 are earlier than
> > #226. If one of them is applied, #226 will be seriously broken.
> >
> 
> I had no idea about these PRs. Thanks for pointing this out. I will check
> them.

Hmmm... I wrote to the mailing list about them, answering to "shan chak
", though that's not identical to your account.

> So I guess what you are trying to suggest is:
> 1. Generalize the behavior for all the programming languages supported by
> geany. I have to find out which languages generate warning messages and
> which dont, this may take some time.

For the old parser, I think covering the example messages will be
enough.

> 2. Remove the hard coding of line_idx+2

Looking at the D/HTML examples, a simple indexing will not work.

> 3. Make changes for both regex parsing as well as older parsing method

Regex should be covered, of course... though that'll lead to even more
conflicts between PR #226 and PR #191-or-SF patch #11.

> If I make these changes, will then you merge the PR? Or Do I need to do
> more changes? Please feel free to give me feedback. [...]

Disclaimer: I'm not a leading developer, and can't merge your changes.
What I can tell you, however, is that the current partial PR #226 is
not very likely to be considered.

As the author of SF patch #11, I plan to extend it for warnings, using
code from PR #226, except for the parsing. But I don't have time now.

-- 
E-gards: Jimmy
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] My PR isn't good ?

[Dimitar Zhekov]

On Fri, 28 Mar 2014 17:35:17 -0700
Matthew Brush  wrote:

> >> The last two are both windows.  None of the devs uses windows
> >> regularly [...]
> >
> > This may change. Recent kernel and x11 updates made my wi-fi and video
> > slower, and [...] I plan to give Windows a try.
> 
> You might like MacOS more than Windows if you like Linux, at least it 
> has bash and most common core utils and stuff, plus a proper terminal 
> emulator, and package managers to get good software onto it. The only 
> bad part is the user interface kind of sucks and you have to buy ugly 
> expensive hardware to run it, but it's still vastly better than Windows, 
> IMO :)

Novadays, there is a full set of coreutils, bash etc. for Win~1, and
they don't need Cygwin. It'll be interesting to see Android-x86,
though it can't be used for development.

-- 
E-gards: Jimmy
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] My PR isn't good ?

[Dimitar Zhekov]

On Fri, 28 Mar 2014 23:28:02 +1100
Lex Trotman  wrote:

> The last two are both windows.  None of the devs uses windows
> regularly (and some like me refuse categorically to do so) so windows
> changes will likely be slower than Linux ones anyway, simply because
> fewer people will look at them and they need to make a special effort
> to do so.

This may change. Recent kernel and x11 updates made my wi-fi and video
slower, and judging from the mailing lists, they will stay like this.
Given the inevitable gtk+3, I plan to give Windows a try. As soon as I
find out how to pull two years of updates before it catches a virus. :)

(Actually, one of the "offline" updaters has a bash download script.)

-- 
E-gards: Jimmy
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] Request to merge PR #226

[Dimitar Zhekov]

On Thu, 27 Mar 2014 16:27:07 -0700
Shankhoneer Chakrovarty  wrote:

> Hi guys,
> 
> I know everybody is busy with release of geany 1.24 .
> Can somebody please find sometime to merge
> PR#226 so
> that it goes to geany release 1.24?
> 
> If there is some problem please do tell me. I would fix it asap.

Min fields are fixed, but:

It still supports the buildin parser only (not regex), and the "gcc
like" syntax only (though the D and HTML examples have warnings).

It still assumes that "warning" is at line_idx + 2 (unless I'm
missing something), though the examples for the so called "gcc type
error" for JAVA and LATEX have it at line_idx + 1.

Last and least, pull request #191 and SF patch #11 are earlier than
#226. If one of them is applied, #226 will be seriously broken.

But we already discussed all this. Why do you insist on #226 in it's
current form?

-- 
E-gards: Jimmy
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] Hi!

[Dimitar Zhekov]

On Tue, 18 Mar 2014 09:26:54 -0700
Shankhoneer Chakrovarty  wrote:

> [...]
> 
> Can you please tell me what is SF and PR?

Local jargon. :)
SF bug/patch # = Geany sourceforge bug/patch tracker item #.
PR # = Geany githut pull request #.

> Also, can you please assign me a
> bug or a feature request? I know I can pick anything from the list but
> since I am new to this project, I think it will be better for me not to
> chose by myself any bug/feature thats too complicated for me to implement
> and mess up the code.

Well, an uncomplicated non-fixed bug is not easy to find, and the
leading developers should have a better look than me. You can
try http://sourceforge.net/p/geany/bugs/839/ if you have Windows.

As of the feature requests, they are highly subjective - everyone wants
his or her own thing, which nobody else may need/like. So you can just
choose whatever seems useful to you.

-- 
E-gards: Jimmy
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] Hi!

[Dimitar Zhekov]

On 3/16/14, Shankhoneer Chakrovarty  wrote:
>
> On Thu, Mar 13, 2014 at 11:42 AM, Dimitar Zhekov
> wrote:
>
> + {
>> +  *type = g_strstrip(g_strdup(fields[data->line_idx+2]));
>>
>> Errr, why do you assume that type is always at line_idx+2?..
>>
>
> As far as I could understand, geany parses the error message by gcc
> compiler. gcc compilers have specific error message format [...]

First, there are several build-in parser configurations, with
different separators and field indexes, example messages included. D
and HTML also have warnings.

Second, the examples under "All GNU gcc-like error messages" have only
"filename:line:whatever" is common, and the parser matches that
format. Nowhere is a column assumed, and line_idx+2 may not even
exist. The java examples clearly have type at line_idx + 1.

> http://gcc.gnu.org/onlinedocs/gcc-4.5.0/gnat_ugn_unw/Warning-Message-Control.html#Warning-Message-Control

This is for the gcc Ada compiler, and even if the entire gcc
standartized is standartized at 4.5, the stable debian still contains
gcc-4.4, so it's too early to drop it. And anyway,  Latex will not
gain more fields because the gcc documentation says so...

>> 1. You wrote support for the fallback parser only, and not for regex.
>>
>
> Yes because the regex parser was returning me NULL for c,cpp and java
> files, so I wrote for the fallback parser only. I was unable to find the
> root cause of why the regex parser is returning me NULL for these
> file types.

Well, I can assure you that the regex parser works...

>> 2. This should be considered after either pull request #191 or SF
>> patch #11 is applied. If the PR is chosen, this patch should be fully
>> rewritten as capturing group  or something similar.

...*sigh* maybe I should include warning recognition is SF #11, using
your styling code and different recognition.

--
E-gards: Jimmy
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] Hi!

[Dimitar Zhekov]

On Tue, 11 Mar 2014 01:35:50 -0700
shan chak  wrote:

> I pulled the geany source code, read the HACKING file and created a patch
> which categorizes the compiler errors into "error" and "warning" [...]

> If you guys have some time, can you please review the patch? If you need
> any more info, please feel free to drop me an email, I will be more than
> happy to explain it.

- data.min_fields = 3;
+ data.min_fields = 5;

Please note that parse_file_line() returns if length(fields) is less
than data->min_fields. With the above change, anything with < 4 colons
will be rejected.

+ if (g_strv_length(fields) == data->min_fields)

N/A: parse_file_line() returns on length(fields) < min_fields, and the
maximum fields to parse are min_fields, so length(fields) is always
equal to min_fields at this point.

+ {
+  *type = g_strstrip(g_strdup(fields[data->line_idx+2]));

Errr, why do you assume that type is always at line_idx+2?..

--

Finally:

1. You wrote support for the fallback parser only, and not for regex.

2. This should be considered after either pull request #191 or SF
patch #11 is applied. If the PR is chosen, this patch should be fully
rewritten as capturing group  or something similar.

-- 
E-gards: Jimmy
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] Code review for feature #683

[Dimitar Zhekov]

On Sat, 1 Mar 2014 11:28:13 +0100
Steven VALSESIA  wrote:

> Hi everybody !

Hi.

> Please, take a look to my patch concerning the feature request #683.

A disclaimer first: I'm not using the autosave actions plugin.
The code seems to match autosave closely, with no obvious errors.

> Let me know if you see how I can improve my code :)

First, the "editor-notify" signal is a tight spot, all Scintilla
events go there. Blocking them while saving may not be a good idea,
especially considering that a file save error may display a modal
dialog IIRC. You can do a plugin_idle_add(func) instead, and make
func() return FALSE.

Second, mentioning -lgthread-2.0 twice may be required, depending on
the libraries and linker, and won't do any harm otherwise.

-- 
E-gards: Jimmy
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] Plugins Quality Check

[Dimitar Zhekov]

On Fri, 21 Feb 2014 16:52:51 +0100
Colomban Wendling  wrote:

> >>> [...]
> > 
> > OK, I didn't think it was OK to assume GCC was the compiler,
> 
> It isn't, indeed.  Although well, to be fair we probably have no idea
> what happens if it's not GCC-like.  Or maybe I even remember there was
> problems with MSVC?

We disabled MSVC some time ago (see "geany-plugins fail to build with
msvc"). In short, cl recognices "template" as C keyword :) and the
CFLAGS / LDFLAGS obtained from pkg-config under win~1 are suitable
for gcc, not MSVC.

-- 
E-gards: Jimmy
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] DMAP file type

[Dimitar Zhekov]

On Wed, 12 Feb 2014 03:57:56 +1100
Lex Trotman  wrote:

> 1.24 is only waiting on a fix for a major bug in the windows version.
> We think we might have that fix now.

What is this bug?..

-- 
E-gards: Jimmy
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

[Geany-Devel] fix for regex error message parsing

[Dimitar Zhekov]

Hi,

As discussed in the "Compiler tab suggestions" thread, Geany regex
error message parsing is buggy - it fetches the matching strings by
index, but GRegex indexes all subgroups, returning empty string for
the non-matching ones. So using | for alternatives does not work,
and parsing a set of strings like:

filename:line:column: warning: passing argument # of 'function' from
incompatible pointer type
In file included from filename:line,
from filename:line,
...
from filename:line:
filename:line:column: note: expected 'foo' but argument is of type 'bar'

is either impossible, or requires a very complex expression.
This is a regression caused by our switch to GRegex.

Fix attached. Of course, it's a simple loop skipping the non-matching
groups by their start position. Tested with both filename:line and
line:filename.

-- 
E-gards: Jimmy
>From d9ff8a53c7ce71aa0d7ab79f57897ec205d17dad Mon Sep 17 00:00:00 2001
From: Dimitar Zhekov 
Date: Tue, 21 Jan 2014 20:22:28 +0200
Subject: [PATCH] fix regex error message parsing (GRegex indexes subgroups,
 not matches)

---
 src/filetypes.c | 22 +++---
 1 file changed, 19 insertions(+), 3 deletions(-)

diff --git a/src/filetypes.c b/src/filetypes.c
index 0048b34..4cd2eea 100644
--- a/src/filetypes.c
+++ b/src/filetypes.c
@@ -1627,11 +1627,27 @@ gboolean filetypes_parse_error_message(GeanyFiletype *ft, const gchar *message,
 	}
 	if (g_match_info_get_match_count(minfo) >= 3)
 	{
-		gchar *first, *second, *end;
+		gchar *first = NULL, *second, *end;
 		glong l;
+		gint i;
+
+		for (i = 1; ; i++)
+		{
+			gint start_pos;
+
+			g_match_info_fetch_pos(minfo, i, &start_pos, NULL);
+			if (start_pos != -1)
+			{
+if (first == NULL)
+	first = g_match_info_fetch(minfo, i);
+else
+{
+	second = g_match_info_fetch(minfo, i);
+	break;
+}
+			}
+		}
 
-		first = g_match_info_fetch(minfo, 1);
-		second = g_match_info_fetch(minfo, 2);
 		l = strtol(first, &end, 10);
 		if (*end == '\0')	/* first is purely decimals */
 		{
-- 
1.8.5.2

___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] Compiler tab suggestions

[Dimitar Zhekov]

On Sun, 19 Jan 2014 19:34:01 +0200
Arthur Rosenstein  wrote:

> > utils.c:643:33: error: expected ')' before 'xxx'
> > 
> > Double click on the message: seeks to the first 'x', Geany status
> > bar shows line 643, column 43 (column # depends on the tab size).
> > 
> > But it *does* seek to 'а' if "боза" is locale.
> 
> Indeed, my bad. You're not treating "column numbers" as column numbers
> but rather UTF-8 byte offsets. That's definitely more common, but not
> universal still.

A truly universal solution should take into account whether the compiler
emits utf-8 columns (java?/net?/python3?), or what is the file locale +
whether the compiler takes into account the system locale + what is the
system locale. Geany sets the GLib I/O channel encoding to NULL "safe
to use with binary data", so at least that should not have any effect.

> > echo "test.py:7: E202 whitespace before ']'" |
> > egrep '([^:]+):([0-9]+):([0-9]+):|([^:]+):([0-9]+): '
> > test.py:7: E202 whitespace before ']'

> Did you actually test it? You're using g_match_info_fetch() to read the
> submatches of the first three *capture groups*. Those are indexed
> independently of the string you're trying to match. So, even though the
> pattern does match the error message in the file:line case, you're
> reading the source-location info from the capture groups that didn't
> match anything.

No, I assumed that Geany works as documented, and reads the first two
matches. Looking at regex(1), it probably worked like that before
switching to GRegex.

> Note that in this case the solution is simple enough:
> "([^:]+):([0-9]+)(?::([0-9]+))?: ", but the general limitation is
> still there.

It's not a limitation, but a bug in the current regex parser. We
should either document that the first two capturing groups are used,
no matter if they match, or skip the non-matching groups (which is
quite easy). After that, P11 can be updated - fixing the regex parser
is outside it's scope.

-- 
E-gards: Jimmy
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] Compiler tab suggestions

[Dimitar Zhekov]

On Sat, 18 Jan 2014 17:10:37 +0200
Arthur Rosenstein  wrote:

> I took a quick glance at patch 11 [...] It treats compiler "column
> numbers" as if they're actually column numbers, while in reality
> they almost never are. Which means that it's not going to work
> right as soon as the code contains tabs or multibyte characters.

Hmmm... :)

(s - text == 10 && "боза" xxx ... [utf-8]

utils.c:643:33: error: expected ')' before 'xxx'

Double click on the message: seeks to the first 'x', Geany status
bar shows line 643, column 43 (column # depends on the tab size).

But it *does* seek to 'а' if "боза" is locale.

> Since it doesn't use named capture groups for the message
> parsing, it's a little less flexible in the type of messages
> it can parse

line [column] filename, or filename line [column]

If no regex is specified (and most people leave it blank I think),
the "fallback" Geany parser requires only one of filename or line
(default filename == that of the current document).

With a regex, both the filename and line are mandatory (though the
regex Geany parser can be modified to make the line optional).

P11 adds an optional column without altering the above behaviour.

> and it also cannot handle different
> styles of error messages in the same regex.

expr1|expr2|...

Or if you mean errors vs. warnings, Geany does not support such a
distinction, and P11 only adds an optional column.

> The example given in the documentation is actually
> not going to work when the column number is missing.

echo "test.py:7:24: E202 whitespace before ']'" |
egrep '([^:]+):([0-9] +):([0-9]+): |([^:]+):([0-9]+): '
test.py:7:24: E202 whitespace before ']'

echo "test.py:7: E202 whitespace before ']'" |
egrep '([^:]+):([0-9]+): ([0-9]+): |([^:]+):([0-9]+): '
test.py:7: E202 whitespace before ']'

Overall, P11 is a minimal implementation, which handles most of
the cases, with very small regex changes (an optional 3rd match).
PR 191 is the maximum implementation. Both have pros and cons.

IMHO, such questions should be decided with a vote.

-- 
E-gards: Jimmy
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] Compiler tab suggestions

[Dimitar Zhekov]

On Sun, 12 Jan 2014 20:16:26 +1100
Lex Trotman  wrote:

> On 12 January 2014 11:17, Steven Blatnick  wrote:
> 
> > My external-tools plugin takes file paths and opens them like a blue link
> > in a webpage. The output is in a textarea-like instead of those table tree
> > structures. Maybe if the compiler pane output to a text buffer like that,
> > then maybe fonts would help. My plugin uses a monospaced font. (See
> > github.com/sblatnick/geany-plugins external-tools branch and directory).
> >
> 
> Havn't tried your plugin, but like the the idea of using gtk_text_view
> widgets with file/line/column references text marked as links (instead of
> the gtktreeview and click on the whole line we use now).

Currently, single click or space positions you at the error/warning,
and double click/enter positions and focuses the editor. That's not
reproducible with a single link.

> This would also mean that text can be copied from the view (a regular
> issue/request).

Right click -> Copy, Copy All. Though it may be better to have multiple
selection for copying and use the cursor row for document positioning.

> The text view (when its not user editable as we would use it) is also less
> complicated than the tree view, and IIUC faster to add lines to, another
> bugbear with the treeview.

"Easier" as in "doesn't require/support structured data"? :)

-- 
E-gards: Jimmy
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel