[Geany-Devel] Re: How to generate geany.txt HTML with meson?

[Nick Treleaven via Devel]

On Fri, 10 Feb 2023 at 19:23, Jiří Techet  wrote:

> Hi Nick,
>
> doesn't
>
> meson -Dhtml-docs=enabled builddir
>
> do the job? You can find all the Geany's configuration options in
>
> https://github.com/geany/geany/blob/master/meson_options.txt
>

I saw that file but didn't know the -D option, thanks. Meson's new to me (I
had to pass --reconfigure too).
___
Devel mailing list -- devel@lists.geany.org
To unsubscribe send an email to devel-le...@lists.geany.org

[Geany-Devel] How to generate geany.txt HTML with meson?

[Nick Treleaven via Devel]

Hi all,
Thanks to Thomas Martitz for adding the meson build system.

After much googling I can't work out how to build geany.html. Please let me
know.

Thanks,
Nick
___
Devel mailing list -- devel@lists.geany.org
To unsubscribe send an email to devel-le...@lists.geany.org

Re: [Geany-Devel] Problem with pointer from API function -- solved

[Nick Treleaven]

Thanks, this info should be added to HACKING to explain how to add API
symbols.

On Tue, 27 Aug 2019 05:29 Austin Green,  wrote:

> Hi All,
>
> OK, after further research I have stumbled on the answer:
>
> As well as adding the GEANY_API_SYMBOL macro to the function definition,
> the function declaration in keybindings.h also needs to be moved from the
> #ifdef GEANY_PRIVATE
> section, into the 'public' section.  Dereffing the returned pointer then
> works fine.
>
> I expect this is documented somewhere, though I haven't found it.  Thanks
> to all for not responding with 'RTFM'.   :)
>
> Cheers,
> Austin.
> ___
> Devel mailing list
> Devel@lists.geany.org
> https://lists.geany.org/cgi-bin/mailman/listinfo/devel
>
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] Building geany on Windows is slow; libgeany

[Nick Treleaven]

>
> Building libgeany and geany.exe takes at least a minute with autotools. I
> resurrected the Windows makefiles and updated them to build libgeany.dll,
> they only take ~2s to do that.
>

Here I meant just making the dll and exe, not compiling the .la or .o files.
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] Building geany on Windows is slow; libgeany

[Nick Treleaven]

It's Windows Vista, I don't have a Linux system available. Building
libgeany and geany.exe takes at least a minute with autotools. I
resurrected the Windows makefiles and updated them to build libgeany.dll,
they only take ~2s to do that.

Commit:
https://github.com/ntrel/geany/commit/421affbbc92b66a2a128537c97ddbe0f36be89d1
Branch (contains unrelated work):
https://github.com/ntrel/geany/tree/dtags

On 26 January 2018 at 08:29, Thomas Martitz  wrote:

> Am 25.01.2018 um 18:27 schrieb Colomban Wendling:
>
>> Le 25/01/2018 à 04:38, Lex Trotman a écrit :
>>
>>> On 25 January 2018 at 22:19, Nick Treleaven  wrote:
>>>
>>>> Hi,
>>>> I hadn't built Geany for a while, I found the MSYS2 build instructions
>>>> with
>>>> autotools. Libtool seems incredibly slow - mainly for linking but even
>>>> compiling is slow. I've tried disabling AV to no effect. Are there any
>>>> simple workarounds? The modify-rebuild cycle is painful now.
>>>>
>>> Long time no hear.  I can't help with Windows build speeds but can say
>>> that the Linux build does not appear to be significantly slower
>>> AFAICT.
>>>
>> No.  By default libtool might build object files twice, one static and
>> one shared, just in case it might need both, but I disabled it ages ago
>> as we don't need both
>> (https://github.com/geany/geany/commit/723f4302e0d7bbd938c78
>> 9b9730366f7c7e03080).
>>   Maybe check if libtool on Windows doesn't enforce something stupid like
>> that.
>>
>> But it might also be that MSYS2 is slow or something, but that Thomas
>> might know more about.
>>
>
> From my experience (it's been some time) shell scripts (i.e. configure) is
> horribly slow (disabling AV helps a lot but it's still bad), the
> compilation itself shouldn't be significantly slower than on Linux.
>
> Can you compare a against Linux builds and post some numbers? Also, what
> kind of system is this?
>
> Best regards
>
> ___
> Devel mailing list
> Devel@lists.geany.org
> https://lists.geany.org/cgi-bin/mailman/listinfo/devel
>
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

[Geany-Devel] Building geany on Windows is slow; libgeany

[Nick Treleaven]

Hi,
I hadn't built Geany for a while, I found the MSYS2 build instructions with
autotools. Libtool seems incredibly slow - mainly for linking but even
compiling is slow. I've tried disabling AV to no effect. Are there any
simple workarounds? The modify-rebuild cycle is painful now.

Also, I'm curious as to why .lo files are built and also interested as to
any info about libgeany.

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

Re: [Geany-Devel] Tab context menu suggestion

[Nick Treleaven]

On 19/02/2015 18:38, Steven Blatnick wrote:

Another thought, is there a way to disable the full list of open tabs
from that context menu so my list isn't so long to get to the power
options?


I sometimes find switching between firefox and geany to be disorienting 
when I want to show the tab list - perhaps having firefox's drop-down 
button on the right would be better.

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

Re: [Geany-Devel] Tab context menu suggestion

[Nick Treleaven]

On 19/02/2015 18:38, Steven Blatnick wrote:

Personally, I'd rather have something like "close from here
before/after" or "close before/after" in place of "close everything
else", but there is no reason geany couldn't have both.


I agree that Close Other Documents isn't very flexible. An alternative 
is to use the symbol list Documents pane - right clicking on a folder 
allows closing all files under it. There could be a 'Close All in 
Folder' notebook tab option to expose this function more.

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

Re: [Geany-Devel] using Coverity to audit the code base

[Nick Treleaven]

On 12/02/2015 21:21, Liviu Andronic wrote:

Coverity has uncovered ~55 implementation defects in the code
base, with 25 or so of high severity (memory corruption, resource
leaks, etc.)


Thanks. Some of this should be useful, but AFAICT some of the serious 
items seem to occur when certain assertions have failed, e.g. TagManager 
Assert, which cause a lot of false positives.

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

Re: [Geany-Devel] Problems with building/Scintilla on Windows

[Nick Treleaven]

On 18/01/2015 14:10, Enrico Tröger wrote:

GTK itself defines them.


Oh right, thanks. I think it didn't at first, anyway, another flag I can 
remove from makefile.win32 sometime ;-)

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

Re: [Geany-Devel] Problems with building/Scintilla on Windows

[Nick Treleaven]

On 18/01/2015 14:20, Enrico Tröger wrote:

On 17/01/15 13:28, Nick Treleaven wrote:

Anyway, I gave up trying to fix the makefiles and tried Waf. It seemed
to work, but now when using Geany autocompletion shows an empty list. It
keeps doing this for a while on typing, then later I start typing again
and Geany freezes - this is not a hang, task manager doesn't show Geany
using CPU. I have to kill it. This is weird, and annoying because I
don't know how to get a backtrace (Ctrl-Z doesn't seem to work on my
Windows gdb, and anyway the process seems stuck rather than looping). I
suspect a fault with Scintilla, but it could be unrelated.



Maybe it's a bug in GTK+? Which version are you using? It might be
worthwhile to test with some different version of the bundle just to see.


Maybe, I haven't updated it in ages (GTK 2.22.0, GLib 2.26.0), it still
works for Geany master a month or two ago. But maybe some recent code
triggered a bug in it, perhaps the Scintilla 1.52 update. Next week I
will try and bisect the commit that did it, and perhaps try updating GTK
too.


Does the empty auto completion list look like this?
http://lists.geany.org/pipermail/devel/attachments/20141014/0cc74183/attachment-0002.png


Yes, pretty much. I'm not using RDP.


This is what I experienced some time ago. I assumed it might be related
to RDP which I use to connect to my Windows box.
If you got the same thing and you are not using RDP, it might something
more serious.

I don't remember to experience any hangs but I don't really use Geany on
Windows except for making Windows builds.

Hah, I just tried the Windows nightly builds (i.e. download the ZIP and
extract it over my existing Geany installation) and then the auto
completion list is filled and usable again on my system.
So it might be related to the differences in how the Geany binary is
created (the nightlies are also built using Waf but cross-compiled, not
native Windows builds).

Nick, can you confirm that the nightly builds work better?


I just tried it (was offline for the weekend ;-)), the nightly does have 
the correct autocompletion list.


Thanks for the info.

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

Re: [Geany-Devel] Problems with building/Scintilla on Windows

[Nick Treleaven]

On 15/01/2015 19:19, Matthew Brush wrote:

Related to lib iberty:

https://github.com/geany/geany/commit/1dc09597b24d19683abc597d45d7c28d37c199f0


OK, so probably I can remove it from makefile.win32.


Anyway, I gave up trying to fix the makefiles and tried Waf. It seemed
to work, but now when using Geany autocompletion shows an empty list. It
keeps doing this for a while on typing, then later I start typing again
and Geany freezes - this is not a hang, task manager doesn't show Geany
using CPU. I have to kill it. This is weird, and annoying because I
don't know how to get a backtrace (Ctrl-Z doesn't seem to work on my
Windows gdb, and anyway the process seems stuck rather than looping). I
suspect a fault with Scintilla, but it could be unrelated.



Maybe it's a bug in GTK+? Which version are you using? It might be
worthwhile to test with some different version of the bundle just to see.


Maybe, I haven't updated it in ages (GTK 2.22.0, GLib 2.26.0), it still 
works for Geany master a month or two ago. But maybe some recent code 
triggered a bug in it, perhaps the Scintilla 1.52 update. Next week I 
will try and bisect the commit that did it, and perhaps try updating GTK 
too.


Is anyone using a recent build of Geany master on Windows (with working 
autocompletion)?

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

Re: [Geany-Devel] Problems with building/Scintilla on Windows

[Nick Treleaven]

On 15/01/2015 14:17, Nick Treleaven wrote:

I also noticed Waf doesn't seem to use -mms-bitfields, but I'm not certain.


I think I'm wrong about that - it was based on git grep. Running 'waf 
-v' does show that flag (sometimes several times in the same command). I 
haven't found where Waf gets it from though ;-)

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

[Geany-Devel] Problems with building/Scintilla on Windows

[Nick Treleaven]

Hi,
This is a bit rambling but I'm kind of stuck now.

I hadn't kept up to date with git master for a while. I ran into trouble 
with the windows makefiles (makefile.win32) - GTK was not defined even 
though -DGTK is passed. So I hacked PlatGTK.cxx to define it manually, 
but on running the resultant Geany aborts - a backtrace showed some 
Scintilla code (Document::Document) causing the fault. (I also had to 
remove -liberty as that doesn't seem to be part of my MinGW install).


Anyway, I gave up trying to fix the makefiles and tried Waf. It seemed 
to work, but now when using Geany autocompletion shows an empty list. It 
keeps doing this for a while on typing, then later I start typing again 
and Geany freezes - this is not a hang, task manager doesn't show Geany 
using CPU. I have to kill it. This is weird, and annoying because I 
don't know how to get a backtrace (Ctrl-Z doesn't seem to work on my 
Windows gdb, and anyway the process seems stuck rather than looping). I 
suspect a fault with Scintilla, but it could be unrelated.


I also noticed Waf doesn't seem to use -mms-bitfields, but I'm not certain.

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

Re: [Geany-Devel] Proposal: move tag type ctags->geany mapping out of individual parsers

[Nick Treleaven]

On 07/11/2014 17:26, Colomban Wendling wrote:

Yep, I was thinking the same a few days ago while discussing a little
CTags shared library, and had the same idea


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

Re: [Geany-Devel] Linkage-Cleanup Build System Breakage

[Nick Treleaven]

On 25/10/2014 19:37, Matthew Brush wrote:

I can probably fix-up the makefile.win32 files if nobody else will as
it's just plain GNU make and should be similar changes as the Autotools.


OK.


It will require a couple more *nix utilities, namely `sed`, `sort`, and
`uniq` (or a `sort` that supports the `-u` option). A quick search finds
sed[1] and coreutils[2] which contains `sort` (probably with -u option)
and `uniq`. I assume MSYS also includes these common utils.


I suppose that's OK. The doc target already needs sed, but building the 
docs is optional. We might want to either require MSYS to build on 
Windows (currently it's an option), or otherwise update the website 
instructions about how to install the other utilities.

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

[Geany-Devel] ctags fork

[Nick Treleaven]

Colomban mentioned this recently, it's got quite a lot of updates over 
the original ctags AFAICT:


https://github.com/fishman/ctags

Just thought I'd share here. They have a Go parser, should any Go people 
wish to add it to Geany.

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

Re: [Geany-Devel] Moving notebook tab keybindings broken

[Nick Treleaven]

On 12/10/2014 17:01, Colomban Wendling wrote:

Done
https://github.com/geany/geany/commit/f5230f334e28248c91fa6f58f3557f0b40f40233


Thanks for fixing, that was fast ;-) Will test tomorrow but looks good.
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

[Geany-Devel] Moving notebook tab keybindings broken

[Nick Treleaven]

keybindings.c:cb_func_move_tab needs to be updated now ScintillaObject 
is not a child of main_widgets.notebook.

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

Re: [Geany-Devel] Glade progress

[Nick Treleaven]

On 24/04/2014 06:11, Thomas Martitz wrote:

Hello,

I want to let you knows know that glade upstream just merged my
backports for the "topological sorting algorithm" into glade-3-8 branch.
This means that we can now use upstream glade for our geany.glade as the
major outstanding deficiency is fixed: it now sorts the generated xml in
a predictable and stable manner, suitable for diff-review and probably
git merges too.

The backports should appear in 3.8.5 if you'd like to wait for a realease.


Great, thanks. I forgot to check again for a Windows release until I 
needed it now (it was made on 2014-05-18):


http://ftp.gnome.org/pub/GNOME/binaries/win32/glade/3.8/

Maybe we should list 3.8.5 as known-good in HACKING.

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

Re: [Geany-Devel] Patch: Enable per project line wrapping

[Nick Treleaven]

On 25/09/2014 09:33, Tim Tassonis wrote:

Hi all

As threatened two weeks ago, I now created a patch to geany to enable
line_wrapping on a per-project basis. Seems to be working fine, I put
the checkbox to enable it on the Editor tab of the project properties.

I hope I did everything right:
- git clone git://github.com/geany/geany.git geany
- Made my changes
- Did a fresh git pull
- git commit -a
- git format-patch HEAD^


I attach the resulting patch to the email, please tell when you need it
in another way.


Thanks, I turned it into a pull request as it may need a few tweaks (and 
it's easier for people to review there):


https://github.com/geany/geany/pull/337

You can follow comments there, if you have any questions about using 
github feel free to ask ;-)


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

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

[Nick Treleaven]

On 23/09/2014 00:57, Matthew Brush wrote:

I've been using Xubuntu for nearly as long as I've been using Linux and
it's been a great distro+DE configuration; familiar, painless,
configurable, minimal, few bugs, each distro upgrade goes super smooth,
and otherwise the whole thing stays out of the way.


It was actually Xubuntu 11.04 (so a few years ago) which broke when I 
dist-upgraded. The system wouldn't boot.

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

Re: [Geany-Devel] SourceFarce

[Nick Treleaven]

On 01/09/2014 03:27, Matthew Brush wrote:

I deleted my Source Forge account after like 20 times of losing my
comments. This final time it was a detailed C++ explanation on
Scintilla's bug tracker that took a lot of thought and effort to write,
which as usual I lost


I've not used it much, but last week I experienced this. Submitting a 
comment when I'm apparently logged-in then made me login again, where I 
am greeted by the same page without my comment. Hitting back failed to 
allow me to recover my 'unsubmitted' comment (that sometimes works on 
other sites). Perhaps there's some kind of login timeout, but either way 
the situation sucks.

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

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

[Nick Treleaven]

On 21/09/2014 14:48, Dimitar Zhekov wrote:

I finally sat on my back and migrated to Windows. It's not a good system
either, but gets the job done.


Welcome, I did the same when I replaced a broken laptop, installing 
Ubuntu, which refused to boot after I did a dist-upgrade. I didn't have 
the energy to download and reinstall another linux. The upside is that 
you don't have to dist-upgrade Windows just to run the latest software. 
The downside: no package management, malware, slow malware scanners.



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


Such as?


probably use it as a debugger only, and limit myself to the official
releases


I've not had any trouble building from Git with MSYS. Occasionally it 
needs simple fixes to compile.



But there will be no gtk+4 support,
at least not from me.


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

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

Re: [Geany-Devel] per-project line wrap

[Nick Treleaven]

Hi,

On 10/09/2014 16:47, Tim Tassonis wrote:

Since I want to start to do some text writing with geany as well, I'd
like to toggle line wrapping on a project basis, which currently does
not seem to be possible.

My question is: Would you take a patch to enable this or is there a good
reason not to implement it?


Should be fine, it's something I've wanted too.
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] [ANN] document_find_by_id() added to plugin API

[Nick Treleaven]

On 28/08/2014 16:21, Nick Treleaven wrote:

Code that uses doc->is_valid or DOC_VALID() outside of iterating
documents_array probably should be using document_find_by_id() instead,
because closed document pointers only stay invalid until another
document needs to be opened.


Additional: if there is no chance of another document having been opened 
since, but there is a chance a document was closed, it should be fine to 
check doc->is_valid.

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

[Geany-Devel] [ANN] document_find_by_id() added to plugin API

[Nick Treleaven]

See:
http://www.geany.org/manual/reference/document_8h.html#aa14a04c6596cd3261b325c73cb21866f

Real-world example when clicking a Messages item:
https://github.com/geany/geany/commit/18181c2e9043add8b13c1fc94c66db2ca5b885be#diff-3

Code that uses doc->is_valid or DOC_VALID() outside of iterating 
documents_array probably should be using document_find_by_id() instead, 
because closed document pointers only stay invalid until another 
document needs to be opened.


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

Re: [Geany-Devel] build.c missing win32.h include

[Nick Treleaven]

On 01/08/2014 12:23, Lex Trotman wrote:

Maybe magic somewhere, the windows nightlys are passing:)

I appears that the "magic" is that the compile options are not strict
enough, there are lots of implicit prototype warnings, but they are
not errors.


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

Re: [Geany-Devel] build.c missing win32.h include

[Nick Treleaven]

On 01/08/2014 13:38, Colomban Wendling wrote:

Le 01/08/2014 13:03, Nick Treleaven a écrit :

On 01/08/2014 11:48, Nick Treleaven wrote:

I'll just add the includes manually


https://github.com/geany/geany/pull/308


Looks good to me, I merged it :)


Thanks.

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

Re: [Geany-Devel] build.c missing win32.h include

[Nick Treleaven]

On 01/08/2014 12:13, Lex Trotman wrote:

On 1 August 2014 20:48, Nick Treleaven  wrote:

On 01/08/2014 11:43, Nick Treleaven wrote:


I can't work out how other files like dialogs.c include win32.h



Update: it isn't either ;-) So I suppose I'll just add the includes
manually. I thought maybe there was some magic happening somewhere.


Maybe magic somewhere, the windows nightlys are passing :)


Hmm, probably they don't use the makefile.win32 makefiles.

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

Re: [Geany-Devel] build.c missing win32.h include

[Nick Treleaven]

On 01/08/2014 11:48, Nick Treleaven wrote:

I'll just add the includes manually


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

Re: [Geany-Devel] build.c missing win32.h include

[Nick Treleaven]

On 01/08/2014 11:43, Nick Treleaven wrote:

I can't work out how other files like dialogs.c include win32.h


Update: it isn't either ;-) So I suppose I'll just add the includes 
manually. I thought maybe there was some magic happening somewhere.

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

[Geany-Devel] build.c missing win32.h include

[Nick Treleaven]

Hi,
I haven't built Geany for some time. I remember there was some 
refactoring of headers, and now build.c errors because 
win32_expand_environment_variables is not declared. Adding the win32.h 
include fixes it, but I can't work out how other files like dialogs.c 
include win32.h, it doesn't seem to be manually included anywhere. 
What's the correct fix?


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

Re: [Geany-Devel] [RFC]: Public API comments in headers

[Nick Treleaven]

On 26/05/2014 01:23, Lex Trotman wrote:

>If we moved to having public headers that just included actual public
>symbols, I think it would be advantageous to have those headers totally
>commented/documented rather than requiring the user to download Geany's
>source code and cross-reference functions in it to access the comments/docs,
>or getting hold of the generated Doxygen API documentation.

Its neater to have them in the public .h file sure, but I suggest that
they are going to be less likely to be kept up to date that way.  Most
of the editing happens in the .c files (I don't even open the .h much
of the time) so the doxygen comments in headers become out of sight,
out of mind.


Agree, that's an important reason. Another benefit is less rebuilding 
due to header file changes.


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

Re: [Geany-Devel] Plugin API design question/change proposal

[Nick Treleaven]

On 20/05/2014 10:29, Matthew Brush wrote:

Does anyone know why the plugin API was designed to use a bunch of
structures containing function pointers, hidden behind macros in
geanyfunctions.h? I found the commit where this stuff was added
initially (ie. plugin ABI 2-3) but it doesn't mention why it was done
like this and I tried to search the mailing list archives but Gmane
won't let me search and the other mailing list archive doesn't go back
that far.

Somebody mentioned it might be because Windows doesn't export symbols by
default, but it still doesn't explain why this way chosen over
explicitly exporting the symbols using
__declspec(dllexport)/G_MODULE_EXPORT which, IIUC, does just this.


The idea was to avoid exporting private symbols, and also to avoid 
having to build the binary with any dynamic link flags. Since the Glade 
3 change, the binary has dynamic link flags anyway, so the reason for 
this is gone.


Note: It's a bit annoying that all binary symbols are exported (on some 
platforms), ideally only symbols marked with some kind of export 
attribute would be.

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

Re: [Geany-Devel] On document pointer recycling

[Nick Treleaven]

On 27/10/2013 13:11, Thomas Martitz wrote:

My concern is that we might not find all the code that assumes
documents aren't freed. Some code might not be updated and would
access the wrong memory. I'm not certain, but I think there may be
some code that retains pointers without checking is_valid. Maybe I'm
being over-cautious.



If that would be the case it is buggy now and will be buggy afterwards.


So you don't distinguish between different levels of buggy? I.e. not 
working correctly vs crashing intermittently?

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

Re: [Geany-Devel] On document pointer recycling

[Nick Treleaven]

On 26/10/2013 20:29, Matthew Brush wrote:

If the GeanyDocument were a GObject (or we added hand-rolled reference
counting), the document would never get freed from under the code that
uses them's backs.


My concern is that we might not find all the code that assumes documents 
aren't freed. Some code might not be updated and would access the wrong 
memory. I'm not certain, but I think there may be some code that retains 
pointers without checking is_valid. Maybe I'm being over-cautious.


Personally I think reference counting would be OTT for this 
(particularly manually incremented/decremented ref counting), there 
doesn't seem to be a sensible reason to free document memory IMO.

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

Re: [Geany-Devel] On document pointer recycling

[Nick Treleaven]

On 26/10/2013 13:17, Nick Treleaven wrote:

* remove GeanyDocument::index and fix any code that uses it
* review all code indexing documents_array and fix any code retaining an
index (I expect that is rarer than code using GeanyDocument::index).
* change documents_array to only contain valid documents, i.e. on close
we swap the last valid document pointer with the pointer being removed,
and decrement the length by 1.


As Dimitar mentioned, this will affect any loops that close documents. 
Hopefully there aren't many of them, they would need to be fixed.


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

Re: [Geany-Devel] On document pointer recycling

[Nick Treleaven]

On 26/10/2013 13:17, Nick Treleaven wrote:

* change documents_array to only contain valid documents, i.e. on close
we swap the last valid document pointer with the pointer being removed,
and decrement the length by 1.


Actually *move* rather than swap, and set the invalid slot to NULL to 
catch any overshooting index.

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

Re: [Geany-Devel] On document pointer recycling

[Nick Treleaven]

On 26/10/2013 00:22, Lex Trotman wrote:

On 26 October 2013 00:01, Nick Treleaven wrote:


On 24/10/2013 10:24, Lex Trotman wrote:


Okay, but you still agree that doc->is_valid should be removed eventually?

That's a step forward:)




Of course I agree.  So its not a terribly big step:)



I only skimmed the discussion, but how can we remove that?



Given your experience it would be good if you could read the discussion and
give your perspective on what the previous posters have discussed regarding
handling doc pointers properly.


I read the discussion.

In summary, I think there are 3 issues:
* forgetting to check is_valid when iterating documents
* freeing memory
* code that uses is_valid to check if a document still exists, which is 
bad practice


I think freeing memory is a non-issue, I think you (Lex) agree with me 
on that. It's not a memory leak, it may be reused later.


The first point needs to be handled before the last one (assuming each 
are worth fixing). I think we can:


* remove GeanyDocument::index and fix any code that uses it
* review all code indexing documents_array and fix any code retaining an 
index (I expect that is rarer than code using GeanyDocument::index).
* change documents_array to only contain valid documents, i.e. on close 
we swap the last valid document pointer with the pointer being removed, 
and decrement the length by 1.

* use a free list for invalid documents

The last point is important to ensure no memory corruption bugs are 
introduced. I think it is harder to find the code that retains document 
pointers (and there is some), so I recommend we don't free document 
memory. At least, we would need a better reason to do so IMO than just 
memory usage, which is insignificant.


Now, once we've done that it's no longer needed to check is_valid when 
iterating documents. Possibly we could remove is_valid, but I think that 
is less important to do. Note that if we do all the steps above, we 
don't need to break the API, only the ABI. I can't guarantee that bugs 
won't be introduced due to these changes, but it seems fairly reliable.

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

Re: [Geany-Devel] On document pointer recycling - doc->is_valid

[Nick Treleaven]

On 24/10/2013 10:24, Lex Trotman wrote:

Okay, but you still agree that doc->is_valid should be removed eventually?
>That's a step forward:)


Of course I agree.  So its not a terribly big step:)


I only skimmed the discussion, but how can we remove that?

I think freeing document memory has high potential to break things. 
There are a few places where Geany assumes document memory isn't freed 
over time.


If people don't like foreach_document (or Matt's improved C99 
foreach_doc with document pointers), we could add document_get_all or 
something that returned a list of valid pointers. That can be done 
without breaking existing code. Personally I prefer Matt's suggested 
macro because you don't have to free the list.

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

Re: [Geany-Devel] Ping on Bug #943 - windows build command

[Nick Treleaven]

On 05/10/2013 14:59, Nick Treleaven wrote:


Maybe to you, but it's very common on Windows to have spaces in the path
names, it's even the default on Windows XP (Documents and Settings). To
most people (ex. the bug reporters) it seems outright broken now,
whereas before it worked.


See my other mail, I made a pull request.


New pull request:
https://github.com/geany/geany/pull/180

This just fixes quoting the arguments so we can stick with the simple 
and effective system() spawn.

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

Re: [Geany-Devel] Ping on Bug #943 - windows build command

[Nick Treleaven]

On 09/10/2013 01:50, Matthew Brush wrote:

I can simply test FiF with regex = ".", which will generate a lot of
output quite fast. Without the SYNC_SPAWN patches, build.c and search.c
async executions are identical (except that build checks if the
returned pid after successful spawn async is > 0, but still sets the
channels if it's not - I wonder why).



Can you get grep to write a lot of stuff to both stdout and stderr in
the same run though?


Exactly, the problem with g_spawn is not the 4kb problem, that is only 
the custom spawning. The problem is capturing both stdout and stderr.



What about wrapping grep in a shell script that
uses `tee` (or equivalent) to dump the output to both streams?


GTK+ 2.22 is over 3 years old by now, FWIW.


I'm using 2.22 under win~1 too, and don't think it will have any
problems with async exec, but we'll see.



Yeah, just pointing it out because 3 years is a lot of code churn for a
project like GTK+. There's been ~15.5 thousand commits[1] since the
2.22.0 tag :)


g_spawn isn't gtk. gspawn[,-win,-win-helper].c don't seem to have any 
significant fixes. I could be wrong, but it doesn't look hopeful.

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

Re: [Geany-Devel] Ping on Bug #943 - windows build command

[Nick Treleaven]

On 07/10/2013 20:07, Matthew Brush wrote:

On 13-10-07 08:31 AM, Nick Treleaven wrote:

On 05/10/2013 15:40, Matthew Brush wrote:

On 13-10-05 07:06 AM, Nick Treleaven wrote:

It was last year, but I think it wasn't just with dmd, although that
triggered it the most, and it only happened when dmd wrote more than a
certain amount to stderr (cascading errors). It was very suspicious
that
the custom spawn code works until there are too many errors, at least
with dmd.


One person reported it on the devel list. See:
http://lists.geany.org/pipermail/devel/2011-July/004845.html

Unfortunately I missed that mail at the time, but I tried the provided
fix before committing my system() change, and I remember it didn't fix
all the issues with blocking and/or hanging Geany I had.



That was going to be my guess for the deadlock, once the buffers fill up
they have to be drained or else can't keep writing to input. The same
issue should apply to any spawning method we use probably (ie. GSpawn).


Did we get deadlock with g_spawn? I'm only aware of missing output.



It sounded like what was described by Josh in your link:

"The problem seems to be that pipes are only 4kb buffered by default, so
any process needing to write more than this would block while writing to
stdout and Geany would kill it, as it wasn't reading the pipes until
after the process exited."


But that link is talking about the custom spawning, and provides a patch 
to it. You must be confused, g_spawn shouldn't have that issue (only by 
coincidence, and I know of no evidence it has).





So with the pull request adding system() as a fallback/hidden
preference, maybe we could just drop the win32 API code altogether,
switch back to using the same codepath as all platforms (ie. GLib async
spawning) and if people experience issues, we can use as further data
points to troubleshoot GLib async spawning and we can recommend they try
the system() option[1] as a workaround?


system() is *synchronous*, so we couldn't remove the SYNC_SPAWN code and
have it as an option.



I mean to remove the win32_spawn function (as it existed before the
system() hack), the one that was left orphaned in win32.c and renamed it
to broken_win32_spawn() that uses the win32 API rather than GLib
spawning or system().


It actually wasn't orphaned if env was set, but I get you.


IMO, any function in our code base prefixed with _broken, that no one
wants to touch, and looses platform-independence for our code, should
just be deleted[2] :)


I thought you said it was most important to fix the common case, that's
why I made the PR.



I imagine the most common case would be that g_spawn_async_with_pipes()
works. I've used it a number of times on Windows without issues and I've
not found online or encountered any issues with lost output that's being
claimed as the reason for all these work-arounds for it.


Can you please try running a command that outputs *both* stderr and 
stdout? See my reply to the parent message about make object and build.o.



BTW, did you try undefining SYNC_SPAWN lately to see if async spawning
still doesn't work for you now? If so and it doesn't, what Windows
version and GLib versions do you have?


I just tried it. Running build on a C file:

gcc -Wall -c "build.c" (in directory: C:\git\geany\src)
Compilation failed.
gcc: error: "build.c": Invalid argument
gcc: fatal error: no input files
compilation terminated.

No idea why gcc says that, also tried for another file in parent
directory.

Running build on a D file just says 'Compilation failed' without
reporting the line compilation fails on.

Windows Vista. GTK 2.22.0, GLib 2.26.0.



GTK+ 2.22 is over 3 years old by now, FWIW.


OK. Try to reproduce my problem with your newer gtk then.
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] On Deprecation of Platforms

[Nick Treleaven]

On 04/10/2013 04:09, Lex Trotman wrote:

On 4 October 2013 02:35, Nick Treleaven wrote:


On 03/10/2013 15:37, Lex Trotman wrote:


- holding us at an unreasonably old GTK version


Sorry?  I don't think Windows support has anything to do with the GTK
version we support.  If anything, it's rather the contrary, providing a
newer version for Windows installers is far easier than forcing users of
old GNU/Linux distros to build a new version.




Well, as I understand it, moving the windows packages to GTK 2.24 is the
only thing holding us at 2.16.  As there was a deathly hush on the ML
thread when volunteers were requested to try it, I guess nobody is willing
to support it, even just for that.



I'm not sure that was the main reason, I argued that LTS distros was a
reason for keeping older dependencies. I expect there are newer runtimes, I
heard gtk 3 on Windows works reasonably well since last year or so.



IIRC the LTS distros were 2.18 at least. GTK3 Geany for Linux is currently
quite stable, I use it every day.  GTK3 on windows could be ok, but again
we come to the point that nobody is going to do the work of testing it and
then changing the release and nightly builder.

Since the only way Windows is "stopping" any upgrades of the oldest version
is the builders using 2.16, maybe stopping windows support is just no
longer making those packages, leaving the code inside #ifdef OS_WIN32 there
for you to build it with your preferred GTK.


I don't understand sorry, why is 2.16 needed for Windows? I have newer 
than that.



  > >- few of the developers have access to a representative development

setup (no WinXP on a VM is hardly representative)



I indeed don't, but AFAIK Nick and Matthew does




And I should add, its not reasonable if you are the only one either, the
fixes needed to windows will deprive the rest of Geany of any of your
effort.  Its not as if there are no other things to do:)



A slightly broken Windows version is infinitely better than none at all. I
use it and don't experience any significant issues that can't be worked
around.



But thats not a universal experience, and again there is nobody who is
looking at why and how to fix it.  At least the Linux version gets a slow
trickle of changes.


You are exaggerating.




  >Anyway, although I agree the Windows version isn't as good as it should

right now, I don't really see the problem it causes to the rest of
Geany.  And if we indeed clean some things up a little like Matthew
suggests, it could even be just fine (Windows dialogs, come on).





I don't mind if Matt wants to remove the Windows dialogs. Enrico put them
in, I think they're not really necessary.



Again "somebody else do it", Matt having already said he won't.  :)


I must have misread him then.

How about this, I make the Windows dialog pref a various pref and merge 
the file overwrite PR. Various prefs are already warned about.



  Again, the issue is, without anybody to do it, all that happens is that

the
rest of Geany gets less love.

Lots of people over the years have put forward suggestions, but none of
them have even dropped a PR or patch, let alone assisted with maintenance.
   Its not nice to cut off a platform, but if everybody expects others to
do
the work, then we may have no choice or the whole project will collapse.



^^^ *Massive* exaggeration. Most open source projects have unresolved
bugs. Unfunded open source projects work mostly because developers fix
problems that they themselves experience. I don't see any significant
problems with the Windows version that affect me.



And you do work on the problems that affect you, and thank you for that,
but "support" is also answering bug reports and questions on IRC, otherwise
you get the current situation of Matt and I blundering about in the dark
(well Matt might have a small torch, but I'm in the dark).  I'm not
criticising you or suggesting you take over the role again, I'm looking for
people to help you.


We shouldn't deprecate it, that won't help anyone.




  I'm not saying delete anything inside #ifdef OS_WIN32 tomorrow.  But also

in fairness some warning that platform specific code is not being
maintained adequately needs to be given to Windows users, and their help
sought, and this is one way I can think of that makes it clear.  Other
suggestions are welcome:)



You are massively overreacting. If we really cared so much about user
experience we would make more bugfix releases, but we don't have the
resources for that.



Indeed, and that is the problem I'm trying to address.  If we don't make it
clear to people that they need to step up and help, we will get nowhere.


You can call for contributors. Don't annoy Windows users.

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

Re: [Geany-Devel] Ping on Bug #943 - windows build command

[Nick Treleaven]

On 07/10/2013 16:31, Nick Treleaven wrote:

gcc -Wall -c "build.c" (in directory: C:\git\geany\src)
Compilation failed.
gcc: error: "build.c": Invalid argument
gcc: fatal error: no input files
compilation terminated.

No idea why gcc says that, also tried for another file in parent directory.


It was passing the quotes directly to gcc. Removed them, and it appears 
to work, but I think gcc only outputs to stderr.


I tried make build.o - the stdout gets captured but the stderr is lost.
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] Ping on Bug #943 - windows build command

[Nick Treleaven]

On 05/10/2013 15:40, Matthew Brush wrote:

On 13-10-05 07:06 AM, Nick Treleaven wrote:

On 05/10/2013 14:59, Nick Treleaven wrote:

I don't remember seeing any bug reports for this, so it's possible it's
limited to you or the specific application you were using, maybe a bug
in a certain version of DMD? The commit messages doesn't explain what
the actual root of the problem was or why it could not be fixed
properly, or what was tried to fix it before abandoning the existing
code.


It was last year, but I think it wasn't just with dmd, although that
triggered it the most, and it only happened when dmd wrote more than a
certain amount to stderr (cascading errors). It was very suspicious that
the custom spawn code works until there are too many errors, at least
with dmd.


One person reported it on the devel list. See:
http://lists.geany.org/pipermail/devel/2011-July/004845.html

Unfortunately I missed that mail at the time, but I tried the provided
fix before committing my system() change, and I remember it didn't fix
all the issues with blocking and/or hanging Geany I had.



That was going to be my guess for the deadlock, once the buffers fill up
they have to be drained or else can't keep writing to input. The same
issue should apply to any spawning method we use probably (ie. GSpawn).


Did we get deadlock with g_spawn? I'm only aware of missing output.


So with the pull request adding system() as a fallback/hidden
preference, maybe we could just drop the win32 API code altogether,
switch back to using the same codepath as all platforms (ie. GLib async
spawning) and if people experience issues, we can use as further data
points to troubleshoot GLib async spawning and we can recommend they try
the system() option[1] as a workaround?


system() is *synchronous*, so we couldn't remove the SYNC_SPAWN code and 
have it as an option.



IMO, any function in our code base prefixed with _broken, that no one
wants to touch, and looses platform-independence for our code, should
just be deleted[2] :)


I thought you said it was most important to fix the common case, that's 
why I made the PR.



BTW, did you try undefining SYNC_SPAWN lately to see if async spawning
still doesn't work for you now? If so and it doesn't, what Windows
version and GLib versions do you have?


I just tried it. Running build on a C file:

gcc -Wall -c "build.c" (in directory: C:\git\geany\src)
Compilation failed.
gcc: error: "build.c": Invalid argument
gcc: fatal error: no input files
compilation terminated.

No idea why gcc says that, also tried for another file in parent directory.

Running build on a D file just says 'Compilation failed' without 
reporting the line compilation fails on.


Windows Vista. GTK 2.22.0, GLib 2.26.0.

Also if you want to make the argument that it might be fixed in newer 
versions, I would appreciate if you quoted something plausible that got 
fixed upstream in Git or in the release notes. To my knowledge no 
significant work has been done on it in years. See:


https://git.gnome.org/browse/glib/log/glib/gspawn-win32.c
https://git.gnome.org/browse/glib/log/glib/gspawn-win32-helper.c


Cheers,
Matthew Brush

[1]: And maybe fix it so it does cmd.exe quoting properly.


Feel free to look at it.


[2]: Of course it's in Git history so if async spawning ends up not
working for many people we can always put it back later.
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel



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

Re: [Geany-Devel] Ping on Bug #943 - windows build command

[Nick Treleaven]

On 05/10/2013 14:59, Nick Treleaven wrote:

spawn that doesn't block Geany or outright hang. This definitely


It would be nice to figure out *why* it was hanging and fix *that*
problem though, not just drop the existing workaround code and write 3rd
workaround that's arguably worse[1] than the original issue.


I did try.


In fact I wasted about a week trying to fix it, reading windows API 
docs, reading forum threads etc.



happened very frequently when using dmd from dlang.org. See:

https://github.com/geany/geany/commit/a3664fae9ece396952d732cc937e63192d8c6f76





I don't remember seeing any bug reports for this, so it's possible it's
limited to you or the specific application you were using, maybe a bug
in a certain version of DMD? The commit messages doesn't explain what
the actual root of the problem was or why it could not be fixed
properly, or what was tried to fix it before abandoning the existing
code.


It was last year, but I think it wasn't just with dmd, although that
triggered it the most, and it only happened when dmd wrote more than a
certain amount to stderr (cascading errors). It was very suspicious that
the custom spawn code works until there are too many errors, at least
with dmd.


One person reported it on the devel list. See:
http://lists.geany.org/pipermail/devel/2011-July/004845.html

Unfortunately I missed that mail at the time, but I tried the provided 
fix before committing my system() change, and I remember it didn't fix 
all the issues with blocking and/or hanging Geany I had.

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

Re: [Geany-Devel] Ping on Bug #943 - windows build command

[Nick Treleaven]

Now I'll answer the rest of your mail Matt.

On 03/10/2013 15:43, Matthew Brush wrote:

On 13-10-03 05:31 AM, Nick Treleaven wrote:

On 02/10/2013 22:58, Matthew Brush wrote:

On 13-10-02 04:40 AM, Nick Treleaven wrote:

On 01/10/2013 22:28, Matthew Brush wrote:

On 13-10-01 05:34 AM, Nick Treleaven wrote:

Just checked my email, was away last week. I'll have a look at it,
but I
doubt the GLib spawning has been fixed. Either way it should be
definitely be tested before reverting to the broken GLib spawn. I
know
GLib spawn doesn't work with my version of GLib/gtk, which isn't that
old (1yr?).



Locally on my Win7 VM I have reverted the patch and removed all the
existing SYNC_SPAWN-guarded stuff and rid of win32-specific and to
just
use GLib spawning same code on all platforms and it runs easily as
good
as it does before the changes (just did some basic testing though).
It's
still not nice and non-blocking like it is on Linux, but seems to
be no
worse-off after removing like 200 lines of code :)


If you push your branch I'll try it. I'll need to use it for a few
weeks
to be convinced though. I remember the problem only occurred for
certain
things, maybe running make or non-gnu binaries or something.



For testing purposes it should be as simple as disabling the SYNC_SPAWN
workaround[1].


I tried that a while ago, it didn't work. That was when I added the
SYNC_SPAWN macro.



"Didn't work" how? The only time it didn't work for me was with old GTK+
2.16 binaries the gspawn-win32-helper program would crash instantly
causing a Microsoft dialog to come up asking to debug the executable. It
would be interesting to investigate the original original problem and
maybe we can find a solution that gets rid of the other work-arounds all
together.


Didn't capture the output properly - stdout or stderr were missing.


In the meantime, I suggest reverting the "fix" until the actual problem
is identified and a fix is properly implemented. There's only 1
extremely minor conflict when reverting.


IMO changing/breaking path quoting is far less important than having a


Maybe to you, but it's very common on Windows to have spaces in the path
names, it's even the default on Windows XP (Documents and Settings). To
most people (ex. the bug reporters) it seems outright broken now,
whereas before it worked.


See my other mail, I made a pull request. I tend to put my code in 
C:\git, but obviously others use paths with spaces in. I didn't realize 
my system() change was the cause of that breakage.



spawn that doesn't block Geany or outright hang. This definitely


It would be nice to figure out *why* it was hanging and fix *that*
problem though, not just drop the existing workaround code and write 3rd
workaround that's arguably worse[1] than the original issue.


I did try.


happened very frequently when using dmd from dlang.org. See:

https://github.com/geany/geany/commit/a3664fae9ece396952d732cc937e63192d8c6f76




I don't remember seeing any bug reports for this, so it's possible it's
limited to you or the specific application you were using, maybe a bug
in a certain version of DMD? The commit messages doesn't explain what
the actual root of the problem was or why it could not be fixed
properly, or what was tried to fix it before abandoning the existing code.


It was last year, but I think it wasn't just with dmd, although that 
triggered it the most, and it only happened when dmd wrote more than a 
certain amount to stderr (cascading errors). It was very suspicious that 
the custom spawn code works until there are too many errors, at least 
with dmd.



BTW the blocking and hanging was with the custom windows process
spawning code, not with GLib's spawning. GLib IME just doesn't report
the output properly, or at least not both stdout and stderr for all
binaries.


What did you try to fix it before dropping asynchronous spawning? How


I didn't drop it, Enrico/contributor did some years ago.


did it improperly report its output? Did it cause the handlers for the
IO channels not to always fire or something? What programs didn't it
work with? What versions were tested? Can it be reproduced in a clean
sample program outside of Geany?

BTW, do you have a link to the upstream bug report for this issue? I
googled a lot, and besides this old fixed issue[2], I don't seem to find
much besides a few Geany-related things that just say "don't work"
without additional details. Did anyone from Geany report the bug
upstream or make note of which upstream bug is causing the original
original issue?


I don't have any links, but there are many serious sounding bugs in 
Glib's bug tracker for g_spawn on Windows.




Cheers,
Matthew Brush

[1]: Causes a command prompt to popup, doesn't support filenames with
spaces, uses a temp file, uses system(), le

Re: [Geany-Devel] Ping on Bug #943 - windows build command

[Nick Treleaven]

On 03/10/2013 18:00, Nick Treleaven wrote:

In the meantime, there are 3 spawning variants: I'm confident that the
custom process spawning code is definitely seriously buggy. I really do
need the system() code. I tried, but couldn't fix it. I know that last
time I tried it, the g_spawn didn't capture enough output. At least one
user - the one that contributed it - also had problems with g_spawn
capturing, and wrote the custom process spawning.

I suggest picking whichever one you and others think is best as the
default, but have a hidden pref to enable at least the system() version.
If you don't want to do that, I'll try to find some time, but I'm not
sure when yet.


https://github.com/geany/geany/pull/174

Also, sorry I didn't realize the quoting bugs were due to my system() 
change. Thanks Matt for sending me a private mail about it, and 
convincing me it needed resolving.

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

Re: [Geany-Devel] Ping on Bug #943 - windows build command

[Nick Treleaven]

cc'ing the devel list.

Hi Matt,
I'll have to reply to this email properly tomorrow.

In the meantime, there are 3 spawning variants: I'm confident that the 
custom process spawning code is definitely seriously buggy. I really do 
need the system() code. I tried, but couldn't fix it. I know that last 
time I tried it, the g_spawn didn't capture enough output. At least one 
user - the one that contributed it - also had problems with g_spawn 
capturing, and wrote the custom process spawning.


I suggest picking whichever one you and others think is best as the 
default, but have a hidden pref to enable at least the system() version. 
If you don't want to do that, I'll try to find some time, but I'm not 
sure when yet.


On 03/10/2013 15:43, Matthew Brush wrote:

On 13-10-03 05:31 AM, Nick Treleaven wrote:

Moving to devel list.

On 02/10/2013 22:58, Matthew Brush wrote:

On 13-10-02 04:40 AM, Nick Treleaven wrote:

On 01/10/2013 22:28, Matthew Brush wrote:

On 13-10-01 05:34 AM, Nick Treleaven wrote:

Just checked my email, was away last week. I'll have a look at it,
but I
doubt the GLib spawning has been fixed. Either way it should be
definitely be tested before reverting to the broken GLib spawn. I
know
GLib spawn doesn't work with my version of GLib/gtk, which isn't that
old (1yr?).



Locally on my Win7 VM I have reverted the patch and removed all the
existing SYNC_SPAWN-guarded stuff and rid of win32-specific and to
just
use GLib spawning same code on all platforms and it runs easily as
good
as it does before the changes (just did some basic testing though).
It's
still not nice and non-blocking like it is on Linux, but seems to
be no
worse-off after removing like 200 lines of code :)


If you push your branch I'll try it. I'll need to use it for a few
weeks
to be convinced though. I remember the problem only occurred for
certain
things, maybe running make or non-gnu binaries or something.



For testing purposes it should be as simple as disabling the SYNC_SPAWN
workaround[1].


I tried that a while ago, it didn't work. That was when I added the
SYNC_SPAWN macro.



"Didn't work" how? The only time it didn't work for me was with old GTK+
2.16 binaries the gspawn-win32-helper program would crash instantly
causing a Microsoft dialog to come up asking to debug the executable. It
would be interesting to investigate the original original problem and
maybe we can find a solution that gets rid of the other work-arounds all
together.


In the meantime, I suggest reverting the "fix" until the actual problem
is identified and a fix is properly implemented. There's only 1
extremely minor conflict when reverting.


IMO changing/breaking path quoting is far less important than having a


Maybe to you, but it's very common on Windows to have spaces in the path
names, it's even the default on Windows XP (Documents and Settings). To
most people (ex. the bug reporters) it seems outright broken now,
whereas before it worked.


spawn that doesn't block Geany or outright hang. This definitely


It would be nice to figure out *why* it was hanging and fix *that*
problem though, not just drop the existing workaround code and write 3rd
workaround that's arguably worse[1] than the original issue.


happened very frequently when using dmd from dlang.org. See:

https://github.com/geany/geany/commit/a3664fae9ece396952d732cc937e63192d8c6f76




I don't remember seeing any bug reports for this, so it's possible it's
limited to you or the specific application you were using, maybe a bug
in a certain version of DMD? The commit messages doesn't explain what
the actual root of the problem was or why it could not be fixed
properly, or what was tried to fix it before abandoning the existing code.



BTW the blocking and hanging was with the custom windows process
spawning code, not with GLib's spawning. GLib IME just doesn't report
the output properly, or at least not both stdout and stderr for all
binaries.


What did you try to fix it before dropping asynchronous spawning? How
did it improperly report its output? Did it cause the handlers for the
IO channels not to always fire or something? What programs didn't it
work with? What versions were tested? Can it be reproduced in a clean
sample program outside of Geany?

BTW, do you have a link to the upstream bug report for this issue? I
googled a lot, and besides this old fixed issue[2], I don't seem to find
much besides a few Geany-related things that just say "don't work"
without additional details. Did anyone from Geany report the bug
upstream or make note of which upstream bug is causing the original
original issue?

Cheers,
Matthew Brush

[1]: Causes a command prompt to popup, doesn't support filenames with
spaces, uses a temp file, uses system(), leaves a bunch of complicated
dead cod

Re: [Geany-Devel] On Deprecation of Platforms

[Nick Treleaven]

On 03/10/2013 15:37, Lex Trotman wrote:

> >- holding us at an unreasonably old GTK version

>
>Sorry?  I don't think Windows support has anything to do with the GTK
>version we support.  If anything, it's rather the contrary, providing a
>newer version for Windows installers is far easier than forcing users of
>old GNU/Linux distros to build a new version.
>

Well, as I understand it, moving the windows packages to GTK 2.24 is the
only thing holding us at 2.16.  As there was a deathly hush on the ML
thread when volunteers were requested to try it, I guess nobody is willing
to support it, even just for that.


I'm not sure that was the main reason, I argued that LTS distros was a 
reason for keeping older dependencies. I expect there are newer 
runtimes, I heard gtk 3 on Windows works reasonably well since last year 
or so.


In any case, if we want to up the dependencies, don't deliberately drop 
Windows support.



> >- hard to maintain due to being hacks on top of hacks

>
>Again, spawning code (only?)
>

Again 10% of open bugs.


Just because there are unresolved bugs doesn't mean we should drop a 
platform.


User: 'Your software doesn't work right'
Dev: 'Forget it, we're going to stop releases for your platform'


> >- few of the developers have access to a representative development
> >setup (no WinXP on a VM is hardly representative)

>
>I indeed don't, but AFAIK Nick and Matthew does
>

And I should add, its not reasonable if you are the only one either, the
fixes needed to windows will deprive the rest of Geany of any of your
effort.  Its not as if there are no other things to do:)


A slightly broken Windows version is infinitely better than none at all. 
I use it and don't experience any significant issues that can't be 
worked around.



>Anyway, although I agree the Windows version isn't as good as it should
>right now, I don't really see the problem it causes to the rest of
>Geany.  And if we indeed clean some things up a little like Matthew
>suggests, it could even be just fine (Windows dialogs, come on).


I don't mind if Matt wants to remove the Windows dialogs. Enrico put 
them in, I think they're not really necessary.



Again, the issue is, without anybody to do it, all that happens is that the
rest of Geany gets less love.

Lots of people over the years have put forward suggestions, but none of
them have even dropped a PR or patch, let alone assisted with maintenance.
  Its not nice to cut off a platform, but if everybody expects others to do
the work, then we may have no choice or the whole project will collapse.


^^^ *Massive* exaggeration. Most open source projects have unresolved 
bugs. Unfunded open source projects work mostly because developers fix 
problems that they themselves experience. I don't see any significant 
problems with the Windows version that affect me.



I'm not saying delete anything inside #ifdef OS_WIN32 tomorrow.  But also
in fairness some warning that platform specific code is not being
maintained adequately needs to be given to Windows users, and their help
sought, and this is one way I can think of that makes it clear.  Other
suggestions are welcome:)


You are massively overreacting. If we really cared so much about user 
experience we would make more bugfix releases, but we don't have the 
resources for that.

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

Re: [Geany-Devel] RFC: Policy for Glade File Updates

[Nick Treleaven]

On 18/09/2013 21:36, Matthew Brush wrote:

P.S. Are we all still agreed to using old 3.8.1 version of Glade? I
think this idea of using same version sounds good, at least we won't be
causing additional noise in diffs due to different versions writing
stuff out in different ways.


One might hope so, but 3.8.1 causes massive noise, see:
http://lists.geany.org/pipermail/devel/2012-January/006418.html



Yeah, that's why I was saying maybe we should do like we (ideally) do
with the geany.txt file; make the changes and commit the text changes,
and then as a separate commit, generate the HTML and commit the noisy
one. If we did this, at least we could be sure that it won't be the next
person who edits the file's job to figure out if saving the file will
break it (like it will at present if anyone tries to edit it with any
version of Glade).


OK, that'd be a good practice. But that won't help get small diffs ;-) 
Glade 3.8.1 likes to rearrange things randomly IME.

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

Re: [Geany-Devel] RFC: Policy for Glade File Updates

[Nick Treleaven]

On 12/09/2013 01:38, Matthew Brush wrote:

P.S. Are we all still agreed to using old 3.8.1 version of Glade? I
think this idea of using same version sounds good, at least we won't be
causing additional noise in diffs due to different versions writing
stuff out in different ways.


One might hope so, but 3.8.1 causes massive noise, see:
http://lists.geany.org/pipermail/devel/2012-January/006418.html

I've just seen 3.14.2 is available for windows though.
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] RFC: Policy for Glade File Updates

[Nick Treleaven]

On 18/09/2013 17:07, Nick Treleaven wrote:

I've just seen 3.14.2 is available for windows though.


Although that isn't compatible with gtk+ 2.x apps.
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] Let's move to C++98 - Re: Lets move to C99

[Nick Treleaven]

On 05/09/2013 10:48, Matthew Brush wrote:

On 13-09-05 02:26 AM, Nick Treleaven wrote:

On 01/09/2013 02:36, Matthew Brush wrote:

On 13-08-29 05:08 AM, Nick Treleaven wrote:

On 29/08/2013 02:39, Matthew Brush wrote:

[...]



If we were to use C++, I think it'd be pointless to limit it to
CFront/CwithClasses-style 1980's C++. We should use common/standard
stuff like standard library containers, inheritance (maybe not
multipl-inheritance), the class keyword, templates (where it makes
sense), exceptions, etc. The issues/limits being discussed in this
thread are issues long since considered "resolved" or "non-issues"
for a
long time for desktop software (and since a *long* time even before
Geany's first line of code was written :). The style of code I read on
the net and in talks and books and stuff is modern (ie. >= C++98)
style
C++ and I'd expect that's what the bulk of C++-using contributors
would
be used to using.


Idiomatic C++ takes a *lot* of learning and experience to get right for
someone coming from C.



Do you think there's more C-only programmers out there contributing to
desktop application projects than C++ programmers? I honestly don't know
but my instinct says there isn't.


If you mean open source projects, then yes. Somewhat difficult to
measure, but some (possibly flawed) stats:

Here C has at least twice the share of C++:
http://lang-index.sourceforge.net/

In terms of noise on the web, here C also has approaching twice that of
C++:
http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html



It would be better (but even harder to measure) to compare desktop
applications, as I mentioned, like Geany since this is an area where C++
makes a lot of more sense compared to C, and there's a lot of excellent
C++ GUI toolkits like Qt, WxWidgets, FLTK, FOX, GTKmm, WTL, etc.
Compared to C, where GTK+ is about the only actually good toolkit I've
ever come across.


You don't need to be a GUI programmer to make good contributions to Geany.


Also even if there were more C++ programmers, it would still be much
easier for a C++ programmer to write C than vice versa.



Yeah maybe, although if you learned C++ first, using C is fairly foreign
and weird I'm sure. Also all of the other languages that support
modern/more programming paradigms would probably make an easier
transition to C++ than C.


The STL is almost unique. Only D has something similar. Also C++-style 
RAII is not commonly found in popular languages.

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

Re: [Geany-Devel] Let's move to C++98

[Nick Treleaven]

On 05/09/2013 12:26, Lex Trotman wrote:

[...]

Hi Nick,

Still somewhat noisy IMO. How about this, C++98 (I think):


#include 
#define FOREACH BOOST_FOREACH

FOREACH(Document &doc, win.documents())
{
 // do stuff with each document
}



Frankly if you want to limit the parts of standard C++ that are used, the
last thing you want to do is to introduce a whole second language, that of
the Boost library. :)


That macro is very similar to C++11 range for. A whole second language 
it is not.



Also you previously worried about compilation times, well boost is a big
hairball of headers that include each other, efficient for its developers,
but its notorious for slowing compilations to a crawl.


I haven't used it, but it says it's supposed to be modular. It may well 
be possible to use BOOST_FOREACH without adding more than a few headers 
to the project. What don't you like about it? Surely you can see it is 
much cleaner than std::for_each?



I guess I was wrong when I said we disagreed on details, I think after
reviewing the thread, we disagree at a very fundamental level on limiting
parts of the language.

To me limiting language features removes many benefits of the language by
throwing away the standard idioms and solutions that use them.  The design
problems for Geany are not unusual, and there are a set of well known and
documented solutions to many of them.  These solutions are known to work,
and known to work well, and known to be safe, and by removing specific
language features many of these standard solutions become no longer
available.

Using a project specific subset of features is not likely to make it easier
for C programmers to learn and contribute because they can't follow the
standard advice in books and on the web any more.  It also is not likely to


They don't need to learn it. We could even limit RAII to just using the 
string type. Dynamic strings are well understood by programmers, even 
GLib has GString. Strings are fundamental to Geany.


The problem is if we don't agree to just use the most useful C++ 
features, there is no way the project will move to it. C++ is controversial.



attract any existing C++ programmers, they are unlikely to want to discount
their knowledge capital by being limited to a subset of their known
solutions.  Moving away from the documented standard language just adds
more barriers to contribution.

And doing things like writing project specific macros like
"foreach_document" doesn't help, in either C or C++. :)


I'm happy to consider a better solution, Matt's foreach_doc is much 
better, once we move away from C90. If you have a better idea, please 
start a new thread. It must somehow deal with doc->is_valid 
transparently though.


If we could accept BOOST_FOREACH, we could make a documents() function 
that works with it.



This does not mean that there should be a free-for-all on how C++ features
are used.  They should be used where that feature would normally be
expected to be used, rather than a sub-optimal C-like solution, or a
solution that uses features for features sake.  I can only defer to the
expert on the subject
http://www.stroustrup.com/bs_faq2.html#coding-standard and
please note the JSF standards are *not* applicable to Geany.  Geany isn't
an over budget, over schedule, critical real-time, billion dollar weapons
platform :)  The key idea is to have a set of standards appropriate to the
project.

Ignoring style advice, since we have our own, something much more
appropriate is the GCC coding conventions
http://gcc.gnu.org/codingconventions.html.  The C++ section starts:

"C++ is a complex language, and we strive to use it in a manner that is not
surprising. So, the primary rule is to be reasonable. Use a language
feature in known good ways. If you need to use a feature in an unusual way,
or a way that violates the "should" rules below, seek guidance, review and
feedback from the wider community."

This is also a project moving from C to C++ (and as of recently has
achieved the milestone of compiling fully with C++) and the rules
anticipate changes, such as the desire to move to RAII style exception
safety.  This may then permit the use of exceptions.  These changes can
happen progressively throughout the code base, and gcc is a "little" bigger
than Geany :)


We have very few resources (and possibly expertise too) to rewrite the 
Geany API in C++, and it would be a big distraction and likely cause 
many arguments (as it already has).


We could instead decide to be pragmatic instead of idealistic and accept 
that only using the most useful features of C++ that apply for Geany is 
a workable, maintainable, easy to understand solution that is still 
better than just C99.


I won't continue to push for this unless anyone else shares my view. We 
can probably give up on any C++ in Geany's core.


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

Re: [Geany-Devel] Let's move to C++98 - iteration

[Nick Treleaven]

On 01/09/2013 03:53, Matthew Brush wrote:

On 13-08-31 07:42 PM, Lex Trotman wrote:

Just for fun I wrote some theoretical code that could be used in a
program
like Geany to compare styles between various C's and C++'s (note:
none of
it tested).

http://pastebin.geany.org/**gYFMO/ 




As discussed on IRC here's another way of doing the C++98/03, marked with
+es. http://pastebin.geany.org/AzbMV/



Or alternatively in c++11 :)

for_each(begin(App::instance().windows()),
  end(App::instance().windows()),
  [] (Window &win) {
for_each(begin(win.documents()),
 end(win.documents(),
 [] (Document &doc) {
   // do stuff with each document
 }
 );
  }
);


Still somewhat noisy IMO. How about this, C++98 (I think):

#include 
#define FOREACH BOOST_FOREACH

FOREACH(Document &doc, win.documents())
{
// do stuff with each document
}

See:
http://www.boost.org/doc/libs/1_54_0/doc/html/foreach.html

"BOOST_FOREACH is designed for ease-of-use and efficiency. It does no 
dynamic allocations, makes no virtual function calls or calls through 
function pointers, and makes no calls that are not transparent to the 
compiler's optimizer. This results in near-optimal code generation; the 
performance of BOOST_FOREACH is usually within a few percent of the 
equivalent hand-coded loop. And although BOOST_FOREACH is a macro, it is 
a remarkably well-behaved one. It evaluates its arguments exactly once, 
leading to no nasty surprises."

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

Re: [Geany-Devel] Let's move to C++98 - Re: Lets move to C99

[Nick Treleaven]

On 05/09/2013 10:26, Nick Treleaven wrote:

Also even if there were more C++ programmers, it would still be much
easier for a C++ programmer to write C than vice versa.


Here I meant *idiomatic* (STL-heavy) C++. Some features e.g. references 
are well known to programmers of other languages and IMO simple to learn 
and understand. I think using a dynamic string type is also well 
understood by modern programmers. Even if we just used those two things, 
I think it would be worth starting to use some C++.

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

Re: [Geany-Devel] Let's move to C++98 - Re: Lets move to C99

[Nick Treleaven]

On 01/09/2013 02:36, Matthew Brush wrote:

On 13-08-29 05:08 AM, Nick Treleaven wrote:

On 29/08/2013 02:39, Matthew Brush wrote:

[...]



If we were to use C++, I think it'd be pointless to limit it to
CFront/CwithClasses-style 1980's C++. We should use common/standard
stuff like standard library containers, inheritance (maybe not
multipl-inheritance), the class keyword, templates (where it makes
sense), exceptions, etc. The issues/limits being discussed in this
thread are issues long since considered "resolved" or "non-issues" for a
long time for desktop software (and since a *long* time even before
Geany's first line of code was written :). The style of code I read on
the net and in talks and books and stuff is modern (ie. >= C++98) style
C++ and I'd expect that's what the bulk of C++-using contributors would
be used to using.


Idiomatic C++ takes a *lot* of learning and experience to get right for
someone coming from C.



Do you think there's more C-only programmers out there contributing to
desktop application projects than C++ programmers? I honestly don't know
but my instinct says there isn't.


If you mean open source projects, then yes. Somewhat difficult to 
measure, but some (possibly flawed) stats:


Here C has at least twice the share of C++:
http://lang-index.sourceforge.net/

In terms of noise on the web, here C also has approaching twice that of C++:
http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

Also even if there were more C++ programmers, it would still be much 
easier for a C++ programmer to write C than vice versa.


P.S. Sorry for the late replies, also to Lex ;-) Been AFK a lot lately.
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] Let's move to C++98 - Re: Lets move to C99

[Nick Treleaven]

On 05/09/2013 09:41, Matthew Brush wrote:

On 13-09-04 09:20 AM, Nick Treleaven wrote:

My C89 & C++ version:

guint i;
foreach_document(i) {
 GeanyDocument *doc = documents[i];
 // do stuff with every valid doc
}



While this code is short, it's actually sort of nuts too (and also not
very C++-ish).

1. You should include the definition of the custom macro used and the
definitions of the two other non-obvious macros used inside the first
macro for a fair comparison, since none of them are standard or even
well-known like the pasted examples.


Most files already include document.h.


2. The code does not loop over the windows like the pasted code, so
you'd need another outer loop which would likely have a 2nd style of
iteration wrapped around the existing loop.


We don't support accessing multiple windows IIUC.

BTW I was just providing code for that specific case, not necessarily 
for all iteration.



3. It's somewhat unclear what type should be passed in looking at the
macro without the doc comments (I always forget and have to RTFM each
time I see it since we often use gint where we mean guint).

4. The argument is not only assigned to but also evaluated multiple
times (what if you pass `--i` or something weird as argument). I guess
assigning might be good here since the compiler would catch it rather
than flying off the end of the array when it hits `(guint)-1` (UINT_MAX)
on underflow.

5. It's fairly tricky to debug misuses of the macro (better with Clang).

6. The implicit check in the loop (failure first) indexes into a macro
wrapper around a whole other type using a hard cast from the result of
another function-like macro cast thing off in another file, and is
dereferenced without any NULL check (although probably safe in this
case, unless a plugin or something re-assigns the global variable or
redefines any macro aliases of it).

7. It forces you to define an indexing variable outside of the loop into
the wrong scope (C89-style, even if used in > C99 plugin code).

8. Even though slightly dirtier, it would be more useful to iterate over
document pointers than document indexes (what are those? tab pages?
order of opening? arbitrary array indices?), for example (untested, C99
or GNU89 probably):

 #define foreach_doc(doc) \
 for (unsigned z_=0; z_ < documents_array->len; z_++) \
if ( !((doc) = documents_array->pdata[z_]) || \
 !(doc)->is_valid ) { continue; } else
 ...
 GeanyDocument *doc;
 foreach_doc(doc) {
   // every valid doc
 }


Yes, that is much better if we have C99/C++. That also solves most of 
the points above.



9. I personally find it annoying to use API's that have all their own
versions of things that are really common and not that hard anyway; it's
difficult to learn them all, and also all the stuff mentioned above when
they are macros. Consider this slightly longer example that uses no
macro madness and common C looping idiom:

 guint i;
 for (i = 0; i < documents_array->len; i++) {
   GeanyDocument *doc = documents_array->pdata[i];
   // do stuff with every *should be* (but isn't) valid doc
 }

Assuming the API didn't have the weirdness about documents being invalid
but still sticking around for whatever reason, it's the same number of
lines as the macro version and no magic.


Yes. Although sometimes bugs do slip through, even in incrementing for 
loops. Suppose someone used <= instead of <, or forgot to initialize i.



10. The macro should be named `foreach_document_index()`.


OK.


I don't think we should rewrite Geany's API in C++, or maintain a C++
wrapper for the C one, except for any cases which are particularly
bug-prone.



An idiomatic C++ binding would be quite useful for a plugin written in
normal C++. In my current C++ plugin I'm working on, I'm actually
wrapping up a few parts of Geany's API it uses to avoid scattering the
weird C code containing lots of raw pointers, miscellaneous allocators,
different string/collection types, and so on, throughout the normal C++
code.


It would be useful, but also a distraction for the core project.
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] Let's move to C++98 - Re: Lets move to C99

[Nick Treleaven]

On 01/09/2013 01:08, Lex Trotman wrote:

I mean inheritance and virtual functions. I don't think they would pull
>their weight in src, unless we were going to use gtkmm for custom widgets.


Agree I can't immediately think of places where inheritance is likely to be
useful at high level, but thats no reason to ban it.


That's not the reason. The reason is maintainability and ease of 
contribution.

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

Re: [Geany-Devel] Let's move to C++98 - Re: Lets move to C99

[Nick Treleaven]

On 01/09/2013 02:36, Matthew Brush wrote:

I would even go so far as to say it's silly to not use C++11 since it's
[...]




Just for fun I wrote some theoretical code that could be used in a
program like Geany to compare styles between various C's and C++'s
(note: none of it tested).

http://pastebin.geany.org/gYFMO/


My C89 & C++ version:

guint i;
foreach_document(i) {
GeanyDocument *doc = documents[i];
// do stuff with every valid doc
}

I don't think we should rewrite Geany's API in C++, or maintain a C++ 
wrapper for the C one, except for any cases which are particularly 
bug-prone.

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

Re: [Geany-Devel] Let's move to C++98 - Re: Lets move to C99

[Nick Treleaven]

On 29/08/2013 13:52, Lex Trotman wrote:

  I would even go so far as to say it's silly to not use C++11 since it's

such a major improvement over previous C++ versions, in both performance



I'm curious, why does it perform better?



I'm putting words in Matthews mouth here, but things like move semantics
can reduce the need for allocations and copying, but like all such
"performance improvements" it needs to be used a zillion times before it
matters, and well, Geany does few things a zillion times (except inside
Scintilla's rendering code).


OK.


Readability is definitely better in C++11 when avoiding iterators and
using lambdas, but I was kind of hoping we could avoid those ugly cases. I
wasn't thinking of using the STL heavily, just a few containers like
string, and perhaps others for any specialized use cases.



Sadly, containers means iterators, inevitably, and yes C++03 syntax is
ugly, but you get used to it, and just type it automatically. Pity "auto"
and "for( a: container )" is C++11, oh well.


Yes. Unless we use a foreach macro ;-P
I'm not sure iterators are needed often for string though, but it's been 
a while since I looked at code using it.



I proposed banning OOP, operator overloading and exceptions in src to make

it (much?) easier to understand & maintain the code vs idiomatic C++, with
all its unintuitive bug-prone corner cases (which are still in C++11), see
my reply to Lex for more info.



Looking at it again, I'm not sure we mean the same thing by OOP, its a much
abused and overloaded term, could you perhaps explain your meaning?
  Depending on what you mean, banning it is either sensible, or the silliest
idea ever :)


I mean inheritance and virtual functions. I don't think they would pull 
their weight in src, unless we were going to use gtkmm for custom widgets.



Yes, or maybe convert a core plugin that uses strings a lot, so we get the
benefit of RAII. I might look into it unless Colomban is against that (even
for a core plugin).



Good idea, plugins can be written in C++ now, without any changes to Geany
being needed.  Just make sure you don't leak exceptions (unless you mean
to) since they currently mean terminate().


OK.

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

Re: [Geany-Devel] Let's move to C++98 - Re: Lets move to C99

[Nick Treleaven]

On 29/08/2013 06:47, Lex Trotman wrote:

On the topic of exceptions, remember many STL operations and "new" can
throw.  Of course only throwing on uncorrectable errors like out of memory
is fine, it just exits the application.  Thats what will happen to a throw
from Scintilla in current Geany, its not something that will be introduced.
  But as resource management moves to RAII, exceptions can be caught and
produce a more user friendly exit such as dumping buffers first.


OK. We might not want to use -fno-exceptions then, but maybe still avoid 
throwing ourselves.



On using gtkmm, personally I think it is *way* better than the C interface
to GTK, but I don't know if it can be mixed with C GTK easily, and changing
*everything at once* would be a big job.


I don't know either, but gtkmm is much better than GObject boilerplate. 
Although I don't think we need custom objects that often.



Not sure why the RTTI affects the ABI, things visible in the ABI must be
POD to maintain C compatibility, there are much stricter limitations to
maintaining POD, like no non-trivial constructors etc.


OK, so a struct declaration in extern C would be compatible with the C ABI.


We need to organise the resources first, doing things "to attract more
contributors" have so far failed, I wouldn't bet a change like this on
attracting more support (at least in the time the change is happening).


I think moving to C99 may at least avoid /deterring/ further 
contributions because of minor issues like C++-style comments and 
variable declaration after code (or at least in a for statement). I 
don't know if it makes a big difference, but the fewer unnecessary 
hurdles we make them jump through the better.



Nick has offered that C++ "might" attract him to contribute more, I "might"
have time at the end of my current contract, unless I get another quickly,
I guess Colomban is out, Matthew? anybody else?


I'm happy to manage/co-ordinate the transition to C++ (at a slowish 
pace), should we decide we want that.

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

Re: [Geany-Devel] Let's move to C++98 - Re: Lets move to C99

[Nick Treleaven]

On 29/08/2013 02:39, Matthew Brush wrote:

Personally, I think it'd be great to use C++ in Geany, and it would more
than likely actually make it *easier* for people to contribute since
outside of a sampling of GTK+-using desktop/GUI software (and obviously
embedded, kernel, drivers, and similar), C is considered "dead" and the
majority uses >= C++ (more likely Java, C#, Python ... many people also
consider C++ outdated and dead for desktop GUI apps - not me BTW :). C++
allows modern programming techniques but still retains much (or more) of
the performance and "light-weightedness" that Geany strives for.


Yeah, templates make it much easier for libraries to have extra 
flexibility in performance.



If we were to use C++, I think it'd be pointless to limit it to
CFront/CwithClasses-style 1980's C++. We should use common/standard
stuff like standard library containers, inheritance (maybe not
multipl-inheritance), the class keyword, templates (where it makes
sense), exceptions, etc. The issues/limits being discussed in this
thread are issues long since considered "resolved" or "non-issues" for a
long time for desktop software (and since a *long* time even before
Geany's first line of code was written :). The style of code I read on
the net and in talks and books and stuff is modern (ie. >= C++98) style
C++ and I'd expect that's what the bulk of C++-using contributors would
be used to using.


Idiomatic C++ takes a *lot* of learning and experience to get right for 
someone coming from C.



I would even go so far as to say it's silly to not use C++11 since it's
such a major improvement over previous C++ versions, in both performance


I'm curious, why does it perform better?


and readability/coder-friendliness and it's well supported on current
compilers and platforms.


Is it? I hadn't heard that, maybe. But I bet it will cause problems for 
some distro maintainers/builders on LTS distros.


Readability is definitely better in C++11 when avoiding iterators and 
using lambdas, but I was kind of hoping we could avoid those ugly cases. 
I wasn't thinking of using the STL heavily, just a few containers like 
string, and perhaps others for any specialized use cases.


Variadic templates are very cool also. (Die, stream << operators!)


Since we're talking about better languages, there's also Vala which has
most of the benefits discussed here about C++, already uses the same
libraries and type-system as our existing G* code, is API compatible
with C (in the sense that it generates idiomatic G*-style C code,
mostly) and would be an easier transition for the vast quantity of C#
programmers out there who might want to contribute, since the languages
are so similar. Not sure it's a point since most of them use Mono and
C#-strong IDEs, but still, in general there's probably substantially
more developers out there who know C# better than C or C++.


I'm happy to consider using Vala, but I think it would probably be a lot 
less work to use C++ if we want to convert existing code.



While it's a community project, and in general I think the popular
opinion should ultimately prevail or at least that not one person
(barring maybe a BDL) solely controls the direction of the project's
momentum, it's somewhat harsh to make the current maintainer who does an
excellent job and devotes a lot of time already to working on Geany
stuff, to learn a whole different, non-trivial language, one he
dislikes, and to become "more proficient than average" in order to be
able to continue doing code reviews, merging PRs and stuff.


+1. Although I would definitely be keener to contribute using restricted 
C++, I don't want to be maintainer again. Thanks for all the great work 
Colomban (and others) ;-)



I'm all for using modern C++ in strategic (or new) places and I'm
totally against using ancient 1980/90's CFront-style C++ or that which
is restricted so much that it's basically C.


totally against :-O

RAII is a powerful feature that standard C has no hope of competing 
with. It basically allows a string type with automatic memory 
management. Ditto for templates, but I can live without defining our own 
templates if that helps contributor understanding & maintainability.


I proposed banning OOP, operator overloading and exceptions in src to 
make it (much?) easier to understand & maintain the code vs idiomatic 
C++, with all its unintuitive bug-prone corner cases (which are still in 
C++11), see my reply to Lex for more info.



Maybe rather than bikeshed about it too much, we can wait until someone
wants to add a new module, or replace an existing module (I'm looking at
you TM!), or some actual use case, at which point we could discuss
whether it makes sense to use C++ for it, and since we already use C++
for Scintilla, it's not a huge change to use it in another new C++
module with respect to the build systems and stuff.


Yes, or maybe convert a core plugin that uses strings a lot, so we get 
the benefit of RAII. I might look into

Re: [Geany-Devel] Let's move to C++98 - Re: Lets move to C99

[Nick Treleaven]

On 27/08/2013 02:48, Lex Trotman wrote:

Hi Nick,

Thanks for the well thought out sensible proposal.  In general I agree with
the idea of progressively moving appropriate parts of the code to using
appropriate C++ features.  Of course, as usual, I disagree on some of the
details and I'm sure we would disagree on some of the selections of files,
but thats healthy.


Thanks for considering it ;-)


I now think gradually using a (quite heavily restricted) subset of C++98
for *some* source files might be better than moving to C99 (more on that
below). I still support C99 over just C90 though. (I don't do a lot of
Geany coding now, but I plan to do some from time to time, so obviously
this is just my opinion and less important than more active devs).



I'll address the "restricted subset" idea here and refer back from relevant
places below.  My experience of a couple of projects migrating to C++ is
that applying strict "limits" on the C++ features just leads to
implementing those features poorly in the code itself.  One common one is
to not allow virtual functions, but in my experience that just leads to the
use of function pointers and the associated ugly syntax and increase in
errors.


If we want to write OOP code, allow "virtual" and "class". Personally I 
tend to think for Geany OOP is mostly useful for GTK. If we want that, 
we would need gtkmm bindings.


Another reason why I suggest we don't use OOP is that getting 
overloading right with inheritance is difficult for C++ beginners, and 
can cause bugs with experienced devs. Avoiding OOP simplifies the 
unintuitive corner cases of C++, and is easier for C programmers.



The approach that seems to have worked better is the same as that required
for C++ in general, *appropriate* use of features.  Whilst that is easier
to control in a corporate situation where programmers can be trained
properly, review by senior devs should catch the more egregious misuses
within Geany, its not like we have a huge developer base to train anyway :).


We have a fairly large potential contributor base.


Reasons:

* No build problems for Long Term Support distros that don't support C99
(but clearly do compile scintilla's C++98).



Neil is attempting to move Scintilla forward, it might soon be using C++03.5


Another project was against Neil moving to C++11, not just us. Nice 
though C++11 is. As things stand though, we know using more C++98 won't 
cause problems for users. C99 possibly might. C++11 may do.



* RAII - this is a pretty essential feature for safe resource management.
It's a stupid acronym though, it's basically automatic scoped destruction:

http://en.wikipedia.org/wiki/**Resource_Acquisition_is_**Initialization



Agree on both the usefulness and the silly name :)


:)


* References can be useful in making code more readable vs pointers.



Unfortunately, since references are immutable, you can never get rid of
pointers in imperative style programs, that leads to code with a mix,
luckily getting it wrong (using . not ->) will be picked up by the compiler.


I don't want to use references instead of pointers, only where 
references make the code easier to maintain. E.g. 'Output' arguments and 
sometimes in local scope to simplify repeated expressions.



* Developer enjoyment, productivity & gaining more experience with C++.
(This might be an incentive for e.g. me to spend more time working on
Geany). This has to be offset against those that might need to learn e.g.
RAII.



Indeed there is a learning curve, but hopefully many will find that useful
and attractive.


+1


* Possibly we could use a GObject wrapper for safe reference counting. I
don't want to add any dependencies on C++ libraries though.



Or what almost all my C++03 programs have, a template headed:  /* The
ubiquitous intrusive reference counted smart pointer */ :)

Of course use gobject, for things that are gobjects, but don't bring it
into things that are not, the idea is to move to C++, not to tie more
closely to a C library.


I don't know how well it would work in practice. But it might be better 
to stick to one type for reference counting than two.



* Possibly we could have some template function utilities instead of
unsafe macros. Although I think most header files should be kept C90
compatible.



Yes existing headers that are used by the remaining C code will have to
remain C compatible, and will probably need:

#ifdef __cplusplus
extern "C" {
#endif

around them.


There's a GLib macro for that.


But (for C++ files) that doesn't prevent having extra headers with
templates in them.


Yes.


matt:

+1. While I'm also not sure it's a good idea in Geany and certainly
won't be pressing for it anytime soon, 90% of C++'s crumminess is due to
backwards compatibility with C, so I think it should be (theoretically,
not socially) possible to gradually transition from one to the other in
a project like Geany without to

Re: [Geany-Devel] Let's move to C++98 - Re: Lets move to C99

[Nick Treleaven]

On 26/08/2013 19:54, Dimitar Zhekov wrote:

On Mon, 26 Aug 2013 16:07:13 +0100
Nick Treleaven  wrote:

* RAII - this is a pretty essential feature for safe resource
>management.

This works for global/static and auto classes. We can wrap a gchar *s
= g_strdup_printf() in a class, but I'd rather not...


We don't always need a gchar*. For string processing we could use the 
STL basic_string (or Scintilla SString).



* References can be useful in making code more readable vs pointers.


But using both heavily (as GLib/GTK+ required pointers) will make it
harder to read.


Just use them where they help ;-)


* Developer enjoyment, productivity & gaining more experience with C++.
(This might be an incentive for e.g. me to spend more time working on
Geany). This has to be offset against those that might need to learn
e.g. RAII.


Hmmm?..


Time spent for contributors who don't know C++ to learn the parts we 
use. What's the question?



* Possibly we might use some STL containers internally.


There things are heavily templated. They generate more code,
compilation is slower, and (unless improved significantly from the last
time I tried them) the code is overall slower than using GArray/GList.


Slower compilation may be an issue. The minor performance/bloat 
differences you mention would not be a problem for Geany IMO.


Assuming we're comparing the same design in C vs templated C++ code, the 
C++ code would normally have an advantage because more code can be 
inlined. It might be at a disadvantage because of code bloat though, but 
the inlining may outweigh that. Are you sure you tested the C++ code 
with full compiler optimization?



Moreover, you propose to ban "class".


struct = class but with public member visibility by default.


* Possibly we could use a GObject wrapper for safe reference counting.


Why? Where? How to do that without classes and destructors?


Obviously you need destructors for RAII. I meant ban the keyword 'class' 
in Geany code, not in STL code.



Note that gcc has a non-standard extension for RAII, which works with
the base C types. And Geany compiles with gcc only.


Really? Have you read HACKING?


* Possibly we could have some template function utilities instead of
unsafe macros.


Do we need these macros to work with different types? If not, "inline
is already declared in a portable manner in the GLib headers and can be
used normally."


See FALLBACK in tagmanager. Matt doesn't like it though. I don't expect 
we need to replace many macros, more that some template utility 
functions will be useful in C++ code. I can give an example if you like.



I don't know if this can be enforced by g++, but I suggest we disallow
these keywords:

class


There isn't, that's THE most basic feature of C++.
And you can write classes with struct and union.


exactly.


dynamic_cast


-fno-rtti


ok.


friend


No classes -> no usage for friends.

...
>> virtual
>
> No classes -> no virtual methods.

*cough* structs *cough*


throw


-fno-exceptions


nice


Thoughts?


Sorry, but IMHO, that seems even more pointless than using C99.


RAII != pointless

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

[Geany-Devel] Let's move to C++98 - Re: Lets move to C99

[Nick Treleaven]

From the C99 discussion:

lex:
>>> Unless we follow the example of gcc itself and upgrade to C++ :)

me:
>> Not sure that's a good idea for Geany now, although I'm glad that gcc
>> did it. They use a restricted subset IIRC. I miss templates and RAII in
>> C though.

I now think gradually using a (quite heavily restricted) subset of C++98 
for *some* source files might be better than moving to C99 (more on that 
below). I still support C99 over just C90 though. (I don't do a lot of 
Geany coding now, but I plan to do some from time to time, so obviously 
this is just my opinion and less important than more active devs).


Reasons:

* No build problems for Long Term Support distros that don't support C99 
(but clearly do compile scintilla's C++98).


* RAII - this is a pretty essential feature for safe resource 
management. It's a stupid acronym though, it's basically automatic 
scoped destruction:


http://en.wikipedia.org/wiki/Resource_Acquisition_is_Initialization

* References can be useful in making code more readable vs pointers.

* Developer enjoyment, productivity & gaining more experience with C++. 
(This might be an incentive for e.g. me to spend more time working on 
Geany). This has to be offset against those that might need to learn 
e.g. RAII.


* Possibly we might use some STL containers internally.

* Possibly we could use a GObject wrapper for safe reference counting. I 
don't want to add any dependencies on C++ libraries though.


* Possibly we could have some template function utilities instead of 
unsafe macros. Although I think most header files should be kept C90 
compatible.


matt:
> +1. While I'm also not sure it's a good idea in Geany and certainly
> won't be pressing for it anytime soon, 90% of C++'s crumminess is due to
> backwards compatibility with C, so I think it should be (theoretically,
> not socially) possible to gradually transition from one to the other in
> a project like Geany without too much pain.

colomban:
> I doubt it, C++ is sufficiently different from a C program not to be
> compilable by a C++ compiler in many cases -- even if it is just for
> some implicit casts C++ requires to be explicit (IIRC), and there are
> plenty.  Or maybe it depends what "too much pain" means:)
>
> Also, I doubt it's any kind of sensible either, because good C++ use is
> sufficiently different from C to require large rewrite.  In this case,
> better rewrite everything and don't keep the clumsy code

I disagree it *requires* a large rewrite. You can make *good* use of 
some C++ features without having *idiomatic* use of C++. (E.g. dmd, the 
reference D compiler is not written in idiomatic C++ - it doesn't use 
the STL really, but it's still good code).


I think it would be quite manageable. If we did this, I suggest just 
converting one source file at a time, and only files that can benefit 
from RAII and/or the more powerful type system.


We would also need to disable some C++ features. I hoped we could do 
that with g++ flags, but I've only found this so far:


-fno-rtti (disable runtime info for object inheritance)

There ought to be a way to disable mixed code and declarations, but 
maybe not.


I don't know if this can be enforced by g++, but I suggest we disallow 
these keywords:


class
dynamic_cast
friend
mutable
operator
throw
virtual

That could be enforced with a 'make check' build target.

Thoughts?

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

Re: [Geany-Devel] Don't pop-up messages/steal focus when in terminal

[Nick Treleaven]

On 20/04/2013 16:06, Matthew Brush wrote:

On 13-04-20 05:59 AM, Harold Aling wrote:

On Sat, Apr 20, 2013 at 1:40 AM, Lex Trotman  wrote:

Agree with Thomas, we should go to 2.24 for windows since we supply the
bundle, Linux doesn't need to go so far, for eg what GTK did the
current red
hat and suse enterprise versions release with, expect 2.18 or 2.20.


I might be stepping completely out of line with this remark: Do people
with dusty old GTK's use bleeding edge Geany?


It is rumored that some percentage (remember 0 is a percent :) of users
are apparently stuck on ancient enterprise distros at work, need to use
the latest bleeding edge Geany at all times, and are able install it but
not GTK+ from source into $HOME. Or so the story goes :)


I imagine building newer GTK/GLib from source with only old dependencies 
would be a pain in the arse, having to grab and build all the newer 
dependencies too. It's also a pain for most users to install and manage 
multiple versions of libraries. Geany is actually very easy to build as 
it only requires Gtk/GLib.


Note: I have never built GTK/GLib from source.

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

Re: [Geany-Devel] Problem with a plugin I'm working on

[Nick Treleaven]

On 02/04/2013 22:53, Steven Blatnick wrote:

I've started writing some plugins for geany on github, but I'm running
into a problem.  C is not my language of expertise, so I thought I would
see if I'm just doing something stupid.

*The Problem:*

The basic problem is that I have a struct I'm using to pass information
around like an object, but the information isn't staying with the struct
when retrieving it from a TreeView.


I think the problem is this line:
list = gtk_tree_store_new(1, G_TYPE_STRING);

later:

Tool *tool
...
gtk_tree_store_set(list, &row, 0, tool, -1);

You should probably be using G_TYPE_POINTER instead of G_TYPE_STRING.

See:
http://en.wikibooks.org/wiki/GTK%2B_By_Example/Tree_View/Tree_Models

"G_TYPE_STRING - stores a string in the store (makes a copy of the 
original string)
G_TYPE_POINTER - stores a pointer value (does not copy any data into the 
store, just stores the pointer value!)"



Also, one of the things I love about Geany is how little memory it uses,
so feel free to give me pointers on when I need to free up memory,
because I don't want my code to leak.


Well, I didn't study your code for long, but:
Tool *tool = g_slice_new(Tool);

Somehow you need to g_slice_free(Tool, tool) for each call to 
g_slice_new. Maybe by iterating the tree store when you've finished 
using it.

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

Re: [Geany-Devel] [geany/geany] 7150c6: Add Find Usage popup menu items for symbol list tags (#3608278)

[Nick Treleaven]

On 17/03/2013 16:45, Colomban Wendling wrote:

+   gtk_tree_model_get(model, &iter, SYMBOLS_COLUMN_TAG, &tag, -1);

When retrieving the TMTag from the tree model, it gets a reference
(since it's inserted as a GBoxed type with ref/unref as copy/free
funcs), so you need to unref it.

I fixed this with a few other reffing issues.


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

Re: [Geany-Devel] Setting Windows working directory

[Nick Treleaven]

On 13/03/2013 06:19, Lex Trotman wrote:

Shouldn't plugins use geany->app->configdir as the base directory as
perhttp://www.geany.org/manual/reference/structGeanyApp.html

and if its Geany it can use GeanyApp.datadir as the system data directory.


  For this to work, the working

>directory must be set correctly. The reason for the mentioned change was
>this in some plugin, so I've moved the code to change the working
>directory to perform it earlier in the init process, before loading plugins.
>For a quick'n'dirty fix we could either move the working directory
>change code move after command line parsing code but before plugin
>loading or we remember the working directory at early stage to use this
>when llater handling command line arguments.
>Both are not nice and the real solution is to get rid of relative paths
>for resources in the installation directory.
>I'm going to work on this.

Yes it would be better to keep the working dir, ... well ... the working dir:)


+1, it's best for plugins to use fixed paths and avoid temporarily 
changing the working dir.


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

Re: [Geany-Devel] Link to ChangeLog on website still pointing to 1.22.0

[Nick Treleaven]

On 12/03/2013 09:18, Dominic Hopf wrote:

Good morning guys!

Maybe someone is able to update the link here:

 http://www.geany.org/Documentation/ChangeLog


I'm at work and don't have my password here for the login to the admin
interface. ;)


Done ;-)

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

Re: [Geany-Devel] [Geany-devel] Remove MSYS dependency of Geany on Win~1 - VirtualStore data files

[Nick Treleaven]

On 12/12/2012 15:24, Matthew Brush wrote:

altogether. I think this requires a 'manifest' XML file, referenced in
the .rc file:

http://msdn.microsoft.com/en-us/library/bb756929.aspx

Yet another Windows build file with a version and metadata to update on
release :-/


I actually have a patch sitting on my Win7 laptop that adds an XML
manifest file to the resource. I made it because it allows the native
dialogs to look more "native" and less win95-ish by using the current
Windows theme. If you want I can dig up that patch and commit it and
then we can just add whatever else to it.


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

Re: [Geany-Devel] [Geany-devel] Remove MSYS dependency of Geany on Win~1 - VirtualStore data files

[Nick Treleaven]

On 11/12/2012 23:13, Matthew Brush wrote:

So, I did a search for geany.glade and discovered it in:
c:\Users\Nick\AppData\Local\VirtualStore\Program Files\Geany\data

reading up on the VirtualStore path, I found it gets created when an
application tries to write to a system path like Program Files, without
the correct privileges. The application then silently receives the
VirtualStore versions of files instead. I must have once tried to
install geany without admin privileges, or manually copy over the data
dir or something like that.

This behaviour is really confusing if you're not aware of it. I think
there is a way to tell Windows not to use VirtualStore for an specific
application though, I'll have to look into it. In the meantime I just
deleted the Geany dir under VirtualStore, all is now working correctly.


FYI, there was a related bug a while back about this:
https://sourceforge.net/tracker/index.php?func=detail&aid=3566329&group_id=153444&atid=787791


OK, thanks for the info. Hopefully we can disable VirtualStore for Geany 
executables sometime.


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

Re: [Geany-Devel] [Geany-devel] Remove MSYS dependency of Geany on Win~1 - VirtualStore data files

[Nick Treleaven]

On 11/12/2012 19:20, Dimitar Zhekov wrote:

On Tue, 11 Dec 2012 17:44:20 +
Nick Treleaven  wrote:


On 10/07/2012 12:55, Nick Treleaven wrote:

2. A weird problem. Installing from cmd.exe doesn't overwrite
geany.glade (and maybe some other files) even though it appears to
succeed. [...]


So, I did a search for geany.glade and discovered it in:
c:\Users\Nick\AppData\Local\VirtualStore\Program Files\Geany\data

reading up on the VirtualStore path, I found it gets created when an
application tries to write to a system path like Program Files, without
the correct privileges. The application then silently receives the
VirtualStore versions of files instead. [...]


Now that's a... a system designed without security, attempting to
provide "compatibility" with weird tricks.

What's the situation with geany.exe in this case - doesn't it create
even more problems? The newest win~1 versions are very sinsitive about
replacing executables.


To be honest I don't understand exactly when the VirtualStore path gets 
written to, but for Geany I think we probably want to just disable it 
altogether. I think this requires a 'manifest' XML file, referenced in 
the .rc file:


http://msdn.microsoft.com/en-us/library/bb756929.aspx

Yet another Windows build file with a version and metadata to update on 
release :-/

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

Re: [Geany-Devel] [Geany-devel] Remove MSYS dependency of Geany on Win~1 - VirtualStore data files

[Nick Treleaven]

On 10/07/2012 12:55, Nick Treleaven wrote:

2. A weird problem. Installing from cmd.exe doesn't overwrite
geany.glade (and maybe some other files) even though it appears to
succeed. I only noticed this because I'm missing the View->Editor->Color
Schemes menu which was added about a month ago (I tend to test in place
rather than install each time).


OMG... Then we must choose between copy and xcopy depending on which one
works. Or we can define:


Neither one works here ;-) But maybe it's something weird about my
system or because I previously installed using MSYS cp.


OK, I think I finally found out whats happening here (or at least a 
related problem). Perhaps it will help someone else with the same problem.


I was reluctant to delete the installed data files in case the problem 
was specific to them, but today I did, then reinstalled. The installed 
files all got the latest versions, but when I ran Geany the old data 
files were still being loaded (glade symbol errors, filetypes.common 
debug error message).


So, I did a search for geany.glade and discovered it in:
c:\Users\Nick\AppData\Local\VirtualStore\Program Files\Geany\data

reading up on the VirtualStore path, I found it gets created when an 
application tries to write to a system path like Program Files, without 
the correct privileges. The application then silently receives the 
VirtualStore versions of files instead. I must have once tried to 
install geany without admin privileges, or manually copy over the data 
dir or something like that.


This behaviour is really confusing if you're not aware of it. I think 
there is a way to tell Windows not to use VirtualStore for an specific 
application though, I'll have to look into it. In the meantime I just 
deleted the Geany dir under VirtualStore, all is now working correctly.

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

Re: [Geany-Devel] VTE resetting and handling of ^C and ^D

[Nick Treleaven]

On 05/12/2012 14:36, Colomban Wendling wrote:

We already have an "Override Geany keybindings" in the terminal prefs,
that actually overrides everything but focus keybindings.  But for some
reason, this is a setting and it is not enabled by default.  And if it
remains a setting, we somewhat*have to*  let required stuff like ^C go
through in any cases.


Probably we should change it to be on by default.

Letting Ctrl-C/D through when the setting is not enabled is OK, but I 
would stop there and recommend using the setting for anything else.

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

Re: [Geany-Devel] [RFC] Document Messages and File Notification Behaviour (was: buried down deep somewhere)

[Nick Treleaven]

On 06/12/2012 09:08, Lex Trotman wrote:

[...]


Agree that this is a PITA.  Since there is a solution available, why
not improve the user experience?



I agree, the modal dialog is horrible, especially when you get them multiple
times in a row (since it pops up for each changed document) which is not
uncommon after switching branches/tags in a VCS.


or when looking at generated files whilst debugging the program that
generates them.


Just to explain my workflow a little: I don't switch 'through' tabs to 
get to the one I want, I choose the one I want directly or by Ctrl-tab. 
So I do get hit by unwanted reload decisions, but only when closing 
documents.


For my workflow, it is never multiple times in a row, unless I choose 
not to reload a file and close it instead. I can avoid the multiple 
prompts when I want to just by choosing reload once. I think this is a 
significant point, but I accept that people that page through their 
documents would suffer the multiple reload prompt scenario, and that 
that is annoying.



Thomas also mentioned on IRC that Gedit makes a document "read-only"
when it detects disk-changes, which seems like a completely sane and
safe thing to do, although potentially also annoying. Do we want to do
this as well, in addition to the stuff being discussed above?



Might be good, except when the document has modifications already.


And it also forces the user to respond immediately, whichis what we
want to avoid.


Wrong. You can still give no immediately response, e.g. by changing to
another document or just viewing the document. Requiring an action if you
are actually going to deal with the document in question is OK for me.


Well, I don't really agree with being forced to do something to
continue use of a file, *I'M* in charge of this program, not the other
way around  but its not that big a point.


It comes down to whether the user would want the editor to protect them 
from editing a document that they actually want to reload first. Note 
that in this scenario edits can happen from 'Replace All in Session', 
i.e. without even switching to the document that is changed on disk.



FWIW, aligning with Gedit might be more convinient for newcomers that come
from gedit. This doesn't have to be a reason for us to do anything, but
might become an interesting point if Mint really replaces Gedit with Geany.



But this is a big point, as a matter of principle, Geany should not
compromise being the best (lightweight) IDE it can be just to be
similar to some dumbed down version.


Agree, we should optimize for programmers.
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] [RFC] Document Messages and File Notification Behaviour (was: buried down deep somewhere)

[Nick Treleaven]

On 03/12/2012 21:48, Matthew Brush wrote:

On 12-12-03 09:05 AM, Nick Treleaven wrote:
On 03/12/2012 14:18,
Colomban Wendling wrote:
 >> Le 03/12/2012 14:35, Nick Treleaven a écrit :
 >>> I don't think we need a Close button. Closing the document can be done
 >>> in the normal way. Or were you planning on disabling normal closing?
 >>> That would complicate the UI code.
 >>
 >> IIUC, the idea was that closing the document "the normal way" would ask
 >> again if the user didn't make a choice yet.  And although it might
 >> indeed look duplicate, I think it's important to make it a clearly
 >> visible option as an answer to the question.  It being a button or
 >> something else I don't have an opinion yet.
 >
 > OK. Presumably 'normal' save or reload would also ask the user for
 > confirmation. Are there any other use cases like these, maybe from
plugins?
 >

I've done some experimenting on ways to do this. I propose documents get
a new "flag" called "doc->priv->notifications_pending" (or whatever).
When a document message is posted, the flag is set to TRUE, the infobar
is shown within the tab page and tab's close icon changes to the
stock-id of the last (or most "important", see below) message. While the
tab's icon is not close (when notifications are pending) and the button
is clicked, it simply focuses the document (document_show_tab() or
whatever), or puts up a modal dialog saying "The tab you are closing has
notifications pending, are you sure you want to close it without
reviewing them?" before it lets you close it (also for save/save all?).
One question is what should clear the "notifications_pending" flag, be
it simply having shown the user the tab, confirming a modal dialog, or
using the equivalent of a "Dismiss" button in the info bar. For easier
inline discussion, I'll itemize the concepts I just discussed:

* Notion that documents have "notifications" and they can be "pending"
(not yet seen/acknowledged)

* Whether we want to use the tab "close" button icon to indicate the
type of the last notification that is pending. Alternatives are
(existing orange) different color tab label or an additional icon in the
tab to the left of the label.

* What happens when you click the "close" button in the tab (or file
menu, etc), and there are notifications pending? Does it just focus the
document/tab or show a special modal warning dialog or something else?

* What clears the "notifications pending" status of a document? Should
it be the modal dialog from last item, or a "Dismiss" (name TBD) button
in the infobar itself or something else?

* What actions are "dangerous" to perform while notifications are
pending? It seems like these might only be ones that don't work on the
"current document" since it's visible and the user will be looking at
the notification at the time of the action.

   - File Menu and Toolbar:
 - Close All
 - Save All
   - Tab Context/RightClick Menu
 - Close/Close All
 - Tab "Close" button

One problem I noticed with my document-messages branch is that it treats
all notifications the same, be it important disk-change events or from
other parts of the code (or eventually plugins maybe). From trial and
error, I believe the best approach for this is to have a special
top-most notification place where important messages can go, and when
one of those is posted, it's stock-id overrides any of the normal
notification's stock-id in the tab "close" button. Here's an ASCII
digram of the widget layout inside the notebook page:


I'm now having serious doubts about whether this complexity is worth it. 
I really have no issues personally with the current modal dialogs. Modal 
dialogs are a good fit for important information that needs immediate 
consideration, like potential data loss.


This extra complexity doesn't seem to provide much benefit over the 
status quo IMO.



 >> Also, as I discussed a bit on IRC (without much success though :D), I'm
 >> not completely sure if the "dismiss" button (we agreed this probably
 >> wasn't the best name for it BTW) is useful: I personally don't really
 >> see why somebody would like to hide the warning while not making a
 >> decision on what to do with the file.
 >> Though, that's no big deal.
 >
 > Agree, we probably shouldn't allow 'Dismiss'.


BTW what I meant here was not allowing removal of the message, whatever 
it's called, so forcing a response.



Thomas also mentioned on IRC that Gedit makes a document "read-only"
when it detects disk-changes, which seems like a completely sane and
safe thing to do, although potentially also annoying. Do we want to do
this as well, in addition to the stuff being discussed above?


Might be good, except when the document has modifications already.
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] Document Message/File Monitoring Behaviour (was Re: Bug: Conflicting Keyboard shortcut in "reload file" dialog - ID: 3587465)

[Nick Treleaven]

On 03/12/2012 14:18, Colomban Wendling wrote:

Le 03/12/2012 14:35, Nick Treleaven a écrit :

On 01/12/2012 06:16, Matthew Brush wrote:

I also made a mockup for "deleted/moved on disk" infobar. I'll put a
link to avoid spamming the list:


Thanks for doing the mockups. Infobars probably would be better than the
status quo, but I think both of the mockups are too complicated. There
are too many options IMO.

I'm not sure if 'Close all externally modified files' is worth having
and is a safe workflow, certainly it shouldn't include modified documents.


Agreed.  I'm not sure it's useful, at least as-is.  If we have "close
all others", why not "reload all others"?  And I'm really not sure it
makes sense to suppose that one wants to perform the same action on all
files matching the "externally modified" criteria.


Exactly, usually I want to reload some and close the others.


I don't think we need a Close button. Closing the document can be done
in the normal way. Or were you planning on disabling normal closing?
That would complicate the UI code.


IIUC, the idea was that closing the document "the normal way" would ask
again if the user didn't make a choice yet.  And although it might
indeed look duplicate, I think it's important to make it a clearly
visible option as an answer to the question.  It being a button or
something else I don't have an opinion yet.


OK. Presumably 'normal' save or reload would also ask the user for 
confirmation. Are there any other use cases like these, maybe from plugins?


BTW should we make a release before these changes? Especially if coupled 
with the file-monitor instead of disk poll change, I think this will 
need time to stabilize. Perhaps we should delay this to 1.24?



Mockup for "document changed on disk":
http://codebrainz.ca/images/infobar-mockup.png

Mockup for "document deleted (or moved) on disk":
http://codebrainz.ca/images/infobar-mockup-deleted.png


I'm not sure that 'Save as' is needed, the user can use 'File->Save As'
if needed. (Resave is a good option though).


Agreed.  Or simply have only "save" (or similar) that triggers a
pre-filled save as dialog, so one could just hit "save" in it to save
under the same name.  This would (IMO) fill both use-cases of save and
save as, and having to agree on the file name on such a case doesn't
look like a big issue to me.


+1


Also, as I discussed a bit on IRC (without much success though :D), I'm
not completely sure if the "dismiss" button (we agreed this probably
wasn't the best name for it BTW) is useful: I personally don't really
see why somebody would like to hide the warning while not making a
decision on what to do with the file.
Though, that's no big deal.


Agree, we probably shouldn't allow 'Dismiss'.

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

Re: [Geany-Devel] Document Message/File Monitoring Behaviour (was Re: Bug: Conflicting Keyboard shortcut in "reload file" dialog - ID: 3587465)

[Nick Treleaven]

On 01/12/2012 06:16, Matthew Brush wrote:

On 12-11-30 09:10 PM, Matthew Brush wrote:

Hi again,

Attached is a mockup of roughly what I was thinking made in 5 minutes on
some website, except I couldn't figure out how to make a warning icon
for the infobar and tab label.



I also made a mockup for "deleted/moved on disk" infobar. I'll put a
link to avoid spamming the list:


Thanks for doing the mockups. Infobars probably would be better than the 
status quo, but I think both of the mockups are too complicated. There 
are too many options IMO.


I'm not sure if 'Close all externally modified files' is worth having 
and is a safe workflow, certainly it shouldn't include modified documents.


I don't think we need a Close button. Closing the document can be done 
in the normal way. Or were you planning on disabling normal closing? 
That would complicate the UI code.



Mockup for "document changed on disk":
http://codebrainz.ca/images/infobar-mockup.png

Mockup for "document deleted (or moved) on disk":
http://codebrainz.ca/images/infobar-mockup-deleted.png


I'm not sure that 'Save as' is needed, the user can use 'File->Save As' 
if needed. (Resave is a good option though).



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

Re: [Geany-Devel] Bug: Conflicting Keyboard shortcut in "reload file" dialog - ID: 3587465

[Nick Treleaven]

On 27/11/2012 13:50, Nick Treleaven wrote:

So in the detect/reload dialog we would have buttons:
[_Close] [_No] [_Yes]

instead of:
[_Close] [_Cancel] [_Reload]

to fix the _c clashing mnemonic. This seems ok to me, but personally I
wonder if:

[_Close] [_No] [_Reload]

is better, as it avoids listing no,yes which is a little odd in order
(albeit the Gnome HIG order), and having Reload instead of Yes is
clearer IMO.


Now committed the latter to Git master.
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] Bug: Conflicting Keyboard shortcut in "reload file" dialog - ID: 3587465

[Nick Treleaven]

On 27/11/2012 18:13, Matthew Brush wrote:

On 12-11-27 09:54 AM, Nick Treleaven wrote:

On 27/11/2012 17:48, Matthew Brush wrote:

We could just drop the Close button altogether since you can already
close the document by using the close button in the notebook tab, the
close button in the toolbar, the close button in the main menu or by
using Ctrl+W (or whatever) accelerator. Unlike the "missing on disk"


That takes quite a bit longer when you have several files to reload and
you want to close most of them. This situation actually happens often
for me, I think pretty much as often as I want to reload documents.



What is your use case for when you want to close a file after it has
been externally modified on disk? I understand the case for "externally
deleted/moved" just not for "externally changed".


1. switching git branches - different branches need different files open 
in Geany. After switching I often want to close the unnecessary ones.


2. sometimes I have the same file open in two instances of Geany - 
sometimes I reuse my 1st instance to open an unrelated file for a quick 
edit and realize I actually need other files open too, so I start a new 
instance. On switching back to the 1st Geany detects the change, but I 
don't want it open any more.


The first item above is the most important. I'm not sure if there are 
other cases too, but I definitely use Close quite a lot. BTW I'm open to 
removing it if it actually causes a problem, but a mnemonic clash has 
other solutions to try first.


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

Re: [Geany-Devel] Bug: Conflicting Keyboard shortcut in "reload file" dialog - ID: 3587465

[Nick Treleaven]

On 27/11/2012 17:54, Nick Treleaven wrote:

On 27/11/2012 17:48, Matthew Brush wrote:

We could just drop the Close button altogether since you can already
close the document by using the close button in the notebook tab, the
close button in the toolbar, the close button in the main menu or by
using Ctrl+W (or whatever) accelerator. Unlike the "missing on disk"


That takes quite a bit longer when you have several files to reload and
you want to close most of them. This situation actually happens often
for me, I think pretty much as often as I want to reload documents.


And it's not just longer but awkward and repetitive and bug-prone to 
keep alternating commands quickly.

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

Re: [Geany-Devel] Bug: Conflicting Keyboard shortcut in "reload file" dialog - ID: 3587465

[Nick Treleaven]

On 27/11/2012 17:48, Matthew Brush wrote:

We could just drop the Close button altogether since you can already
close the document by using the close button in the notebook tab, the
close button in the toolbar, the close button in the main menu or by
using Ctrl+W (or whatever) accelerator. Unlike the "missing on disk"


That takes quite a bit longer when you have several files to reload and 
you want to close most of them. This situation actually happens often 
for me, I think pretty much as often as I want to reload documents.



dialog where I often use the dialog's Close button (to close and re-open
new filename), for the "changed on disk" dialog, I find the Close button
to not be very useful in practice.


> Either way, I also agree with keeping the "Reload" button.

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

Re: [Geany-Devel] Making Geany faster (reducing latency to typed text)

[Nick Treleaven]

On 25/11/2012 15:42, Evandro Borracini wrote:

Thanks Dimitar,

I've updated the patch to always call document_set_text_changed() for
BOM/ENCODING.  For UNDO_SCINTILLA, document_set_text_changed() is called
only at the first document change.

I've tested and it worked fine for me. The latency while typing is gone.
As expected, we still have a small latency at the first key hit but that
doesn't create any trouble at all.

The new patch is below.


Thanks, applied (with minor edits). I had trouble applying the patch as 
I had to convert it to tab indentation first. (Also in future please 
attach patches as a file instead of inline, as this is easier for us and 
more robust).



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

Re: [Geany-Devel] Bug: Conflicting Keyboard shortcut in "reload file" dialog - ID: 3587465

[Nick Treleaven]

On 27/11/2012 13:27, Amit Sengupta wrote:

hey! It's about the bug

http://sourceforge.net/tracker/?func=detail&aid=3587465&group_id=153444&atid=787791

i tried to debug it by changing the buttons to YES No buttons, I figured
out that the document.c is the file associated with this bug.


So in the detect/reload dialog we would have buttons:
[_Close] [_No] [_Yes]

instead of:
[_Close] [_Cancel] [_Reload]

to fix the _c clashing mnemonic. This seems ok to me, but personally I 
wonder if:


[_Close] [_No] [_Reload]

is better, as it avoids listing no,yes which is a little odd in order 
(albeit the Gnome HIG order), and having Reload instead of Yes is 
clearer IMO.


What does everyone think?


Can anyone please help me with this so that I can test this, also how to
submit the code (ie if I get it right)


I don't mind making the change myself as it's easy (once we all agree), 
so in this case it's not that necessary. But the usual way is to create 
a patch file in unified diff format. Google 'unified diff patch'.


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

Re: [Geany-Devel] Making Geany faster (reducing latency to typed text)

[Nick Treleaven]

On 24/11/2012 14:04, Colomban Wendling wrote:

A solution might be to only do the updates if (doc->changed != changed).
  I didn't look at the interactions with the rest of Geany (nor test it
actually), but looking at this I guess that changing it to:


I played with this a little. It won't work easily because 
document_set_text_changed is sometimes called to force a UI update, 
possibly even when the current doc hasn't changed. The API docs describe 
this behavior also.

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

Re: [Geany-Devel] [Geany-devel] [PATCH] File saving dialog behavior

[Nick Treleaven]

On 17/11/2012 03:22, Lex Trotman wrote:

Updated and now a pull request:
>https://github.com/geany/**geany/pull/80


Hi Nick,

This works fine for me, applies cleanly, no warnings, and meets the use
cases listed in the thread.

For me its committable as is, nice one.


Great :) I updated it to only copy the selection when there is one. This 
seems more useful.

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

Re: [Geany-Devel] [geany/geany] a3664f: Fix spawning [synchronous] commands on Windows

[Nick Treleaven]

On 16/11/2012 20:31, Dimitar Zhekov wrote:

>This confused me. Are you saying you use native Windows functions in
>combination with g_spawn? I thought only g_io_add_watch could be used.

g_spawn_async_with_pipes() returns libc/msvcrt fd-s. You can use them
to create channels, or directly.

Anonymous win~1 pipe fd-s are handled by giowin like regular fd-s
(G_IO_WIN32_FILE_DESC), which causes problems, and I wanted a single
g_source with the order of stdin/out/err operations order under my
control. So calling read() and write() turned out to be easier. giowin
uses them at the lowest level too.


OK, thanks for the info.
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] [Geany-devel] [PATCH] File saving dialog behavior

[Nick Treleaven]

On 15/11/2012 16:27, Nick Treleaven wrote:

On 09/11/2012 17:39, Nick Treleaven wrote:

On 05/11/2012 22:45, Lex Trotman wrote:

On 6 November 2012 02:02, Colomban Wendling
wrote:


Le 03/05/2012 13:41, Quentin Glidic a écrit :

The main point is about the “Rename†, the unsaved file one (last
commit message line) is a bonus.


I agree that "Open in new tab" shouldn't have precedence over "Rename".


The patch looks like it removes the disabling of Rename so it is always
enabled. I'm not sure that's a good idea, but then the 'Open in new tab'
checkbox should probably be a button itself - only it would make the
buttons too wide with that caption. 'Open in new tab' is not an action
that should typically be repeated.

...

'Open in new tab' could perhaps be superseded by File->'Save a Copy'.
The user could then open the saved copy from the recent files menu if
they want. This would be clearer and more intuitive than the current
'Open in new tab' behaviour.


I now have a different solution which I think packages the current use
cases in a better way - see:

https://github.com/ntrel/geany/commits/document-clone


Updated and now a pull request:
https://github.com/geany/geany/pull/80

This adds a Document->Clone menu item. It also disables the Save As 
dialog Rename button unless the document already exists on disk.


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

Re: [Geany-Devel] [Geany-devel] [PATCH] File saving dialog behavior

[Nick Treleaven]

On 09/11/2012 17:39, Nick Treleaven wrote:

On 05/11/2012 22:45, Lex Trotman wrote:

On 6 November 2012 02:02, Colomban Wendling
wrote:


Le 03/05/2012 13:41, Quentin Glidic a écrit :

The main point is about the “Rename†, the unsaved file one (last
commit message line) is a bonus.


I agree that "Open in new tab" shouldn't have precedence over "Rename".


The patch looks like it removes the disabling of Rename so it is always
enabled. I'm not sure that's a good idea, but then the 'Open in new tab'
checkbox should probably be a button itself - only it would make the
buttons too wide with that caption. 'Open in new tab' is not an action
that should typically be repeated.

...

'Open in new tab' could perhaps be superseded by File->'Save a Copy'.
The user could then open the saved copy from the recent files menu if
they want. This would be clearer and more intuitive than the current
'Open in new tab' behaviour.


I now have a different solution which I think packages the current use 
cases in a better way - see:


https://github.com/ntrel/geany/commits/document-clone

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

Re: [Geany-Devel] [geany/geany] a3664f: Fix spawning [synchronous] commands on Windows

[Nick Treleaven]

On 31/10/2012 17:49, Dimitar Zhekov wrote:

On Fri, 26 Oct 2012 18:44:04 +0100
Nick Treleaven  wrote:


On 26/10/2012 17:44, Dimitar Zhekov wrote:

I'm using Geany on win~1 recently, with gtk+2.16 and glib-2.22 (the
minimum versions). g_spawn_async_with_pipes() works fine for me, from a
plugin, for a console application, along with the helper.


So redirecting I/O works for stdout, stderr and it works for build
commands like gcc, make, grep, etc?


It works between a console program and the plugin that spawned it, with
{PeekNamedPipe() + read()} and {repeat write() on N ms} calls.


This confused me. Are you saying you use native Windows functions in 
combination with g_spawn? I thought only g_io_add_watch could be used.




Note that instead of EAGAIN, read() may return EINVAL, and write() may
return ENOSPC. I have no idea how the higher level I/O functions
respond, and I'm doing async spawn, not sync (though it shoudn't
differ).

One more thing you must do:

HANDLE h = (HANDLE) _get_osfhandle(fd);
DWORD state;

if (h != INVALID_HANDLE_VALUE &&
GetNamedPipeHandleState(h, &state, NULL, NULL, NULL, NULL, 0))
{
state |= PIPE_NOWAIT;
if (SetNamedPipeHandleState(h, &state, NULL, NULL))
return TRUE;
}

return FALSE;

for all fd-s used, otherwise read() and write() will block.


IME it sometimes works and sometimes doesn't, and it might depend on
which program is being spawned (e.g. which grep you use). I recently
checked the commits on the GLib gspawn-win32 code and there didn't seem
to be any relevant fixes.


The anonymous pipe I/O under Win~1 is not marked as deprecated, but all
documentation says to use overlapped I/O (which is no good for us),
and the named pipe functions work on anonymous pipes only "for
compatibility with MS-DOS LAN Manager" (sic!) IIRC, and may be killed
any time. So it's not much of a glib problem...



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

[Geany-Devel] [OT] Re: [PATCH] File saving dialog behavior

[Nick Treleaven]

On 09/11/2012 17:49, Quentin Glidic wrote:

no CRLF (why did it get these?)


I got CRLF again ;-) Maybe Thunderbird converts to CRLF as I'm on Windows:

https://bugzilla.mozilla.org/show_bug.cgi?id=161806
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] [Geany-devel] [PATCH] File saving dialog behavior

[Nick Treleaven]

On 05/11/2012 22:45, Lex Trotman wrote:

I can't find the mail with the patch quickly so I havn't looked at it.


I've attached a trailing-space stripped version of it (I had to convert 
the line-endings CRLF -> LF for git, and my project prefs stripped the 
spaces).



On 6 November 2012 02:02, Colomban Wendling wrote:


Le 03/05/2012 13:41, Quentin Glidic a écrit :

Hello,


Hi,


Attached a little patch concerning the file saving dialog.
I may have missed some use cases, but it works on all cases mentioned in
the commit message.

The main point is about the “Rename†, the unsaved file one (last
commit message line) is a bonus.


I agree that "Open in new tab" shouldn't have precedence over "Rename".


The patch looks like it removes the disabling of Rename so it is always 
enabled. I'm not sure that's a good idea, but then the 'Open in new tab' 
checkbox should probably be a button itself - only it would make the 
buttons too wide with that caption. 'Open in new tab' is not an action 
that should typically be repeated.



However, I'm not completely sure about the change on "Open in new tab"
behavior, e.g. that it has no effect either when renaming or when the
file wasn't yet saved.  Upon rename, I agree it doesn't seem to make
much sense, because the original tab would become "orphaned", and would
show a "hey, I'm not found on disk!".  But I can imagine one would save
to file while keeping the unsaved buffer open (maybe to save it to
another file again later on) -- OK, I don't have such use-case myself.




It makes sense to me when used on the save-as dialog, ie keep the old file
open in another tab as well as saving this one under a new filename.  But I
agree it doesn't make sense on rename, but how to know that the user is
going to rename to grey it out?

But neither open in new tab or rename makes sense on the save dialog, its
just that we are too lazy to define different save dialog versions IIUC :)

If save and save-as are to remain the same dialog then only save and cancel
should be sensitive on the save dialog.


Personally I would make Rename a separate command in the File menu.

'Open in new tab' could perhaps be superseded by File->'Save a Copy'. 
The user could then open the saved copy from the recent files menu if 
they want. This would be clearer and more intuitive than the current 
'Open in new tab' behaviour.



So, on this subject, open question: what do other think?  I'm OK with
the proposed behavior, but as said I could understand somebody wanting
to keep "open in new tab" with unsaved files;  but if no one cares it
probably makes the thing more intuitive to remove it (e.g. no unsaved
file after save).


I would be in favour of removing 'Open in new tab'.


Anyway, the UI should reflect the behavior, e.g. the "Open in new tab"
checkbox should be sensitive only if it will be used (with your patch,
when doc->file_name != NULL).


+1
>From 8ccb3bffad52c7bd9053e945dbb888f944151be9 Mon Sep 17 00:00:00 2001
From: Quentin Glidic 
Date: Thu, 3 May 2012 13:22:49 +0200
Subject: [PATCH] More consistent behavior for open new tab / rename
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

“Rename� is a button, so a conscious user action while “Open file in a
new tab� is a checkbox, more like a setting.

When a user wants to rename a file, she/he has to uncheck the box, which
is annoying when the new tab behavior is wanted in all other cases

There was also a little bug: the “Rename� button was not deactivated if
the saved state of the box was checked, leading to a duplicated file
when the user expected a rename

Here, we consider the button as an action i.e. prevalent on the
checkbox, which is considered as a setting

Also, when a file is unsaved, we don’t create a new tab for it
---
 src/dialogs.c |   40 ++--
 1 file changed, 14 insertions(+), 26 deletions(-)

diff --git a/src/dialogs.c b/src/dialogs.c
index 58b32f9..d06a280 100644
--- a/src/dialogs.c
+++ b/src/dialogs.c
@@ -487,12 +487,6 @@ void dialogs_show_open_file(void)
 }


-static void on_save_as_new_tab_toggled(GtkToggleButton *togglebutton, gpointer 
user_data)
-{
-   gtk_widget_set_sensitive(GTK_WIDGET(user_data), ! 
gtk_toggle_button_get_active(togglebutton));
-}
-
-
 static gboolean handle_save_as(const gchar *utf8_filename, gboolean 
open_new_tab, gboolean rename_file)
 {
GeanyDocument *doc = document_get_current();
@@ -500,27 +494,24 @@ static gboolean handle_save_as(const gchar 
*utf8_filename, gboolean open_new_tab

g_return_val_if_fail(NZV(utf8_filename), FALSE);

-   if (open_new_tab)
-   {   /* "open" the saved file in a new tab and switch to it */
-   doc = document_clone(doc, utf8_filename);
-   success = document_save_file_as(doc, NULL);
-   }
-   else
+   if (doc->file_name != NULL)
{
-   if (doc->file_name != NULL)
+   if (rename_f

Re: [Geany-Devel] [geany/geany] a3664f: Fix spawning [synchronous] commands on Windows

[Nick Treleaven]

On 26/10/2012 17:44, Dimitar Zhekov wrote:

I'm using Geany on win~1 recently, with gtk+2.16 and glib-2.22 (the
minimum versions). g_spawn_async_with_pipes() works fine for me, from a
plugin, for a console application, along with the helper.


So redirecting I/O works for stdout, stderr and it works for build 
commands like gcc, make, grep, etc?


IME it sometimes works and sometimes doesn't, and it might depend on 
which program is being spawned (e.g. which grep you use). I recently 
checked the commits on the GLib gspawn-win32 code and there didn't seem 
to be any relevant fixes.

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

[Geany-Devel] Fwd: [geany/geany] a3664f: Fix spawning [synchronous] commands on Windows

[Nick Treleaven]

Hi all,
I've replaced the command spawning code on Windows as there were serious 
issues with it (see below). I've been using my replacement build for a 
month and haven't found any problems.


This mainly affects build commands on Windows. If you use Windows, 
please test it.



 Original Message 
Branch:  refs/heads/master
Author:  Nick Treleaven 
Committer:   Nick Treleaven 
Date:Wed, 24 Oct 2012 16:35:19
Commit:  a3664fae9ece396952d732cc937e63192d8c6f76

https://github.com/geany/geany/commit/a3664fae9ece396952d732cc937e63192d8c6f76

Log Message:
---
Fix spawning [synchronous] commands on Windows

Build command spawning failed sometimes when there were several
pages of errors. In these cases the process would block for 30s and
then abort. (Some hangs were also experienced).

This fix does cause a console window to be shown for the duration of
the spawned process. This seems acceptable compared with the old
broken behaviour, and can be useful to abort the build command by
closing the console window.

Note: If 'env' is passed, the old broken spawning is used.

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

Re: [Geany-Devel] [Geany-devel] [PATCH 13/19] Remove the "set" button from the project properties dialog

[Nick Treleaven]

On 06/10/2012 17:25, Colomban Wendling wrote:

Hi,

This got committed, but actually the button did set "%p" (not %d) to the
directory in which execute non-filetype commands (like make).  This is


I was aware that it sets %p, not %d.


useful for anybody with a basedir-only build system (non-recursive
autotools, handmade Makefiles, Waf, plenty of others), so I think
providing an easy way to set this is useful.

Commit is 9add067c040b23753d982688eb19fee932437301

What do you think?


I had 2 reasons to remove it:

* It's bad UI design to have a button on one notebook page that silently 
affects fields on another notebook page.
* It's quite easy to type %p, select it and middle-click paste it to any 
other fields desired.


I'm not against adding something like it, so long as it's on the Build page.

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