[Geany-Devel] Re: Geany 2.0 has bad or missing signing keys

[Colomban Wendling via Devel]

Hello,

Le 19/10/2023 à 21:52, Doug Henderson via Devel a écrit :

Hi,

I always like to be able to download the pubkeys and signatures so I
can verify the downloads before doing the installation.


That's good!  Although for actual security you should have a trusted 
path to the PGP key, just downloading everything from the same website 
is just gonna help verifying corruption during the transfer :)



gpg2 gives me these diagnostics:

geany-2.0.tar.bz2.sig
Good signature from "Colomban Wendling " [expired]

geany-2.0.tar.gz.sig
Good signature from "Colomban Wendling " [expired]

[…]

In summary,  two expired keys were used to sign the geany 2.0 assets,


Sorry, they key expiry was updated on keyservers, but not on geany.org. 
This should now be fixed.



There are also no signatures for the .zip and .tar.gz files containing
the source code for both geany and geany-plugins.


You mean the ones labelled "source code" from GitHub Release page [1]? 
Those are automatically generated by GitHub and contain the Git state, I 
don't think we can sign that.  However, they are generated from the Git 
tag, which is signed with the same key as the one that signed the 
release tarballs.


[1] https://github.com/geany/geany/releases/tag/2.0.0


With previous releases,  I have also used the MD5SUM, and SHA*SUM
files for additional verification.


This should also be available already, isn't it?

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

[Geany-Devel] Re: Geany colour scheme on MIT license?

[Colomban Wendling via Devel]

Hello,

Le 13/03/2023 à 21:18, Julian Groß via Devel a écrit :
is it possible to use the default Geany colour theme (as defined in 
https://github.com/geany/geany/blob/master/data/filedefs/filetypes.common ) in an MIT licensed project?


I myself have no problem with this at all, but it might be legally 
tricky, given GPLv2 is not "compatible" with MIT it would require the 
approval from everybody that contributed to it (as we don't require 
contributors to hand over their copyright rights to us).  However, you 
might be so lucky that the colors themselves have never been altered by 
anybody but a few original authors (my guess would be something like 
Enrico and/or Nick, and possibly Matthew and I, maybe a few others).


You probably could "fairly easily" (for some definition of that) find 
the list of people you'd need ACK from using a combination of `git 
blame`, `git log -G` and or other history scrapping tool.


Or maybe the color scheme itself could be considered not an important 
enough original work that nobody would really care.


Anyway, good luck, and you have my blessing, for whatever it's worth.
Colomban
___
Devel mailing list -- devel@lists.geany.org
To unsubscribe send an email to devel-le...@lists.geany.org

[Geany-Devel] Re: Problems with building geany plugins

[Colomban Wendling via Devel]

Hello,

Le 04/03/2023 à 14:32, fireclawthefox--- via Devel a écrit :

[…]
configure.ac:16: error: possibly undefined macro: AC_DISABLE_STATIC
   If this token and others are legitimate, please use m4_pattern_allow.
   See the Autoconf documentation.
configure.ac:17: error: possibly undefined macro: AC_PROG_LIBTOOL
autoreconf: error: /usr/bin/autoconf failed with exit status: 1
configure: error: cannot find required auxiliary files: compile missing 
install-sh


Looks like you might be missing libtool?
___
Devel mailing list -- devel@lists.geany.org
To unsubscribe send an email to devel-le...@lists.geany.org

[Geany-Devel] [ANN] Geany 1.37.1 is out!

[Colomban Wendling]

We are happy to announce a new release of Geany!

This is a bug fix release following the recent release of Geany 1.37.

On Windows, Geany crashed on startup without an existing configuration
file. This release fixes this bug and Geany will startup normally again.

Other operating systems were not affected.

As usual, all downloads can be found on
https://www.geany.org/download/releases/.

- Colomban



signature.asc
Description: OpenPGP digital signature
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

[Geany-Devel] [ANN] Geany 1.37 is out!

[Colomban Wendling]

We are happy to announce a new release of Geany!

For a comprehensive list of changes please see:
https://www.geany.org/documentation/releasenotes/

Some highlights:

* Save main and project configuration whenever documents are
  opened/closed to reduce accidental loss of current session in the
  event of a crash (can be disabled).
* Fix a possible crash when quitting (Hodong & Guido Falsi).
* Show OS info in debug messages which can and should be included in bug
  reports to ease support and debugging.
* Update Scintilla to version 3.21.1.
* Add BibTeX (Mirco Schoenfeld) and Smalltalk (Snowflake the Pony).
* Update FreeBasic, JavaScript (dmitryunruh), Lua (Filip Szymański) and
  Python filetypes.
* Support programming ligatures (like Fira Code font) on Windows.
* New translations: ie
* Updated translations: da, de, el, es, fr, id, it, ja, lv, nl, pl, pt,
  ru, sk, sv, zh_CN

This is the last release supporting GTK+2 and Windows i686 binary
builds. Starting with the next release, Geany will require GTK3, a C++17
compiler (like GCC 7.3 or Clang 4.0) and Windows binary builds will only
be provided for the x86_64 architecture.

We want to thank all developers, translators and everyone who
contributed to this release with patches, feedback, bug reports and so
on. Thank you!

As usual, all downloads can be found on
https://www.geany.org/download/releases/.

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

Re: [Geany-Devel] Smalltalk support in Geany

[Colomban Wendling]

Le 16/11/2019 à 22:45, Snowflake the Pony a écrit :
>>I fixed the bits I mentioned and did rudimentary testing that shows it
>>works well.  The lexer is indeed a plain copy of Scintilla's one, so no
>>problem here.  IMO this is fine to go in, and I'll make a PR for review.
>>
>>@Snowflake what credit should I use?  Your name and email as see on this
>>ML, or something else?
>>
>>Cheers,
>>Colomban
> 
> Thank you very much! I had freed some time this Sunday to look over
> those issues you mentioned, but you beat me to it. Again, thanks!

No problem.  It's now visible at https://github.com/geany/geany/pull/2399.

Is there some command build commands for Smalltalk?  E.g. a common
compiler available on major platforms or such, so that we could provide
a mostly sensible default set of commands.  If there isn't it's no big
deal, it's just nicer if we configure something useful by default, even
if most users will end up either altering the configuration or plainly
use external tools directly.

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

Re: [Geany-Devel] Smalltalk support in Geany

[Colomban Wendling]

Le 14/11/2019 à 13:17, Colomban Wendling a écrit :
> […]
> * the scintilla/scintilla_changes.patch patch needs updating
> * there seem to be an indentation issue in src/filetypes.c
> * maybe comment_single shouldn't be set to an empty value
> 
> I didn't test, but apart from that it looks good (not tested yet).

I fixed the bits I mentioned and did rudimentary testing that shows it
works well.  The lexer is indeed a plain copy of Scintilla's one, so no
problem here.  IMO this is fine to go in, and I'll make a PR for review.

@Snowflake what credit should I use?  Your name and email as see on this
ML, or something else?

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

Re: [Geany-Devel] Smalltalk support in Geany

[Colomban Wendling]

Le 13/11/2019 à 22:24, Lex Trotman a écrit :
> Geany is a volunteer project, nothing will happen unless "somebody"
> submits a pull request.  Not saying it will be accepted, but if nobody
> has done it to date it likely means nobody uses smalltalk and it isn't
> going to happen otherwise.

I myself think a patch is fine, and this one looks quite good at first
glance (assuming the lexer is Scintilla's upstream one).
All I can notice is that:

* the scintilla/scintilla_changes.patch patch needs updating
* there seem to be an indentation issue in src/filetypes.c
* maybe comment_single shouldn't be set to an empty value

I didn't test, but apart from that it looks good (not tested yet).

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

Re: [Geany-Devel] [ANN] Geany 1.36 is out!

[Colomban Wendling]

Le 30/09/2019 à 17:47, Tim Tassonis a écrit :
> […]
> 
> A quick question: ist GTK+2 still the recommended toolkit, or is it now
> GTK+3?

Currently they are both supported just as well (but maybe not on
Windows, I'm not sure GTK3 is much tested), the only thing that might
differ is which plugins work: most work with both, but not all of them.

So it's mostly up to you.  Most Linux distributions are now distributing
a GTK3 version, but that doesn't mean much more than the GTK3 version
getting more attention.

For the moment we don't plan on phasing out GTK2 support, and that'll
most likely remain the like this unless it starts being problematic, or
in a far future where GTK2 had effectively been buried for long.

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

[Geany-Devel] [ANN] Geany 1.36 is out!

[Colomban Wendling]

We are happy to announce a new release of Geany!

For a comprehensive list of changes please see:
https://www.geany.org/documentation/releasenotes/

Some highlights:

* Add support for fractional font sizes (Pedro Henrique Antunes de
Oliveira).
* Improve matching filetype extensions.
* Add Apple Swift (Ankit Pati), Nim (Simon Krauter), Kotlin, Groovy and
TypeScript filetypes.
* Update CUDA (Rajesh Pandian M) and NSIS filetypes.
* Update Scintilla to version 3.10.4.
* Fix build on recent MSYS2.
* New translations: ku
* Updated translations: da, de, es, fr, it, ja, lv, pt, sk, sv, zh_CN

We want to thank all developers, translators and everyone who
contributed to this release with patches, feedback, bug reports and so
on. Thank you!

As usual, all downloads can be found on
https://www.geany.org/download/releases/.

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

Re: [Geany-Devel] Recommended introduction email

[Colomban Wendling]

Hi Lukas, and welcome around those parts!

Le 27/09/2019 à 10:48, Lukas R a écrit :
> I like the idea behind Geany and like it's approach already but if I'm
> honest the main reason I'm here is to improve the vimode plugin […]

It's great to focus and what is of actual interest to you, so that's
perfect; and I'm sure the author of that plugin will be happy to see and
review your contributions :)

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

[Geany-Devel] [ANN] Geany 1.34.1 is out!

[Colomban Wendling]

Shortly after 1.34, we have released 1.34.1 which fixes a few issues
that were discovered in the 1.34 release.  Most importantly, while
fixing other related issues, version 1.34 broke line breaking feature on
existing lines, and unwillingly changed the modifier for rectangular
selections on Windows.

We also took the opportunity to include a Ukrainian translation update
that didn't make it into 1.34 in time, as well as a fix for displaying
filenames containing XML control characters inside infobars.

For a more detailed and comprehensive list of changes please see:
https://www.geany.org/Documentation/ReleaseNotes

As usual, all downloads can be found on
https://www.geany.org/Download/Releases.

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

[Geany-Devel] [ANN] Geany 1.34 is out!

[Colomban Wendling]

We are happy to announce a new release of Geany!

For a comprehensive list of changes please see:
https://www.geany.org/Documentation/ReleaseNotes

Some highlights:

* GTK version to build against is now automatically detected.
* Show part of the file path to show unique items in the go to symbol
popup (Thomas Martitz).
* Fix high CPU usage with the Scope plugin (Dimitar Zhekov).
* Update Scintilla to version 3.10.0.
* Fix display issues on Windows with HiDPI displays.
* Fix line breaking with multi-byte characters.
* Update Python 3.7 keywords and PHP 7.2 tags.
* New translations: da.
* Updated translations: de, dk, es, fr, hu, it, ja, pt, sv, sk, uk, ru,
zh_CN, zh_TW.

We want to thank all developers, translators and everyone who
contributed to this release with patches, feedback, bug reports and so
on.  Thank you!

As usual, all downloads can be found on
https://www.geany.org/Download/Releases.

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

Re: [Geany-Devel] Linker issues with VTE

[Colomban Wendling]

Le 22/02/2018 à 15:09, Lars Paulsen a écrit :
> Then I installed it using apt-get install but Ubuntu only installed a
> version 0.42 which was older than required.

It sounds odd you'd need a version not found in Ubuntu, unless you'd be
using a very old Ubuntu.  And in any case, depending on something too
recent for major distributions to have it has to be a conscious choice:
some users might not have access to your software, or have a harder time
to get it.  Just a thought.

> So I downloaded the sources and built it myself.
> After that the error message about the missing "#include "
> was gone.
> 
> But I got linker errors for calls to unresolved external function
> "vte_terminal_set_color_foreground_rgba". I assume this is some geany
> macro stuff. It turned out I can simply call
> "vte_terminal_set_color_foreground" because they changed the parameter
> from "GdkColor" to "GdkRGBA" - just what I needed.

Oooh, right, in Geany we have wrappers to bridge this ABI break so we
don't have to deal with it, so yeah the `_rgba` suffix is just an
internal Geany glitch in vte.c, not any actual API anywhere. Sorry for
the confusion it gave you indeed.

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

Re: [Geany-Devel] Linker issues with VTE

[Colomban Wendling]

Le 21/02/2018 à 15:06, Lars Paulsen a écrit :
> Hi All,
> 
> during porting the scope plugin to GTK3 I had to switch from "GdkColor"
> to
> "GdkRGBA".
> The scope code was calling "vte_terminal_set_color_foreground" which
> according to the geany header files seems to have a replacement  which I
> called instead: "vte_terminal_set_color_foreground_rgba". Since I
> replaced the call I get linker errors.
> 
> I saw that geany is creating the functions through a macro surrounded by
> some version checks. I assume I have to change something on the build
> parameters for geany to make it work. Please help.

Don't touch Geany itself, only Geany-Plugins.  And you have to change so
you use a GTK3 version of libvte with that function ("libvte2.90"
package IIRC) and not the GTK2 version ("vte").

Regards,
Colomban
___
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

[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/723f4302e0d7bbd938c789b9730366f7c7e03080).
 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.

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

[Geany-Devel] Workbench translation and the use of Directory vs Folder

[Colomban Wendling]

Hey Lars, and other translators,

I'm trying to translate the Workbench plugin in French, and beside the
trickiness of translating (or not) "Workbench" itself, I'm highly
puzzled by the use of both "Directory" vs. "Folder" in very similar
manner yet with apparently distinct meanings.

For example, there is "Open all files in directory", but also "Open all
files in folder".  I'm not a native English speaker, but I do find this
very obscure: for what I know, "folder" and "directory" are mostly
interchangeable terms in the common computer world, and it's certainly
not clear what is the difference between those for me in that context.

So I think there should be a better wording in English so that the user
could understand what each of those do, and how they are different.
Also, I'm afraid the use of those will be inconsistent with other part
of the software (Geany, GTK, and likely other plugins), not helping
being clear.
And for now I cannot translate those properly, because I still have no
idea what the difference is, and although in French I could translate
"directory" to "répertoire" and "folder" to "dossier", it would have the
exact same problem here: they are basically equivalent in this context.

So Lars, could you explain the difference between those?
And to the other translators, what did you do with this?

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

Re: [Geany-Devel] Fwd: Updating Geany doesn't update user's filetypes files

[Colomban Wendling]

Le 25/06/2017 à 17:22, Lex Trotman a écrit :
> […]
> As Matthew says the filetype files in the users directory are the
> users own, it would be rude of Geany to overwrite them, since users
> likely want to keep changes they made.  Geany overwrites the system
> filetype files only.  If you want to use that just delete the entries
> in your user filetype files for the things you want to use the system
> files for.  Or delete the user files if you have made no other
> changes.

Exactly: only keep what you actually intend to overwrite in the user
filetypes.  Maybe we should have a comment somehow in those files
mentioning it to suggest that to the users?

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

Re: [Geany-Devel] [geany/geany-plugins] 9fe302: Add missing style mappings for Rust and PHPSCRIPT

[Colomban Wendling]

Hey,

Couldn't you use something like `!highlighting_is_code_style()` or
alike?  Maybe it wasn't part of the API earlier or there's a subtlety I
didn't think about, but it would seem more robust.

Cheers,
Colomban

Le 25/05/2017 à 09:23, Enrico Tröger a écrit :
> Branch:  refs/heads/master
> Author:  Enrico Tröger 
> Committer:   Enrico Tröger 
> Date:Thu, 25 May 2017 16:23:38 UTC
> Commit:  9fe302801be4ac87e86a7533385c10bfbd5876a9
>  
> https://github.com/geany/geany-plugins/commit/9fe302801be4ac87e86a7533385c10bfbd5876a9
> 
> Log Message:
> ---
> Add missing style mappings for Rust and PHPSCRIPT
> 
> 
> Modified Paths:
> --
> spellcheck/src/speller.c
> 
> Modified: spellcheck/src/speller.c
> 21 lines changed, 21 insertions(+), 0 deletions(-)
> ===
> @@ -889,6 +889,7 @@ gboolean sc_speller_is_text(GeanyDocument *doc, gint pos)
>   break;
>   }
>   case SCLEX_HTML:
> + case SCLEX_PHPSCRIPT:
>   case SCLEX_XML:
>   {
>   switch (style)
> @@ -1145,6 +1146,26 @@ gboolean sc_speller_is_text(GeanyDocument *doc, gint 
> pos)
>   }
>   break;
>   }
> + case SCLEX_RUST:
> + {
> + switch (style)
> + {
> + case SCE_RUST_DEFAULT:
> + case SCE_RUST_COMMENTBLOCK:
> + case SCE_RUST_COMMENTBLOCKDOC:
> + case SCE_RUST_COMMENTLINE:
> + case SCE_RUST_COMMENTLINEDOC:
> + case SCE_RUST_STRING:
> + case SCE_RUST_STRINGR:
> + case SCE_RUST_BYTESTRING:
> + case SCE_RUST_BYTESTRINGR:
> + case SCE_RUST_LEXERROR:
> + return TRUE;
> + default:
> + return FALSE;
> + }
> + break;
> + }
>   case SCLEX_SQL:
>   {
>   switch (style)
> 
> 
> 
> --
> This E-Mail was brought to you by github_commit_mail.py (Source: 
> https://github.com/geany/infrastructure).
> ___
> Plugins-Commits mailing list
> plugins-comm...@lists.geany.org
> https://lists.geany.org/cgi-bin/mailman/listinfo/plugins-commits
> 

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

[Geany-Devel] [ANN] Geany 1.30.1 is out!

[Colomban Wendling]

Shortly after 1.30, we have released 1.30.1 which fixes calltip and
auto-completion popup placement with multi-monitor setups [1].  We are
sorry for this inconvenience.

We also took the opportunity to include new translation updates that
didn't make it into 1.30 in time: ca, de, el, es, sk.

As usual, all downloads can be found on
https://www.geany.org/Download/Releases.

- Colomban

[1] https://github.com/geany/geany/issues/1422
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

[Geany-Devel] [ANN] Geany 1.30 is out!

[Colomban Wendling]

We are happy to announce a new release of Geany!

For a comprehensive list of changes please see:
https://www.geany.org/Documentation/ReleaseNotes

Some highlights:

* Initial accessibility support in the editor.
* Fix scrolling on Wayland.
* Fix Ctrl+X and Ctrl+C in non-Latin keyboard layouts (Forkest).
* Update Scintilla to version 3.7.3.
* Add Arduino custom filetype (SukkoPera).
* Updated translations: de, es, fr, it, lt, pt.

We want to thank all developers, translators and everyone who
contributed to this release with patches, feedback, bug reports and so
on.  Thank you!

As usual, all downloads can be found on
https://www.geany.org/Download/Releases.

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

Re: [Geany-Devel] [geany/geany] b974d2: C: Fix line continuation handling

[Colomban Wendling]

Le 20/01/2017 à 14:05, Colomban Wendling a écrit :
> Branch:  refs/heads/c/backslashes
> Author:  Colomban Wendling <b...@herbesfolles.org>
> Committer:   Colomban Wendling <b...@herbesfolles.org>
> Date:Fri, 20 Jan 2017 13:05:03 UTC
> Commit:  b974d26dff67d0e8dd768057b8b47a0ba67f0315
>  
> https://github.com/geany/geany/commit/b974d26dff67d0e8dd768057b8b47a0ba67f0315

Sorry, push fail while playing with `git hub` command.  I now deleted
the branch, and properly PR'd: https://github.com/geany/geany/pull/1370
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

[Geany-Devel] [ANN] Geany 1.29 is out!

[Colomban Wendling]

We are happy to announce a new release of Geany!

For a comprehensive list of changes please see:
https://www.geany.org/Documentation/ReleaseNotes

Some highlights:

* Fix executing external commands on Windows.
* Fix search entries color with the default GNOME 3.20 GTK2 theme.
* Add support for keeping the cursor a number of lines from the edges to
  always show some context.
* Update Scintilla to version 3.7.0.
* Improve support for GTK 3.22.
* Add support for VTE 0.38 and newer.
* Update translations: ca, de, el, es, fr, id, it, kk, nl pt, pt_BR,
   sv, zh_CN.

We want to thank all developers, translators and everyone who
contributed to this release with patches, feedback, bug reports and so
on.  Thank you!

As usual, all downloads can be found on
https://www.geany.org/Download/Releases.

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

Re: [Geany-Devel] Future removal of Geany-Plugins from Fedora

[Colomban Wendling]

Le 12/11/2016 à 00:24, Matthew Brush a écrit :
> […]
> P.S. It is my Markdown plugin that is threatening the removal of the
> entirety of Geany-Plugins (upgrade patches welcomed).

Might also be WebHelper, maybe I/we should upgrade to webkitgtk2 or
something.  I don't have plans to do that before Sunday, but if it's
something useful I can try and work on the WebHelper part, it shouldn't
be too hard I guess as that plugin doesn't use too many advanced features.

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

Re: [Geany-Devel] [FT-plugins] Proposed "Features"

[Colomban Wendling]

Le 31/08/2016 à 03:27, Matthew Brush a écrit :
> On 2016-08-30 06:43 AM, Colomban Wendling wrote:
>> Le 29/08/2016 à 05:14, Matthew Brush a écrit :
>>> […]
>>
>> I'm really not sure it's a good idea to go the custom callback way.
>> IMO, we should first try and see how easy it'd be with plugins providing
>> their own full-blown Scintilla lexer library that we just add and use.
>>
> 
> The only positive I really see, which in practice probably won't exist,
> is modularity and ability to re-use lexers independent of
> Geany/ft-plugin (ie. for all Scintilla-using apps). I say in practice
> because at least with my `LexClang.so` I needed it to be bound into
> Geany anyway to get hooks for when to re-parse (you can't re-parse a
> million token C++ file each time Scintilla wants to re-colour a line of
> code). Further, the dynamic lexer needs to cooperate with
> Geany/ft-plugin, or at least deviate from normal Scintilla lexers, if it
> wanted to provide/setup its own lexical states/styles (TBD how this part
> will go).
> 
>> Having our own callback means one more indirection, and changing the
>> SciLexer to CONTAINER anyway, so I don't see much advantage just now.
>>
> 
> With the `LexClang.so` dynamic lexer I made, dynamic lexers seemed not
> to fit well (too isolated, too many assumptions that it's a simple dumb
> lexer and not a semantic-based on, etc) . All I really wanted was a way
> to disable Scintilla's lexer (ie. switch it to `SCLEX_CONTAINER`)
> without changing the filetype in Geany, and without doing it behind
> Geany's back from the plugin.

Okay then, if there's good reasons to do so, fine.

I just thought that it would be handier if later on plugins want to be
able to add new filetypes altogether (e.g. not necessarily based on
lib, but just filetypes), but maybe not, or maybe it's not
good for all cases.

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

Re: [Geany-Devel] [FT-plugins] Proposed "Features"

[Colomban Wendling]

Le 31/08/2016 à 13:22, Thomas Martitz a écrit :
> Am 31.08.2016 um 13:03 schrieb Jiří Techet:
>> […]
>>
>> No, performance is a very valid point. Tag updates don't happen in a
>> background thread in Geany but rather on the main thread (and changing
>> this would require lots of modifications as neither ctags, nor TM nor
>> Geany are thread-safe) and all updates have to happen in a really
>> short time period - you cannot make the GUI freeze while the user is
>> typing so you have 100ms at most without any noticeable delay.
> 
> I'm saying we can't evaluate performance at this time, because no
> implementation is available. So saying now "uhm I fear it might be too
> slow my guess is that the other one is 100x faster" is just a wild
> assumption that doesn't help except spraying FUD. And outright rejecting
> a proposal based on such assumptions is invalid.

I wouldn't dismiss Jiří's performances remarks that easily :)  Remember
he spent a fair amount of time optimizing it, and has had experience
with huge amount of tags with his project-organizer plugin on large
projects (Linux kernel, anyone?).
And IIUC, he realized that with all the tags *current* parsers generate
(e.g. no local variables, etc.) TM started to struggle too much for it
to be usable.

Sure, we need numbers, but I'm afraid we kinda already have some idea of
what they would be.

Yes, maybe it'd be possible to improve the situation even further, but
it might be a lot of work for very little gain.  I would guess if a e.g.
libclang works with real-size projects is because it has a lot of highly
specific optimizations resulting of a lot of work on their side.  And
why I'm not sure it's even so useful for TM anyway, is that both Lex and
Matthew showed some semantic examples that are both very subtle to deal
with, and highly specific to some languages (here, C++) -- I love Lex's
ADL example, C++ can seem just crazy :)

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

Re: [Geany-Devel] [FT-plugins] Proposed "Features"

[Colomban Wendling]

Le 30/08/2016 à 17:31, Thomas Martitz a écrit :
> Am 30.08.2016 um 03:56 schrieb Lex Trotman:
>>> […]
> 
>> Certainly 1) showing symbols in the symbol list, 2) autocomplete and
>> 3) calltips are currently available to a degree in Geany.  But
>> highlighting, build commands and build result handling are not.
> 
> 
>> But
>> to be able to do 2) and 3) accurately needs more knowledge of each
>> language semantics than is currently available in Geany or tagmanager.
> 
> That's right. But it doesn't mean the features should be *entirely*
> moved into plugin space. TM should be improved to be able to hold
> sufficient information, and plugins should help by providing that data.
> But *just* the data, don't offload very specific use cases onto them,
> this will make us less flexible in the long run. If Geany has the data,
> we can implement new features inside Geany or non-ft-plugins. Otherwise
> we would have to modify every single ft-plugin for new features and
> exclude non-ft-plugins.

I don't think the real problem for the current state to really only be
about what tags are generated.  Sure, if tags for local variables were
generated, scope completion would become more useful just like that
indeed.  And then, the current code should only be improved to properly
use the tags to show completions.

But this doesn't take into account several language specific things, like:

* what is an identifier? (for looking up what to complete)
* what is an argument list? (for showing calltips)
* what are the scope semantics?
* …

Sure, some of those can be implemented generically using TagManager
capabilities with appropriate tags, just by improving the generic code.
But that means scope semantics are always the same, or are pluggable,
and same for the other details.

Yes, I'd love TagManager (and our use of it rather) to be as good as it
can get, and it could get pretty far (like what I tried with that
"visible in current scope" patch in the scoped calltip PR).
It's not trivial (like requires to know all the imported namespaces and
stuff), but it's doable if all languages can fit in the same jar [1]

But if a language has totally different semantics than, say, C++, we'd
be pretty much screwed no matter how good the C++ semantics were.

Also, I think Matthew pointed out that in any case, to get perfect
completions we'd need prefect tags, and that we'd have to check how fast
it is with virtually an infinite set of tags (Jiří?).  But that's indeed
not a concern to have now.


Anyway, my point is that I totally agree that we should try to get TM
completions to the best they can be, but that no matter how good it is
won't ever be as good (well, at least not better) than completely
specific code.  So I think Matthew's goal of allowing to *replace* code
deciding what to complete makes sense.


Regards,
Colomban


[1] I don't know the English expression, so I built one that sounded nice :)
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] [FT-plugins] Proposed "Features"

[Colomban Wendling]

Le 29/08/2016 à 05:14, Matthew Brush a écrit :
> […]
> 
> Syntax Highlighting
> ---
> 
> Most likely using an API based on/similar to Scintilla's "container
> lexers".
> 
> At the minimum, it could have a callback something like:
> 
> gboolean (*highlight)(GeanyPlugin*, GeanyDocument*,
> guint start_pos, guint end_pos, gpointer user_data);
> 
> As with Scintilla's "container lexer", it would just tell the provider
> what and where to highlight. It might be pointless providing `end_pos`
> it could probably just highlight a whole line at time (maybe like
> Scintilla's 'style-needed' notification).

I'm really not sure it's a good idea to go the custom callback way.
IMO, we should first try and see how easy it'd be with plugins providing
their own full-blown Scintilla lexer library that we just add and use.

Having our own callback means one more indirection, and changing the
SciLexer to CONTAINER anyway, so I don't see much advantage just now.
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] [FT-plugins] Proposed "Features"

[Colomban Wendling]

Le 29/08/2016 à 10:04, Jiří Techet a écrit :
> […]
> 
> sounds good. This is much more lightweight than how #1195 and various
> other discussions sounded, I'm happy :-).

Agreed :)  I was a little afraid of seeing a proposal introducing a
gazillion GObject interfaces and GIO extension points ^^

> All the described functions look good to me in principle except the
> sidebar symbol tree one. The current code is quite complex (I was fixing
> some minor issues there and spent a lot of time thinking if it could be
> simplified but I don't think so). The problem is this: if a file is
> reparsed and you get new symbols, if you just cleared the tree and
> repopulated it with the new tags, the tree would jump to the beginning
> no matter where the scrollbar was before. So what the code does now is
> it compares the old and new tags, removes the tags that aren't present
> in the new tags array and inserts new tags which weren't present in the
> old tag array to the right position. If you have a look at the code,
> this isn't probably something you want to write in a plugin :-). So a
> plugin should provide the full list of new tags so the tree can do all
> this diffing and updating.

Agreed.  And the tree updating avoids scroll movements, flickering and
also proven significantly faster than re-building the whole tree (well,
than the previous code at least).

> Which brings me to a question - do you plan to generate TMTag(s) and
> feed them to the tag manager instead of the ctags ones? It shouldn't be
> that hard and if you do this, you could have the sidebar symbols updated
> for free.

I don't know if plugins should fill the TagManager with extra tags, but
I agree that plugins should probably use the TMTag structure to pass
Tag-like data to Geany.  For example, for symbols tree, autocompletion
suggestions and calltips: instead of providing a list of strings,
provide a list of TMTags.  As I see it, a TMTag structure contains
everything useful for the current feature set (and could be extended),
and are a fairly canonical representation of it.
A plugin could create temporary TMTags just to give to Geany, or
maintain its own list (or feed TagManager, if we wanted), but anyway
just pass the ones it want to the various APIs.

TMTags contain name, scope (useful for symbol tree and currently
calltips), type (useful for icons at least), signature, etc.  All we
need in various places.  And a plugin could leave many fields empty if
it doesn't care about them, not many fields are actually required.

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

Re: [Geany-Devel] [FT-plugins] Proposed Design

[Colomban Wendling]

Le 29/08/2016 à 03:09, Matthew Brush a écrit :
> On 2016-08-28 05:47 PM, Matthew Brush wrote:
>> [...]
>>
>> To give an idea, the registration function called by plugins might look
>> something like this:
>>
>> gboolean ftplugin_register_provider(GeanyPlugin*,
>> GeanyFiletypeID, GeanyFiletypeFeature, GCallback, gpointer);
>>
>> [...]
> 
> I forgot to mention, it may turn out that in order to provide a feature,
> there may be a need for multiple callbacks (ex. activate, deactivate,
> init_styles, prepare_list, whatever). If this ends up being the case, we
> would need to either pass a table of callbacks here or perhaps a GObject
> implementing a particular interface or whatever.

Then probably better make the provide a structure like

GeanyAutoCompleteProvider {
GeanyFiletypeID filetype;
GCallback feature1;
...
}

In theory I have nothing against GInterface, but I'm not quite sure it's
a good idea to start riddling Geany with GObject API where we already
have like 2 non-GObject-ish API styles (plugin registration, Proxy
registration, signals…)

Not saying GInterface is a presona non-grata, but that IMO it would have
to prove very useful over the other solutions to be used.  Especially as
people are likely to implement these filetype features in C or C++ more
than Python, JavaScript or Ruby, so it should be comfortable in C and
C++, and you know you don't like GObject boilerplate :)
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] Integrate ESLint into Geany

[Colomban Wendling]

Le 11/08/2016 à 00:27, Abel a écrit :
> […]
> 
> If the editor can execute Node.js directly (like Atom or Visual
> Studio Code), you can use Node.js
> API: http://eslint.org/docs/developer-guide/nodejs-api
> Otherwise (like
> Sublime Text or Vim), maybe you can use CLI and communicate
> by stdio: http://eslint.org/docs/user-guide/command-line-interface
> 
> 
> 
> But if there are plugins for sublime or vim using CLI, it seems that the
> CLI way is not that bad.
> BTW, I forgot to link to the list of known editors integrations with
> ESLint: http://eslint.org/docs/user-guide/integrations#editors
> 

If you can communicate with the process yes, you could write a plugin
doing so more dynamically than a build command.  If the process can work
with pipes even better.
That's a Mere Matter of Programming, but it should not be *too* hard to
do (Geany even has some supposedly handy API for communicating with a
subprocess, taking care of the most obvious issues it implicates).

> Also, for the moment you pretty much need to write Geany
> plugins in C or C++, although Thomas' Peasy plugin [1] adds support for
> several languages (include JS I'd believe), and it's getting closer to
> stability. 
> 
> 
> What about Vala?

Well, Vala requires a description of the C API too, but yes it can work.
 There is a manually generated VAPI file, but Thomas' work also generate
a VAPI file automatically.  That could probably be used.

> it's getting closer to stability means that it'll be soon inside Geany
> trunk??

It's a plugin for Geany that adds support for extra plugins (it's
actually a proxy for other plugins in other languages).  I don't know
when he'll consider it stable, but he certainly can answer.  I think he
considers it beta or close to that -- i.e. working, but would require
wider testing.

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

[Geany-Devel] Commander enhancements (was: Re: Plugins)

[Colomban Wendling]

Le 22/07/2016 à 14:03, Vasiliy Faronov a écrit :
> Colomban Wendling's Commander plugin [1] also supports switching
> between open files, even though this is not documented.

Yeah documentation could be improved indeed.

> However, to
> limit Commander to display *only* the files, you have to type an "f:"
> prefix (likewise "c:" for menu items). Personally I find this
> cumbersome, so I use a straightforward patch that adds keybindings for
> limited modes (not sending this upstream yet because it needs more UI
> work).

You could have a keybinding that just popups the dialog like normal, but
pre-fills it with the appropriate prefix.  Shouldn't be too much change
and virtually no UI rework.

I just created https://github.com/geany/geany-plugins/pull/468, seems
straightforward enough :)

> Colomban, do you think these two features -- symbols from the current
> document, and keybindings for limited modes -- would be good to have
> in Commander?

Sure, they seem useful.

About symbols, at some point I wanted to have a mode showing all symbols
form the workspace (not only current file), but a simple implementation
was way too slow with a large number of files.
Probably for one single file it'd be alright; otherwise, a more complex
but probably more efficient approach could be dynamically searching for
matches instead of building the list and filtering it.  But that
requires large rework.

Also, just one thing: adding new dynamic elements might require making
sure it doesn't get too much in the way of other matches.  I mean that
for example, out of habit I now expect some short "commands" to do
something particular, and would be a little annoyed if they didn't work
because something else matched.  But well, that doesn't have to stop
innovation either, so it's a matter of balance.
Though, with automatic filtering it becomes less of a problem, as it
becomes very easy to filter a particular category, and things in other
categories then won't conflict :)

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

[Geany-Devel] [ANN] Geany 1.28 is out!

[Colomban Wendling]

We are happy to announce a new release of Geany!

For a comprehensive list of changes please see:
https://www.geany.org/Documentation/ReleaseNotes

Some highlights:

 * Improve support for GTK 3.20.
 * Fix type name coloring when types change (Jiří Techet).
 * Fix undo of line end type change (Jiří Techet).
 * Update Scintilla to version 3.6.6.
 * Improve Goto Symbol popup contents (Jiří Techet).
 * Treat `.h` headers as C++ by default (Jiří Techet).
 * Improve symbols for Ruby.
 * Update translations: ca, de, el, es, fr, it, ja, lt, pt, ru, sk, tr,
zh_CN.

We want to thank all developers, translators and everyone who
contributed to this release with patches, feedback, bug reports and so
on.  Thank you!

As usual, all downloads can be found on
https://www.geany.org/Download/Releases.

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

Re: [Geany-Devel] Toggle menu and status bars

[Colomban Wendling]

Le 02/07/2016 à 11:08, Vasiliy Faronov a écrit :
> Hi,
> 
> Most of the time, when using Geany, I don't need the menu and status
> bars; they are just noise. But occasionally I want to check the status
> bar (e.g. for the line/column number) or browse the menu. So I want to
> toggle their visibility with a keystroke.
> 
> I wrote a simple plugin for that: https://github.com/vfaronov/geany-togglebars
> 
> The problem is, the menu and status bars are not exposed in
> geany.main_widgets, so I have to find them manually, which makes the
> plugin brittle as it relies on a specific window layout.
> 
> Perhaps there is a better way to do it?

You could use a more solid resolve_widget() function, that doesn't rely
on the layout, something like that:

> def resolve_widget(widget, expected_type):
> if isinstance(widget, expected_type):
> return widget
> elif isinstance(widget, Gtk.Container):
> for child in widget.get_children():
> ret = resolve_widget(child, expected_type)
> if ret:
> return ret
> return None

Also, your plugin is a bit dangerous for the new user if I read it
correctly: you do not bind the keybinding by default (which is good),
but you hide the menubar by default.  This means that the user enabling
your plugin might be totally lost with no way of recovering his/her
menubar to even access the preferences and set a keybinding.

I guess you did that because you didn't wanna bother about a
configuration file for saving the state for such a little thing you
probably didn't mean to publish so much, but if you do want to publish
it it'd be important to resolve this.

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

Re: [Geany-Devel] [Test] Geany GTK3 Windows binaries for testing

[Colomban Wendling]

Hey!

Le 23/06/2016 à 17:28, Jiří Techet a écrit :
> Hi Enrico,
> 
> On Fri, Jun 17, 2016 at 2:00 AM, Enrico Tröger  > wrote:
> 
> Hi all,
> 
> in preparation of the upcoming release, I renewed the test installers:
> 
> http://download.geany.org/snapshots/geany-1.28nightly20160617_setup.exe
> 
> http://download.geany.org/snapshots/geany-plugins-1.28nightly20160617_setup.exe

Nice!  Didn't test yet, but still nice.

> There is still the ugly Adwaita theme.
> I didn't and I won't play with themes. If someone wants a specific
> alternative theme included and enabled and there is some general
> agreement, I'm fine with it.

Maybe we should just wait a little further, apparently in 3.22 (?) they
work on some Windows theming and integration.

> 
> But I noticed a new bug:
> with each start of Geany, the messages window will be shown a little
> lower and at some point it is finally hidden because its position is at
> or below the status bar.
> No idea what is causing this, GTK3 is always surprising as it seems.

Hum, interesting, we did have such a report one day, but I never was
able to find out what was doing it.
https://sourceforge.net/p/geany/bugs/634/  But that was GTK2 and the
other direction (editor shrinking).

> We should decide soon whether we want to use GTK2 or GTK3 based Windows
> release binaries.
> 
> 
> I would say that if there aren't any advantages of the GTK3 build (and
> in contrary, there seem to be some issues), it's better to stick with GTK2.

Agreed, seems more reasonable to stick to something that works,
especially if GTK3 doesn't give us something important.

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

Re: [Geany-Devel] [Test] Geany 1.27 Windows binaries for testing

[Colomban Wendling]

Le 12/03/2016 16:35, Enrico Tröger a écrit :
> […]
>>
>> * Spellcheck seems to miss all dictionaries, making it not very useful
>> (and print an error when loaded)
> 
> The error message on load without any dictionaries is a known problem
> but I didn't get to fix it yet.
> But what does "miss all dictionaries" mean? There are no dictionaries
> installed by default. Did you had an existing config with a patch to
> dictionaries which don't work any longer? This would be bad.

Nope, I just mean it complains and doesn't work out-of-the-box as it
doesn't have any dictionaries.  But if it's expected none get installed
(understandable), then it's probably fine.

>> * WebHelper somewhat works, but the inspector doesn't, complains about
>> missing resource:
>>
>>> Unable to load page
>>>
>>> Problem occurred while loading the URL
>> resource:///org/webkitgtk/inspector/UserInterface/Main.html
> 
> There is a resources folder in share\webkitgtk-1.0\resources but it
> doesn't contain anything like this.
> No idea where these files normally would come from :(.

Bummer :(  Makes the plugin a fair bit less useful.  But well.

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

Re: [Geany-Devel] geany and geany-pluigins standalone installation

[Colomban Wendling]

Hi,

Le 11/03/2016 18:40, Volodymyr Kononenko a écrit :
> Hi folks,
> 
> I am trying to build PairTagHighlighter to verify PR
> https://github.com/geany/geany-plugins/pull/359
> 
> But I am getting undefined references to all Scintilla functions:
>  CCLD pairtaghighlighter.la 
> .libs/pair_tag_highlighter.o: In function `findBracket':
> /home/kononenv/devel/geany-plugins/pairtaghighlighter/src/pair_tag_highlighter.c:85:
> undefined reference to `sci_get_char_at'
> […]
> 
> The way how I build Geany:
> 
>   * ./autogen.sh
>   * ./configure --prefix=
>   * make
>   * make install

Which version of Geany?  It looks like you'd be building a relatively
old one, and a recent version of Geany-Plugins or something like this.

> The way how I build geany-plugins:
> 
>   * export PKG_CONFIG_PATH=/lib/pkgconfig
>   * ./configure --prefix=
> --with-geany-libdir=/lib --disable-addons
> --disable-autoclose  --disable-automark --disable-codenav
> --disable-commander --disable-debugger --disable-defineformat
> --disable-devhelp --disable-geanyctags --disable-geanydoc
> --disable-geanyextrasel --disable-geanygendoc
> --disable-geanyinsertnum --disable-geanylatex --disable-geanylipsum
> --disable-geanylua --disable-geanymacro --disable-geanyminiscript
> --disable-geanynumberedbookmarks --disable-geanyprj
> --disable-geanypy --disable-geanysendmail --disable-geanyvc
> --disable-geanypg --disable-largefile --disable-geniuspaste
> --disable-gitchangebar --disable-lineoperations --disable-markdown
> --disable-multiterm --disable-overview --disable-pohelper
> --disable-pretty_printer --disable-projectorganizer --disable-scope
> --disable-shiftcolumn --disable-spellcheck --disable-treebrowser
> --disable-tableconvert --disable-updatechecker --disable-webhelper
> --disable-xmlsnippets

You could use --disable-all-plugins --enable-pairtaghighlighter to avoid
having to list all --disable options ;)

> Please suggest, how to make standalone installation in a proper way.

Your way looks good, and all I can imagine is trying to build against an
old version of Geany not using libgeany and a recent enough version of
GP with
https://github.com/geany/geany-plugins/commit/25e3c8851a5113423ce16a6b80085925ebac2e13
applied.

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

Re: [Geany-Devel] RFC: Merge C and C++ Filetypes (no troll)

[Colomban Wendling]

Oops, forgot the [1]

> However, it being for build commands [1], or default extension, etc.,
> I'm not sure having one single "C and C++ headers and sources" is a
> great idea.

[1] I mostly agree stock build commands are seldom (if ever) useful with
C and C++, but for the most basic "Hello World".  .o generation is even
less useful.
However, I do have a custom script (that fetches some deps by inspecting
includes) there I use to build very simple or test stuff, and it's very
handy in such cases.
But in all cases, we could imagine having many sorts of commands, maybe
a linter or anything; anyway not necessarily the same handling both C
and C++.
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] New Lexer

[Colomban Wendling]

Hi,

Le 01/01/2016 18:09, Mark Robinson a écrit :
> Hi Guys,
> 
> Some time ago, I asked how I go about adding a new filetype/language
> to Geany called DMAP.  You kindly told me first to request a new
> lexer be added to upstream Scintilla, which I did, and it was
> accepted (it was added to Scintilla 3.3.7).
> 
> Geany has moved to a Scintilla 3.6.1, which indeed contains the new
> language.  However, when I look in the ~/geany-1.26/scintilla/lexers
> directory, I do not see the lexer's file (LexDMAP.cxx).  In fact, the
> Geany build does not contain many of the Scintilla files.  Is this
> because only the files that are used are placed in the Geany build?
> 
> Sorry if this seems like a naïve question (which it is), but if I now
> move to add a new filetype to Geany, will the references to the
> "missing" Scintilla source be handled automatically or is there
> something I need to do? - I don't want to mess things up.

Yes, only the used lexers are imported from Scintilla.  To add a new
one, just copy if from Scintilla's one, list it in src/Catalogue.cxx [1]
and in the build system and start using it.  It's mostly well documented
in the "Syntax Highlighting" section (under "Adding a filetype") of
HACKING in Geany's source tree.

Feel free to ask about any further details if you're unsure about something.

Regards,
Colomban


[1] well, actually the best way would be to edit the
scintilla/scintilla_changes.patch patch and run the update script, but
that's not yet documented and can be tricky if you're not familiar with
unified diff format.

> 
> Kind regards...M ___ 
> 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] Regex in 1.25 and 1.26

[Colomban Wendling]

Le 21/12/2015 18:31, Mark Robinson a écrit :
> Hi Guys,
> 
> Is the regular expression capability broken in 1.25 and 1.26
> 
> In 1.24, if I pop up the Find dialogue on a simple text file, I can
> search for \n with reg. expressions ticked and I find the end of the
> line.
> 
> If I do this in 1.25 or 1.26, it does not find the end of the line
> and claims it cannot find \n.
> 
> I notice single line reg. exp. was added at 1.25.

Which is the reason of your problem :)  Single-line regular expressions
can't find the \n because it's not part of the line itself, and in a
line-based regular expression the line end is $ (as it's the end of the
input).

So yes, 1.25 changed behavior by implementing single-line regular
expressions and making it the default (because I believed it was more
commonly what people were after, esp. because there's a history of
people confused by some multi-line results).

This doesn't mean you can't search for \n: you can either switch back to
multi-line regular expressions (there's a checkbox just for that), or if
you want to search for line ends (e.g. if line ends are not \n in your
file(s)), use $ with single-line regexes.

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

Re: [Geany-Devel] Devel Digest, Vol 93, Issue 2

[Colomban Wendling]

Hi,

>> […]
>>
>> The API has been fixed to not leak symbols, which it did for a few
>> recent versions. The only functions that are public, which is how it's
>> always been, are those documented in the API reference[0]. That you were
>> able to compile and link against private symbols was a bug in Geany. 

BTW, linking to private API never worked under Windows.

> […]
> 
> I can probably find an alternative workaround for document_close_all,
> e.g. iterate document_index(0) until it returns NULL, and call
> document_close; so I think should be ok too.
> 
> The project functions however, since Djynn is meant to integrate with
> the internal Geany project manager, with functions for opening and
> closing projects. I believe Geany would be enhanced by the possibility
> for plugins to open and close projects. When creating a Djynn-project a
> Geany-project is generated automatically, and when opening and closing
> Djynn-projects, the Geany-projects are opened and closed too. It's been
> working very well, seamlessly and invisibly, and would be a loss if I
> had to cut out the Geany-project integration.

I've got what might be a stupid question, but couldn't your plugin
integrate with Geany projects the other way around, e.g. your plugin
reacts to project open/close rather than making Geany react to your
plugin's project open/close?

I must admit I didn't try your plugin, but there are a few other plugins
enhancing Geany's project support, and AFAIU they do this by listening
to Geany project open/close and add their own logic to that.

> Anyway, I'm sure document_close_all could be used by many plugins, but
> filetypes_detect_from_document is not needed. The project functions
> would be much appreciated. That's all on my xmas wishlist :)

Adding `document_close_all()` sounds reasonable indeed.  Out of
curiosity, why do you need it?
Project stuff might be too, depending on your answer on the above
project-related question.

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

Re: [Geany-Devel] End of Line

[Colomban Wendling]

Hi,

Le 27/11/2015 18:57, Dimitar Zhekov a écrit :
> I see that the Scope plugin is marked in autotools as gtk+2 only,
> and rightly so. […]
> 
> Enough. If the gtk+3 developers want to target the mobile market
> or something, so be it. I'm switching to another editor. It has
> disadvantages, but is stable, and gets the job done.

I for one don't plan on dropping full GTK2 support in any near future.
Basically, unless supporting GTK2 prevents us from running on modern
OSes too, it'll (most probably) stick.

So yeah, Frank has some plans to require GTK3 support in GP plugins,
which I can understand for consistency with Geany and as some setups
will (in the future) require a Wayland-capable toolkit (which, AFAIK,
GTK2 isn't) and the likes;  but Geany (and GP) will not drop GTK2
support just like that.

Regards,
Colomban


PS:

> [1] For example, set height request 80, as somebody did for the
> Project Description field, though using a fixed height is against
> everything gtk+. […]

BTW, instead of size request you can set a "min content width/height" on
the GtkScrolledWindow.

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

AFAIK the small size is a result in changes in GtkScrolledWindow rather,
and GtkTextView only asks for its very minimal size.  GtkScrolledWindow
used to require a quite large size (I'd say around 80x80 maybe), but
that changed so now it requires its very minimal size too.

One possible "solution" for an "intelligently" sized view would be to
override the size requisition for the scrolled window and do something
"smart" in it in all cases, even if the child GtkTextView doesn't ask
for anything.

But yeah, that's kinda annoying.

BTW, I'm not sure in what context this is, but default packing flags
changed in GTK3, so some things that used to expand by default might not
anymore, so this might also be the source of the problem.
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] [geany] Avoid possible invalid memory access when activating plugin (#732)

[Colomban Wendling]

On 04/11/2015 22:21, Enrico Tröger wrote:
> On 04/11/15 14:19, Colomban Wendling wrote:
>> Re the build failures: yeah, since a few days we can't seem to
>> fetch the GTK3 bundle… it's not a biggie in practice as if all of
>> Linux+GTK2, Linux+GTK3 and Windows+GTK2 work it should be fine and
>> not require testing Windows+GTK3, but it's annoying.  I'll see what
>> we can do here.
> 
> Maybe it's worth to host the GTK bundle archives ourselves. I think
> the network traffic won't be a problem. But to do this we still need
> the original ZIP archive to e available first to download it to the
> server.

I was about to PR a change to do just that, but I got stuck at the same
point: I don't seem to have a local copy of the bundle :/  I've got the
GTK2 one but not the GTK3 one :(

Maybe someone else of us has it?  Thomas maybe?

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

Re: [Geany-Devel] Problems calling ui_update_statusbar from a plugin

[Colomban Wendling]

On 31/10/2015 14:40, Abel wrote:
> I have a fix for #631 but I was trying to fix this statusbar
> inconsistency thing as well, but I think I will open a new issue for
> that and work on them separately.
> 
> On 31 October 2015 at 13:16, Thomas Martitz  > wrote:
> 
> 
> Are you working on the existing splitwindow plugin or are you
> creating a new one?
> 
>  
> I'm working on the existing one. I prefer to solve some quick &
> essential issues first rather than create a new one

Take a look at https://github.com/geany/geany/pull/724

> I'm slowly working on a in-core solution, you can find it at
> https://github.com/kugel-/geany/tree/splitwindow2?files=1
> 
> 
> Last commit is on November of former year? that's really slowly :/
> Anyway, has it been taken any *official* decision of moving on to a
> built-in feature instead of a plugin? On other words, Geany dev team, do
> you have plans of putting splitwindow into core and dropping it as plugin??

Short answer: yes.

Longer answer: I myself have low interest for the feature (read: I don't
use it, and probably wouldn't much), but the quality of the current
splitwindow plugin definitely leaves a lot to be desired.  However, we
all know and agreed that it's probably currently impossible to implement
a perfect "split window" feature as a plugin, so yes, it probably would
have to land in core anyway.  I would probably accept a version of this,
and could be reviewing it.  It however absolutely has to be
*non-intrusive* to the non-split case.

Also, IMO a replacement/large improvement should include the following
in the end:

1. Seamless integration (all features in all splits)
2. (keep) support for multiple views of the same document
3. multiple (arbitrary) splits

Point 1 is obvly the main goal of everyone who ever tried to improve the
situation.

Point 2 would IMO be important, especially to avoid changes in some
views when another changes (i.e. if I want to display document A in view
V, and I already have it in view W, I don't want view W to stop
displaying it).
On this point I'm on disagreement with others, who are happy with the
idea that documents are dispatched on the various areas, rather than
areas are views for documents; so your opinion might vary.  I also won't
strongly oppose either way, as again I probably wouldn't make much use
of the feature myself.

Point 3 would be great, but I guess less of a primary goal.


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

Re: [Geany-Devel] [Geany-Users] Geany-Plugins website down because of issue at sf

[Colomban Wendling]

Le 21/07/2015 23:18, Enrico Tröger a écrit :
 […]
 
 The website http://plugins.geany.org is back online again.
 
 We moved the site to our infrastructure.
 The plugin pages are fully back as well as the downloads for the latest
 release, 1.25. Only the downloads for some older releases are missing,

Superb!  You're the man, thanks :)

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

[Geany-Devel] [ANN] Geany 1.25 is out!

[Colomban Wendling]

After another long delay, we are finally happy to announce a new release
of Geany!

For a comprehensive list of changes please see:
http://www.geany.org/Documentation/ReleaseNotes

Some highlights:

* Fix spawning programs on Windows (for real this time!, Dimitar
  Zhekov).
* Use native Windows quoting rules for commands on Windows.
* Fix and improve MacOS X support (Jiří Techet).
* Show document-related dialogs embedded in the main window (info
  bars) (Matthew Brush and Thomas Martitz).
* Huge tag management performance improvement (auto-completion,
  calltips, etc.) (Jiří Techet).
* Update Scintilla to 3.5.6.
* GTK3 support, while not enabled by default, is now considered stable.
* Add support for single-line regular expressions.
* Add filetypes CoffeScript (Mark Dresselhaus), JSON, Zephir.
* Significantly improved filtypes CSS, Erlang (Beng Tan), Go (Jiří
  Techet), JavaScript, Make, PowerShell, Txt2tags.
* Update translations: be, ca, cs, de, el, es, fr, id, it, ja, nl, pl,
  pt_BR, pt, ru, sl, sr, sv, zh_CN.

We want to thank all developers, translators and everyone who
contributed to this release with patches, feedback, bug reports and so
on.  Thank you!

As usual, all downloads can be found on
http://www.geany.org/Download/Releases.  But this time you'll also find
a MacOS X DMG, thanks to Jiří Techet!

Additionally, to try and avoid another long delay before the next
version, we decided to try and embrace a time-based 4 months release
schedule.  If we can stick to it, next release should come out around
November 15.

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

Re: [Geany-Devel] Fwd: Re: Github loses comments

[Colomban Wendling]

Le 08/07/2015 05:19, Matthew Brush a écrit :
 […]
 
 So does that mean it's ok to make comments either on the main page of
 the pull request or the files changed view which shows the combined
 changes?

Depends what you mean ok, but yeah they shouldn't get lost.

The problem is that sometimes it's a lot handier to comment on a
specific commit's diff rather than the whole thing.

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

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

[Colomban Wendling]

Le 29/06/2015 10:24, Thomas Martitz a écrit :
 […]
 
 That helps only existing users, and only that fraction that actually
 reads release notes (I would think the bulk of them doesn't).
 
 Perhaps it would be indeed best to not toggle the default for this
 release already?

Makes sense to me, and in the next cycle we add some appropriate
feedback so the user can discover the feature.

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

Re: [Geany-Devel] [RFC]: No force push policy on Github PRs

[Colomban Wendling]

Le 07/07/2015 08:41, Thomas Martitz a écrit :
 [...]
 
 Am 07.07.2015 um 02:13 schrieb Matthew Brush:
 Hi All,

 As anyone trying to follow Pull Requests on Github has probably
 noticed, when you force push to your PR branch, Github deletes various
 comments related to the PR, depending on what got clobbered (it seems).
 
 Not always. I haven't found a consistent pattern, but it seems worse
 when commits are removed.

Just as your GH emails says, it's simply when people commented on a
*commit* that got removed from the PR by the rebase, no real mystery here.

The problem is that when the diff is relatively large it's a *lot*
easier sometimes to comment on the smaller commit-only changes than on
the whole set, so then it becomes annoying.
As it's like that, I'm trying more and more to comment only on the
overall diff, but it's sometimes just not handy either.

 This makes it extremely difficult to keep track of and finally merge
 PRs because issues that may have been raised are gone and it leaves
 holes in the comments which are a useful way to make sure any issues,
 notes, ideas, etc. have been dealt with before merging.

 In addition to the dropped comments, it makes it harder to follow the
 changes made since it clobbers the Git history too, so you have to
 basically review the entire changset by looking at the whole diff of
 all files affected by the PR at once.
 
 Well, assuming an updated PR only changes stuff which has  been
 commented on before or are otherwise explicitely noted in a new comment,
 you do not have to review the entire diff again. And you have to review
 those parts of the diff you commented on again, other parts should be
 fine since they received no comment at the first review, right?

No, you just cannot know what changed and what remained the same [1].
Of course the creator of the PR probably means well, but even then
sometimes small (or less small) mistakes get introduced by rebases (you
know it just as well as I do :), so it has to be reviewed again as a
whole.  Well, the whole always have to be reviewed at some point if we
ever rebase, but if it can be once in the end it's better.

[1] well, sometimes I pull the changes locally in versioned temp
branches so I can at least diff the various versions.

 So it boils down to lost comments are the main problem.
 

 Another reason to avoid is because it makes it harder to test a PR if
 the repos history keeps getting munged, it breaks your previous pulls.

 I propose that we disallow force pushing, rebasing, squashing, etc. on
 any PR until it is fully ready for final merging. We could probably
 use a label or milestone or something to signify that a PR has been
 fully reviewed and is ready for merging. At that point it _might_ make
 sense to fudge history and get rid of some noisy fixup commits[0].

 
 The more fixup commits the less likely that the post-review cleanup is
 actually going to happen. The largeish linkage-cleanup branch was almost
 merged as is, and I'm sure bisection of in the middle of those commits
 is harder or even impossible.

IMO that's not true.  You just need to be disciplined when you do your
fix commits and split them.  In such situation I generally create one
fixup commit per commit I to fix, and also insert the SHA1 of the commit
to fix in the fixup message so it's easy to track later.

 Thoughts, opinions?
 
 I prefer rebasing and rewriting commits, because that makes my life
 easier too. I can handle my stuff better if it has a clean history, and
 it helps me in making design decisions because I try to logically
 separate stuff in the commits.

Sure, but IMO here we're mostly talking about fixes that aren't complete
rewrites, so design decisions should be mostly dealt with.  And if they
aren't and aren't trivial, it might warrant a separate PR.

 And merging master into my PR when the PR
 should eventually be merged into master is not acceptable for, therefore
 I rebase.

Well, ok we have an history with you of letting your stuff rot for long
(sorry :-() so getting up-to-date with master is important, but in most
PRs that doesn't matter.


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

Re: [Geany-Devel] [RFC]: No force push policy on Github PRs

[Colomban Wendling]

Le 07/07/2015 02:13, Matthew Brush a écrit :
 Hi All,
 
 As anyone trying to follow Pull Requests on Github has probably
 noticed, when you force push to your PR branch, Github deletes
 various comments related to the PR, […]

Yeah, that annoyed the hell out of me more than a few times.

 This makes it extremely difficult to keep track of and finally merge
 PRs because issues that may have been raised are gone and it leaves
 holes in the comments which are a useful way to make sure any issues,
 notes, ideas, etc. have been dealt with before merging.

Yes.

 In addition to the dropped comments, it makes it harder to follow
 the changes made since it clobbers the Git history too, so you have
 to basically review the entire changset by looking at the whole diff
 of all files affected by the PR at once.

Also true.  For that part they could provide a diff between the previous
and current state, so at least we could see what changed.  But well,
it's not (yet) the case.

 Another reason to avoid is because it makes it harder to test a PR
 if the repos history keeps getting munged, it breaks your previous
 pulls.

Well, true but you can also just create versioned local branches -- so
you can even diff them.  I generally do that with largish stuff, like:

user/pr/v1
user/pr/v2
user/pr/v3

etc.  Of course it requires manual intervention, but it's not very hard.

 I propose that we disallow force pushing, rebasing, squashing, etc.
 on any PR until it is fully ready for final merging. […] ready for
 merging. At that point it _might_ make sense to fudge history and get
 rid of some noisy fixup commits[0].

Agreed, this should be the default behavior.  We should at least try and
see how life gets easier.

 Thoughts, opinions?
 
 If it sounds like a good idea, I could probably try and update any 
 relevant documentation (HACKING comes to mind) to make a note of
 this[1].
 
 Cheers, Matthew Brush
 
 [0]: I personally don't think it's a big deal leaving the history to 
 match real life, but I can see how Fix some typo type of commits 
 aren't very useful to keep around.

Well, IMO it doesn't make sense to keep endless fixup commits in the
final marge.  Not only it clobbers history, but it also makes it a lot
harder to bisect.

Of course, this applies to *fixups*, not incremental development.  If
changes were made incrementally in the PR it probably makes sense (or
may not, depending on the case) to keep the incremental history too.

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

Re: [Geany-Devel] Questions about bugs/features trackers

[Colomban Wendling]

Hi,

Le 03/07/2015 23:48, Minh Bui a écrit :
 Hello, I'm a student who wants to contribute to Geany. I've read the
 HACKING file and surf through the bug/features tracking list.

Great :)

 There are several questions I would like to ask:
 
 1. What are the open tickets? Are they issues that people have
 proposed and haven't been picked up by the development team?

Open is the default state on SF, so it can mean that
* Nobody really looked at the ticket
* Someone looked, found it sensible but didn't do anything else

So yeah basically it's what you guessed.

 If the answer to the question above is yes then:
 Are the open-accepted tickets are tickets that the development team
 has accepted to work on?

Basically, it means okay, we confirm/agree this is an issue/feature to
have.

 2. Why do we have to use 2 different tracking systems? I noticed that
 the issues tracking on Github and the one on SourceForge do not match
 with others. Which is the most active recent tracking system?

Basically, we're (slowly) moving to GitHub.

 4. Assuming my assumption for the first question is correct, I would
 like to work on this: http://sourceforge.net/p/geany/bugs/1026/. But I'm
 in doubt because I don't know if someone has already working on this.

Nobody that I know of, so please, go ahead :)

BTW, this is a good example of open-accepted, Lex just said you're
right that's a bug we need to fix, but didn't do anything further (yet).
Though, we are pretty bad at managing our bug tracker, so I wouldn't be
surprised there are open tickets that we forgot to close (probably
because we fixed the issue separately), or await for a long time :(

Regards,
Colomban


PS: there's no item 3, is it?
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] Don't panic -- There have been a force update on geany-plugins master!

[Colomban Wendling]

Le 26/06/2015 19:34, Frank Lanitz a écrit :
 Hi folks,
 
 I need to apologize! Due to chunky fingers I accidentally forced-push an
 old head to geany-plugins master repo. Colomban was able to recover the
 old state (inkl. same sha) but your client might, depending on when you
 have cloned/pull the repo, complain that there is something suspicions.
 So don't panic! Everything under control.

And it's my turn to apologize, as it turns out I committed some things
in Frank's name…
I tempered with authoring info on my side when trying to mimic a missing
commit (it didn't work, though), and forgot to undo this.

I'm actually the one to blame for these recent commits on geany-plugins:

*
https://github.com/geany/geany-plugins/commit/b318bfdd85e7877130c8350facbf23eb91e588c0
*
https://github.com/geany/geany-plugins/commit/c71623b4d4d286fcc44e6d86c270cfaa52f36221
*
https://github.com/geany/geany-plugins/commit/2322d669f764ca1f958893ed60fc9232cf2eadd7

Sorry again for having stole your identity Frank.

Regards,
Colomban



signature.asc
Description: OpenPGP digital signature
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

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

[Colomban Wendling]

Le 26/06/2015 07:22, Thomas Martitz a écrit :
 […]
 
 However, as we entered string freeze, I don't suppose a new dialog like
 this is acceptable at this point?

It would be really better not to indeed?

 What else can we do for *this* release?

Hum.  If this is an important enough issue, I can see these solutions:

- Default to not keep history (hence prompt);

- Add an extra hidden setting don't show this message again-like for a
*future* dialog/infobar, so it still always asks unless the user
manually changes this hidden setting.

Both are suboptimal for this feature, but if it's a problem we can
probably delay default enabling to the next cycle.

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

Re: [Geany-Devel] Spawn module API

[Colomban Wendling]

Le 24/06/2015 00:18, Matthew Brush a écrit :
 […]
 
 I think the general policy is to export stuff on demand as plugins need
 it. Seeing as you wrote the API in question, I'm assuming you know best
 the stuff you will need, so I don't personally see much problem
 preemptively exposing that stuff[0].
 
 From you're previous email you mentioned the stuff checked with [x] below:
 
 [ ] spawn_get_program_name()
 [ ] spawn_check_command()
 [x] spawn_kill_process()
 [ ] spawn_async_with_pipes()
 [ ] spawn_async()
 [x] spawn_with_callbacks()
 [x] spawn_write_data()
 [ ] spawn_get_exit_status()
 [ ] spawn_sync()
 
 [x] SpawnFlags
 [x] SpawnReadFunc
 [x] SpawnWriteData

Seems to make sense, only spawn_write_data() doesn't strike me as
totally required, but I understand.
TLDR version below.

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

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

spawn_async_with_pipes() can be nice, but most people probably shouldn't
use them as they have same IO trickery most IO layers have, where you
have to take care of not filling up any pipes (write) or forget to empty
them (read).  The only real difference wit g_spawn_async*() is that it
uses native API on Windows (which indeed solves some issues so is
useful, but that's not my point).
Inside Geany, we can rely on the GLib main loop to be running so anyone
can use the handier spawn_with_callbacks().

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

spawn_async() doesn't seem so much useful to me, as it doesn't (seem) to
have so much advantages over g_spawn_async(), which works okay (as there
is no pipes involved).  Also, it's a thin wrapper around
spawn_async_with_pipes().  I don't know about speed or anything though.

spawn_sync() is nice because it allows to easily pipe through a process
(send some data to stdin and and read the output).  How often is this
useful for everyone I don't know -- but any plugin wanting to call a
filter command might benefit from it.  Also, it's not that hard to
reproduce using spawn_with_callbacks() as that one has SPAWN_SYNC, so
only the communication callbacks have to be implemented.

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

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

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

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

   We should make Colomban decide :)

 The leading developers should decide - including you.

 
 Well you know my opinion :) I think everyone pretty much agrees we
 shouldn't expose stuff unrelated to the plugin API, and I think we all
 also agree it's stupid for plugins to have to copypaste code that
 exists already or else use an inferior version. I also think everyone
 agrees that a separate utility library would be a good idea.

I'm everyone and all :)

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

Re: [Geany-Devel] Spawn module API

[Colomban Wendling]

Le 24/06/2015 01:57, Lex Trotman a écrit :
 Colomban,
 
 Correct me if I'm wrong, but despite my loudly voiced misgivings :)
 doesn't the spawn_* series do command quoting and g_spawn* not?
 
 If that the case they should not be mixed on the same platform
 otherwise the user has to know which commands are run with which
 function to know if they need to do the quoting themselves.

Well, those support an additional command parameter that indeed is
read in a platform-dependent manner.  (this was a discussion point and
ended like this).

They however also support argvs just fine, so you can use those too and
they would work the same.  With this, you can also imagine using
g_shell_parse_argv() on all platforms if you like, just like you would
do with g_spawn().

So well, yes, the user has to know which syntax is needed, but that's
basically true already.

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

[Geany-Devel] ANN: Geany 1.25 release schedule

[Colomban Wendling]

Hi everyone!

We finally planned the release of Geany 1.25!  This release will include
a lot of enhancements, including:

* Improved MacOS X support (Jiří Techet).
* Improved subprocess spawning, especially on Windows (Dimitar Zhekov).
* Huge tag management performance improvement (Jiří Techet).
* Show document-related dialogs embedded in the main window (info
  bars) (Matthew Brush  Thomas Martitz).
* Improved plugin manager dialog.
* Scintilla 3.5.6, including many highlighting fixes and improvements.
* More robust plugin API (Jiří Techet, Matthew Brush  Thomas Martitz).
* And many more!  See http://git.geany.org/geany/tree/NEWS

Here is the schedule:

Fri. 2015-06-19 (evening)
String freeze (no more changes affecting translations)
Frank will post an additional announcement.
Sat. 2015-07-04
Feature freeze (only bugfixes)
Sun. 2015-07-12
Release!

In addition to the release, we decided to try and make time-based
releases every 4 months or so, to release more often and (among other
things) avoid 1+ year cycles like it was the case for 1.24 and 1.25.

As a result, 1.26 will be due around 2015-11-15.

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

Re: [Geany-Devel] Profiling Geany with gperftools

[Colomban Wendling]

Le 19/06/2015 15:05, Jiří Techet a écrit :
 Hi,
 
 as the ctags guys were interested how I profiled some performance issue
 in the Python parser, I thought it would be a good idea to write a wiki
 page about it because the outputs are very useful for locating various
 performance issues. I put it here:
 
 https://wiki.geany.org/howtos/profiling/gperftools
 
 Comments/suggestions are welcome.

First reaction: awesome, thanks!

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

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

[Colomban Wendling]

Le 14/06/2015 17:16, Thomas Martitz a écrit :
 […]
 - copy geany.gtkrc to geany-1.25/data (doesn't seem to be installed
 automatically)

geany.gtkrc is not installed on GTK3 builds because it's a GTK2-only
thing.  The GTK3 version is geany.css.

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

Re: [Geany-Devel] Autotools and Waf options (Was: Re: Msys2 to compile on win32)

[Colomban Wendling]

Le 06/06/2015 14:57, Colomban Wendling a écrit :
 […]
 
 And we could probably relatively easily add a flag similar you the
 current Waf's `--enable-plugins` -- this was mentioned yesterday on IRC,
 we could try and add e.g. --disable-all so to build a single plugin it
 could be --disable-all --enable-this-one, but we could probably also
 have the --enable-plugins=list semantic.

Proposed implementation: https://github.com/geany/geany-plugins/pull/236

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

[Geany-Devel] Autotools and Waf options (Was: Re: Msys2 to compile on win32)

[Colomban Wendling]

Le 06/06/2015 13:07, Dimitar Zhekov a écrit :
 […]
 
 I'm using waf under Linux as well, since it keeps the source tree clean,

You can do the same with Autotools, though it admittedly doesn't enforce
it.  Just run configure from the directory you want the build files in, e.g:

$ mkdir _build
$ cd _build
$ ../configure [options]

 and allows compiling only selected plugins without a super-long list of
 --disable-plugin-s.

With Autotools you can indeed not (yet) easily only configure a specific
plugin, but you can very easily only build one, by running Make inside
the plugin's subdirectory (e.g. `make -C theplugin`).

And we could probably relatively easily add a flag similar you the
current Waf's `--enable-plugins` -- this was mentioned yesterday on IRC,
we could try and add e.g. --disable-all so to build a single plugin it
could be --disable-all --enable-this-one, but we could probably also
have the --enable-plugins=list semantic.

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

Re: [Geany-Devel] pull request on GitHub, to add GeanyHighlightSelectedWords, into Geany Plugins

[Colomban Wendling]

Le 01/06/2015 15:48, Steven Blatnick a écrit :
 […]

 Odd, I don't see this reply from Marius in my inbox.  Was this in
 private separately?

No, it was sent to the mailing list just like the rest…  maybe a spam
filter got confused?

 […]

 BTW, @Steven: search_find_text() is *NOT* part of the Geany plugin API
 and never have been.  The fact you can use it is a issue of the way
 Geany API was exported, and it is fixed in the dev version (meaning it
 won't work anymore).  Not also that this never worked on Windows.

 Thanks for the information.  I wonder if any of my other plugins include
 non-API calls.  Is there an easy way to tell what is allowed and what
 shouldn't be?

Anything not in the API documentation shouldn't be used.  And as said
the current Geany development version (1.25) has this fixed so you
plugin shouldn't load anymore if it uses something it shouldn't.

 Is there a reason we don't allow plugins to tie into
 anything when they could besides trying to stop plugins from being
 overtly complicated or breaking things?

The reason is that we don't want to break the API every few minutes, so
this means it has to be defined.  This can't reasonably include every
function in Geany, as it would basically mean we can't change anything
inside Geany without potentially breaking plugins.

So we choose what to render public (based on needs basically), and we
then commit to maintain this API (to a reasonable extent, at least,
meaning we will only change it if there is an important reason to).

To use the example of search_find_text() as how non-API things can
change, this function actually changed in the 1.24 cycle [1] to fix a
real problem.

All this said, if you need a function that isn't part of the API, ask
(or make a PR!) and we'll probably be happy to add it if it makes sense.

Regards,
Colomban

[1]
http://git.geany.org/geany/commit/?id=5412a244ba903624053cdaf7393732bc3af689ea
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] pull request on GitHub, to add GeanyHighlightSelectedWords, into Geany Plugins

[Colomban Wendling]

Le 29/05/2015 02:38, Lex Trotman a écrit :
 […]

 That being said, showing occurrences of the word is such a common and fairly
 useful feature for an IDE, I'd personally rather see the 3-4 existing
 plugins obsoleted by a good implementation in core Geany[1].
 
 +1
 
 Gotta agree, this is so common (even browsers do it) that it should be
 an easily found built-in feature, but maybe that just means moving the
 Menu-Search-more-mark all menu item?

Apparently it's not the search results highlighting they are talking
about, but dynamic highlight of the current word (which to me is the
same as search result highlighting searching for the word under cursor,
but who knows if there's a subtler thing behind it) -- and I don't know
any browser doing that (nor, for that matter, any application).

 Improving the implementation is also good of course.

It depends on what improving means.  I have to go with Jiří on that
one, this should not be over-engineered unless there is a problem to
solve, and the added complexity does solve it.  This probably can be
something like a 30-60 line feature (in C!), so please don't make it a
2k line one unless it makes me coffee in the morning :]

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

Re: [Geany-Devel] pull request on GitHub, to add GeanyHighlightSelectedWords, into Geany Plugins

[Colomban Wendling]

Hey,

Le 30/05/2015 01:45, Matthew Brush a écrit :
 […]
 
 I was thinking something like this for implementation:
 
 - Have a preference to enable the feature (since it would now be
 automatic). Have the preference turned off by default. Put the
 preference in Preferences-Editor-Display as a checkbox called
 Highlight current word or similar. Or would it be better under
 Preferences-Editor-Features?
 
 - Use a different indicator number than the current Mark All feature,
 so it won't clash with the one used for the Search dialog and can have
 different styling.
 
 - Remove the Mark All keybinding. Also make these new indicator types
 not cleared by the Document-Remove Markers menu item.

As said on IRC, I probably would rather combine the two feature (current
mark all [shift-ctrl+m] and this dynamic version of it).

E.g, have a setting in the preferences Dynamically mark the current
word that decides whether mark all is dynamic or not, and have
shift+ctrl+m toggle the marking, whether it's dynamic or not.

on_toggle_mark() {
if ((dynamic  active) || (!dynamic  current_char_is_marked())
clear_markers();
else
mark_all();
active = dynamic  !active;
}

on_caret_moved() {
/* if enabled and current word is not already marked */
if (dynamic  active  !current_char_is_marked()) {
clear_markers();
mark_all();
}
}

 […]
 
 - If there is a current word and it's different from the last one, clear
 the indicators and then have Scintilla close its gap buffer by getting
 the character pointer to it.
 
 - Use strstr() starting at the character pointer to the buffer start,
 comparing the bytes with the bytes of the current word, working its way
 through the whole document.
 
 - For each non-NULL return of strstr(), set an indicator at position
 `foundPtr - docStartPtr` with the indicator length as the number of
 bytes in the current word, and then use strstr() again starting at
 `foundPtr + currentWordLength`, repeat to end.

Why not use the basic Scintilla search features?  It should be fast and
do just what you want just as easily -- and look like it's the expected
way you do it, which may even not need closing the gave or something.

 Does that sound fairly reasonable?
 
 The only thing I'm not 100% sure about is handling of multi-byte
 characters in the UTF-8 of the wordchars or the buffer, but it seems
 like it should just work since it's just comparing raw bytes, and at
 worst, setting a indicator position in Scintilla that is between two
 bytes of the same multi-byte char (but not moving the caret there, so no
 weird editing bugs).

you shouldn't have to worry about that.  we already have a way to get
the word under cursor, so just use that and don't worry about how it's
done (we can always fix it if it doesn't get it right, but it seem to be
good enough as nobody complained).

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

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

[Colomban Wendling]

Le 19/04/2015 17:31, Colomban Wendling a écrit :
 […]
 
 I'll open an issue on Scintilla and see what Neil thinks, whether he'd
 accept a hack like that dummy field -- or maybe if he has a better
 understanding of ABI issues on Windows (but I'm afraid here there really
 is an ABI incompatibility and we're screwed on that front).

Reported (https://sourceforge.net/p/scintilla/bugs/1726/), accepted
(https://sourceforge.net/p/scintilla/code/ci/e9f9c964236a6b740f75d09a8b0ac76e5d6dd09f),
and imported
(https://github.com/geany/geany/commit/9b98d55defc918c951660f05e9ebdd30e9bfb184),
yay!

Thanks a lot Enrico for helping debugging this!

Cheers,
Colomban



signature.asc
Description: OpenPGP digital signature
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] C# tags for Unity 5

[Colomban Wendling]

Hi,

Le 21/05/2015 15:05, Deep Thought a écrit :
 Hi! I'm a general programmer/CS student who likes to use Geany for
 everything textual. I got around to installing the Unity 5 Editor a few
 days ago but was disappointed to find that its scripting workflow mainly
 went through MonoDevelop, so I switched that to Geany in the preferences.
 
 Unfortunately, this meant I lost all of the built-in autocomplete and
 hinting features, so I spent a few hours constructing building a .tags
 file for the Unity 5 Scripting API for Geany. You can find it here:
 https://github.com/DThought/unity-tags
 
 I thought I'd share it in case other people found it useful and could be
 added to http://www.geany.org/download/extras#tags.

Great!  what about adding it to the wiki? http://wiki.geany.org/tags/start

 By the way, I thought I'd mention that
 http://www.geany.org/download/extras#colors seems severely outdated,
 considering there's a completely new theming system in Geany
 (https://github.com/codebrainz/geany-themes/tree/master/colorschemes).

Indeed.  I'll fix that.

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

Re: [Geany-Devel] GeanyLua compatiblity with Lua 5.2

[Colomban Wendling]

Le 24/04/2015 23:31, Dominic Hopf a écrit :
 Hi guys,
 
 I've noticed the GeanyLua plugin does not build with Lua versions
 greater than 5.2. I've stumbled over this since I updated to the
 current version of Fedora 22 Beta which is with Lua 5.3.0 already.
 
 Is someone able to fix the issues and make the plugin compatible with
 Lua versions greater than 5.2? Otherwise it will be quite a pity since
 I would have to disable the plugin in the Geany Plugins Fedora package
 then.

IIRC I quickly tried and saw the API change in some non-obvious manner,
meaning one willing to fix it would probably need reasonable knowledge
of the Lua API, or at least being willing to learn some of it.  And I'm
afraid we ain't got no one like that currently.

BTW, the plugin is lacking a maintainer for quite some time now
(probably like 5 years), so I do not expect it to last forever unless
someone is willing to step up for it.  We did the bare housekeeping on
it as much as we could, but that's all.

So yeah, if anyone wishing to keep on using this plugin should consider
helping maintaining it, it really needs some love from time to time.

Regards,
Colomban



signature.asc
Description: OpenPGP digital signature
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

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

[Colomban Wendling]

Le 19/04/2015 15:57, Enrico Tröger a écrit :
 On 17/04/15 19:44, Colomban Wendling wrote:
 Le 15/04/2015 15:27, Colomban Wendling a écrit :
 […]

 So we'll have to fix the Windows build issue in some way…
 
 I gave it another look, however I sort of give up :(.
 
 What I know is, with gcc 3.4 the popups work cleanly and as expected,
 even when compiled natively on Windows. This is why the nightly builds
 work, they are built with an old gcc 3.4.
 
 Then I tried gcc 4.8 and gcc 4.6 on Windows, both are failing.
 […]
 
 This might support the above supposition about binary incompatibilities
 with the GTK libs. But maybe it is something completely different.

Thanks a lot for that in-depth investigation and testing!

But… dammit.  If this is really an ABI issue depending on the GCC
version, we don't have so many solutions:

1) build Geany using the same GCC as GTK was build;

2) use a GTK that is built with the same GCC as GTK (would mean
rebuilding GTK I guess);

3) avoid hitting the ABI issue by not relying on the size of the
structure (would mean not subclassing, but then I don't really have a
solution);

4) avoid hitting the ABI issue by adding dummy padding (as we don't
actually access any data ourselves it doesn't matter).

None of those solutions are really great… 1 is not really practical, and
2 is just a dream.  I don't have a good way of doing 3.  4 is a bit ugly
but quite easy to implement.

 While the
 typedef struct { GtkScrolledWindow parent; int dummy; } SmallScroller;
 typedef struct { GtkScrolledWindowClass parent; int dummy; } SmallS...

 hack works pretty fine, it is still a crude hack and feels weird to send
 this to Scintilla upstream.

At worse we can always add it to our Scintilla patch…

I'll open an issue on Scintilla and see what Neil thinks, whether he'd
accept a hack like that dummy field -- or maybe if he has a better
understanding of ABI issues on Windows (but I'm afraid here there really
is an ABI incompatibility and we're screwed on that front).

 The other way, to stick with gcc 3.4.x for Windows, seems also quite
 ridiculous :(.

Indeed.  And the mingw package for GCC3 even conflicts with the 4.x one :(

Regards,
Colomban



signature.asc
Description: OpenPGP digital signature
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

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

[Colomban Wendling]

Le 16/04/2015 19:15, Dimitar Zhekov a écrit :
 On 16.4.2015 г. 14:41, Colomban Wendling wrote:
 Le 15/04/2015 19:15, Dimitar Zhekov a écrit :
 That's exactly what I'm talking about. The white horizontal line, which
 normally gives nice outline [vertical_tabs], but is almost lost [...]
 the white editor background, combined with the identical unchangeable
 background for the tabs. Not completely indistinguishable, but much
 worse than 2.22, and hard on many tabs.

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

It's 2.24.10 from the official bundle, and it uses the native engine.
 Normally you activate it by setting

gtk-theme-name = MS-Windows

in etc/gtk-2.0/gtkrc, as stated in the bundle's readme.  But for some
reason I didn't even had to do that on Windows 7.

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

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

However, using Raleigh (the one you seem to use given the look) it's
relatively easy (well, not to guess what to change, but to change it).
Here's an example changing the *inactive* tabs (because changing the
active's background also changes the border around the tab's content and
I didn't like it):

style notebook {
bg[ACTIVE] = #
}
style notebook-label {
fg[ACTIVE] = #
}
widget *.GtkNotebook style notebook
widget *.GtkNotebook.*GtkLabel style notebook-label

(not very well tested, might override too much)

Attached screenshot shows the (ugly) result.

 Wouldn't this address your issue? (even better than avoiding using GTK
 2.24 altogether) Or do you have another problem with the integrated
 theme?
 
 The problem is, it doesn't look much different than the Enrico's
 example, no matter the theme, though I have not tested extensively under
 7even.

Hum, to my eyes on my capture it looks quite different…  and attached is
the same on XP, still using the MS-Windows theme.

 Well, if XP is the problem, I wonder how it'll look under 10? I
 plan it as my next Windows version.

XP is not the problem, it works just the same.  Of course the
MS-Windows theme looks different as it tried to feel native and the
Windows themes are different, but that's all.

 […]

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

If you like it, sure, but it sounds a bit heavy for something that
should be solvable with a theme :)

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

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

[Colomban Wendling]

Hi,

Le 14/04/2015 21:54, Enrico Tröger a écrit :
 […]
 
 Windows 7 with GTK 2.24.10.
 Nick has the same problem, we talked about this in
 http://lists.geany.org/devel/2015-January/009257.html.

Dammit, I knew I saw this recently on a thread, but apparently I can't
search my emails :)  thanks for the link.

 Your patch works for me. I personally would not mind the minimal size
 increase. I completely agree it's better than an empty popup :).

BTW, I think I found a way to avoid the oversize without subclassing
GtkScrolledWindow, which might even be a better fix for the original issue.

 What bothers me more is that for some reason this problem doesn't occur
 with the cross-compiled nightly binaries.
 This is what we noticed in the above mentioned thread already, I just
 re-tested it to get sure.
 Though I have not yet an idea what could cause the different behaviour
 by the different builds :(.

Interesting.  It doesn't surprise me much, as my patch should not fix
anything actually -- it doesn't even make sense.  I just ended up seeing
this change fixed the issue, but I have no clue why it would…

So I guess it's some kind of memory corruption or something, due to
either a bug in Geany, Scintilla or GTK, or in mingw itself…  I'll try
and see if I can track the issue down, but without Valgrind I'm afraid
I'll have a hard time…

Anyway, thanks a lot for the infos, it'll probably avoid me heading in
the wrong direction :)

Regards,
Colomban



signature.asc
Description: OpenPGP digital signature
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

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

[Colomban Wendling]

Le 12/04/2015 19:20, Dimitar Zhekov a écrit :
 On 10.4.2015 г. 18:36, Colomban Wendling wrote:
 
 waf: Fix the checks for openpty() on FreeBSD
 
 ACK. Please, be sure to use the same check for debugger, it probably
 needs it.

The same commits should already have altered both Scope and Debugger to
use the same checks.

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

Re: [Geany-Devel] New plugin loader mechanisms

[Colomban Wendling]

Hi,

Le 30/03/2015 08:52, Thomas Martitz a écrit :
 […]

 ```
 struct MyRealPlugin {
   RealPlugin parent; /* offset 0 has the Geany struct, so it's binary
 compatible */
 /* plugin-specific fields here */
 int the_game;
 };
 ```
 
 Now this is a big methodology change, from Geany-allocated plugin
 handles to plugin-allocated plugin handles. This change has so many
 implications and touches so many things that I really don't want to do
 it. And given we want to maintain compatiblity to old plugins we have to
 support both at the same time.
 
 
 My new loader is much less invasive, *by design*. It only changes the
 way the already known hooks are registered and called (but still being
 transparent to the plugin), in order to provide a solution to the
 problems I outlined in the initial mail. And it provides binary
 compatibility to older plugins at very little extra complexity.
 
 I am mostly happy with how we load plugins, with my new loader I am
 completely happy, so I don't feel the big change you propose is
 justified. I don't do all of this for the sake of change, I want to
 provide an effective solution, and the fundament for proxy plugins. I
 don't want to change all the way we interact with plugins, which will
 also require plugin developers to re-learn.
 
 This is by far not the primary reason, but I also try to keep the
 changes less invasive to actually improve the chance of it being
 reviewed and merged in a reasonable time frame.

OK, this explanation makes me feel better with your proposal :)

What concerned me mostly was that you were proposing a new API, but I
felt it being riddled with relics from the past -- e.g. instead of
designing the new thing to be great on its own, you made it to be the
same as the old one, just getting rid of the most obvious shortcomings.

And I didn't feel very comfortable with this, because I felt like we'd
then probably want to rewrite it again in the (near) future, which would
mean breakage or introducing a third API.  Basically I feel that if a
new thing was introduced, it should be done right, and the complexity of
keeping compatibility should be a minor concern.

However, with some of the reasoning above (and below), I feel more
confident it is not only choices made for facility, so that's a bit of a
relief :)

And I must admit that indeed low change impact is unfortunately a
factor… Scotty, we need more (man) power! :)

 […]

 With your new proposal that gets rid of set_info() the how does a
 proxied plugin give its info (mostly) moot, but there still is the
 question why having separate argument holding pointless stuff
 (GeanyPlugin) while all could be packed in a new and better structure.
 
 GeanyPlugin is Geany's *handle* to the plugin and required to call lots
 of our API functions. With no global pointer being set in the plugin we
 have to provide the pointer to the plugin code through function arguments.

Good point.  Though in my new thing idea the plugin-provided self would
have been the new handle, but it's true that it'd require API changes.

 E.g. my point could maybe be summarized with why split things up while
 they actually represent the same thing?.

 And BTW, remember that we need the (translated) plugin infos in all
 cases, so it should be no difference giving it straight ahead -- even
 proxied plugins.
 
 I don't understand this part. What's the implications of translated
 plugin info? I think it only needs GeanyData to be available?

This last sentence is partly a leftover from when you still had a
set_info() plugin vfunc, so you can mostly forget it.  The only real
point I tried to make was that we need the plugin info no matter what,
so we could (should) give it when registering the plugin, not after.
But you addressed that now, so this point is moot :)

 […] Additionally the existing
 PluginCallbacks pointer registered here for all plugins that want
 statically defined signal handlers.
 I'm really not sure if we should bother keeping this.  Is there any
 benefit over plugin_signal_connect()?
 
 But what's the problem with PluginCallback? It's a convenient and useful
 feature to allow signal connections to be statically defined. The cost
 to support is really tiny, and it's not like we deprecated this API
 aspect so I don't see removing it is justified. Removing things from the
 API still requires some considerations.

I was suggesting this consideration :)
I never saw much use for it, but if people prefer this way of setting
handlers, well, why not.  Just remember this can *only* connect to
Geany's own signals, none else.

 […]
 Why return gboolean?  is this just meant to allow geany to say the
 current incompatible plugin, pleas rebuild?
 If so, shouldn't this rather be a result of a failing
 geany_plugin_register()?

 I don't get why geany_load_module() should fail, IIUC it should just not
 call geany_plugin_register() if it can't work, shouldn't it?
 
 It could be done this way too, indeed. Actually I don't use the 

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

[Colomban Wendling]

Hi,

To offload the discussion from PR#441 [1] from this partly off-topic
discussion and give it more visibility, I'm moving it here to the ML.
There already was a thread on the subject that got mostly forgotten, see
[2].

I apologize for the long and complex email, but I don't know how to
present that in a more concise way without losing important information
or clarity.

Note:  I will use *NIX-style command lines as examples.  The ones for
Windows are slightly different, but the problematic is basically the
same (though we don't use the shell there so it's a bit simpler).


1. So, what are we talking about?

Some of our commands can contain placeholders.  The most important ones
are the build commands, but also e.g. the terminal tool has '%c'.  These
placeholders are replaced by Geany with various things, like file names,
paths, line numbers etc.
Some of the commands are executed by a shell (build commands) and some
aren't (terminal command).


2. What is the problem?

The replacement for these placeholders can be anything, so they might
contain characters that have a meaning in a command.  The most obvious
example is quotes: imagine a file named `foo bar.c`.  If we just
replace the placeholder with the raw value (as we currently do) in a
build command, e.g. `gcc -c -o %e.o %f`, it gives this:

gcc -c -o foo bar.o foo bar.c

which is obviously incorrect (see [1] or [2] if it's not obvious for you ;)
We need to escape (or quote) replacements in some way or another.


3. So, how can we fix this?

Several solutions have been suggested (well, actually 3.5 is new!), each
with pros and cons:


3.1. Insert quoted replacement as needed where they appear

This is what I first implemented: track the quotes in the user command,
close them before inserting a quoted/escaped replacement, and reopen it
right after.  With the above command, it would give this:

gcc -c -o 'foo bar'.o 'foo bar.c'

which is valid and as we want it (again, see [1] and [2] if it's not
clear that it's valid).

This is what the patch at [3] (and [2], but the version there is
outdated) does.

3.1.1. Pros

* compatible with any current user commands (no breakage of the user
configuration, and fixes replacement in them);
* the user doesn't have to worry about the issue.

3.1.2. Cons

* requires understanding of the shell quoting rules (including sub-shell
like `` and $()), which might be non-trivial.
* if it gets something wrong, the users are mostly screwed (the only
thing they could do would be try to adapt the command in a way for Geany
to get it right)


3.2. Insert quoted replacements everywhere blindly

Replace blindly each placeholder with an escaped/quoted version of
itself.  This is like 3.1 but doesn't try to manage quotes in the input
command.  It would give:

gcc -c -o 'foo bar'.o 'foo bar.c'

(which is incorrect, see the cons below)

3.2.1. Pros

* easy to implement;
* simple, the user can easily know exactly what happens.

3.2.2. Cons:

* Incompatible with (some) current user commands: as the placeholder is
replaced without care, the placeholders need to appear outside other
quotes.  E.g. the above example would have to be altered to remove
quoting around the %f placeholder not to be quoted twice: `gcc -c -o
%e.o %f`.


3.3. Provide format modifier performing specific quoting

Dimitar suggested introducing format modifiers like %f or %'f that
would quote in various ways (see
https://github.com/geany/geany/pull/441#issuecomment-87272057).

3.3.1. Pros

* The users can quote in various ways as they see fit;
* Explicit control on how things are quoted/escaped;
* Could support recursive quoting (quoting twice or even more), so Lex
could use it in a `python -c` or similar called by the shell ;)  e.g.
`python -c print(%\f.replace(' ', '_'))` could end up in `python -c
print(foo\ \\\bar.c.replace(' ', '_'))` -- assuming we implement
the escaping Python requires.  happy? :)

3.3.2. Cons

* it doesn't fix existing user commands (needs to make use of the new
format modifiers);
* requires to implement various kind of quoting (which requires knowing
several shell escaping rules);
* complex and uncommon format modifiers (the users have to pick the
right one, which might not be obvious);
* the users can screw themselves up if they don't use the appropriate
format (could work with some replacement but not others).


3.4. Parse command as an argument vector and replace in each argument

Instead of working on the command itself, use g_shell_parse_argv() and
perform replacements in argv[1:] (each argument separately).

3.4.1. Pros

* no need for quoting or escaping the replacement (as each argument is
done on its own).

3.4.2. Cons

* doesn't work with shell constructs, so it's not a solution for build
commands (as an argv is an argv, which can't support sub-shell, piping
and whatnot).


3.5.  Use environment variables, not placeholders

Change the whole logic and use the environment to pass what currently
uses placeholders.  

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

[Colomban Wendling]

Le 30/03/2015 21:59, Thomas Martitz a écrit :
 […]
 Is this a real problem (reported by someone) or just theoretical?

Mostly theoretical, although we got a supposedly security-related mail
about that issue (ref https://bugs.gentoo.org/show_bug.cgi?id=446986)

 […] After all, somone naming his files `foo
 bar.c` should expect to shoot himself in the foot.

Agreed, but some people keep playing with guns and complain when they
hurt themselves :)

So, well, yes to some extent it's an imaginary problem I agree, but the
code does have a problem and it stares back at me each time I pass
through build.c :)
But no, it's not an issue everyone keep complaining about.

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

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

[Colomban Wendling]

Le 31/03/2015 02:10, Lex Trotman a écrit :
 […]
 
 Perhaps we should be more explicit in the manual that on *ix build
 commands are run in the shell and the user is responsible for either
 quoting the substitutions correctly, […]

The user currently *cannot* do it correctly so it works with any
possible replacement, that's actually the problem :]
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] New plugin loader mechanisms

[Colomban Wendling]

Hi,

Le 18/03/2015 18:11, Steven Blatnick a écrit :
 
 On 03/18/2015 10:42 AM, Thomas Martitz wrote:
 Currently geany exports a pointer to a struct, that contains more
 structs, which contain function points to the API functions.
 Fortunately this is nicely hidden to developers via macros. But due to
 gtkbuilder all functions and nothing prevents plugins from accessing
 these. And the macros are awkward and strange anyway. There is
 currently the linkage-cleanup PR in the works which improves this by
 actually exporting the API functions, and _only_ the API functions to
 plugins. 
 Maybe I'm completely wrong on this from an architecture perspective, but
 part of what I like about writing plugins for geany is accessibility. 
 If we only get access to a subset of functions, then it seems less
 flexible what our plugins can actually do.  Yes, this allows us to write
 bad plugins that can do some sloppy things, but I say so what.  They
 are plugins.  […]

In addition to what Thomas said (which is very true), realize two things:

1) plugins that use functions not part of the API won't work e.g. on
Windows (for technical reasons, all functions are currently actually
usable under *NIX, but on Windows only explicitly exported ones are).
So if you care about your plugin working on Windows you'll stick to the
official API anyway (the one we commit to and maintain).

2) before Geany 1.22, you couldn't use non-API anyway.  If you were
happy with the API before, you'll still be after this change.

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

Re: [Geany-Devel] New plugin loader mechanisms

[Colomban Wendling]

Le 26/03/2015 00:16, Thomas Martitz a écrit :
 Am 20.03.2015 um 19:45 schrieb Dimitar Zhekov:


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

 There seem like two different things to me.

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

 Now, do we really want the plugins to run arbitrary resource checking
 code, and display their own error messages, only because they are
 queried (or registered, as you put it), each time the list is build?
 
 They [incompatible plugins and plugins that are unable to function due
 to missing runtime deps] are different things, but the resulting action
 should be the same (hide it from the PM dialog, possibly give the user a
 hint). Hiding from the PM dialog should IMO be done before it even
 showed up, to avoid creating expectations that cannot be met and
 negative user surprise.
 
 Yes plugins should be able to run arbitrary checking code because that's
 necessary for proxy plugins. Whether Geany can provide APIs to report
 results to a the user in a consistent manner is on another piece of
 paper, one that's IMO slightly out of scope for my proposal.
 
 I'm thinking if the plugin loaded successfully, then it should be
 operational too.

 I can check if scope.glade exists, but is it valid XML, compatible
 with the current version of gtk_builder? The only way to be 100% sure
 is to actually load it. And them immediately unload it, because Scope
 is being queried only, not activated. And then load it again on init...
 
 My opinion is that if the XML isn't compatible to the current GtkBuilder
 version then scope shouldn't even show up in the PM dialog, because
 there is no way it can be functional. This is not fundamentally
 different to a plugin being incompatible to Geany's ABI version. So yes,
 that implies validating the XML in geany_plugin_register() (although
 loading seems excessive to me, because the XML should be considered
 distributed with the plugin and not to be edited by the user; at some
 point you have to make some assumption to keep problems managable).
 
 If this seems so inefficient you could try to rescue the state from
 geany_plugin_register() to init. However keep in mind that init can be
 called without prior call to geany_load_module(), if the user toggles
 plugins in the PM dialog. And that init might not be called at all, so
 plugins shouldn't be wasteful with resources in geany_load_module() if
 might never be needed.
 

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

 
 What do you do currently?
 
 Besides, I didn't mean to make init() any better than the current
 plugin_init() w.r.t. to its semantics. The only difference is more/other
 parameters.
 Geany does not handle failing init() currently, and I don't want to
 change that now because I think that's out of scope for my proposal.

Well, while I can understand not extending the scope of the changes, as
it introduces *new* API, it's a good time to improve things without
breaking any compatibility :)

 […]  I also tend to think that a failing init is misdesigned.
 
 What do others think about this point?

Well, while I agree a plugin shouldn't fail to initialize (when the user
clicks on it), I tend to agree with Dimitar: there are some things that
can fail, and that you can only know whether or not they do by actually
trying.  Checking many things when querying the module seem wrong to me,
because if we start to make e.g. extensive I/O there, it gets slow for
no reason.  And it also seem wrong to run anything more than strictly
needed when the plugin hasn't even been activated.

E.g., I don't want to bother about performance with 250 plugins
installed beside how long Geany takes to scan the SOs.

And in the end, I agree that if init() can still fail to do its job
(which will be the case, unless all failable initialization is done in
load_module() only), then it's better to have a way to notify the user
something failed, rather than pretending it worked but having a
non-functional plugin.

All this said, a counter argument is that many plugins will load
external UI for configure(), and there we have no way to fail either.


So anyway, I think I'd be in favor of a failable init(), maybe like

Re: [Geany-Devel] New plugin loader mechanisms

[Colomban Wendling]

Hi,

I'm answering both to the initial mail and this one here, so expect
mixed citations.  This will avoid raising the same points twice :)

First, stuff extracted from the first mail.
Disclaimer: Sorry if some remarks look slightly off-formulated, but
while I altered them in the light of the last changes, I didn't have the
courage of rewrite all sentences from the ground up when they were still
(mostly) relevant.

 gboolean geany_plugin_register(GeanyPlugin *, gint api, gint abi,
 PluginHooks *(see below), gpointer)
 
 The plugin defines a single global function,
 geany_load_module(GeanyPlugin *, GModule *). This is the only function
 that geany learns about using g_module_symbol(). And the only thing this
 function ought to do is to call geany_plugin_register(). This does 4 things
 1) Provide the plugin handle to the plugin very early
 2) Perform abi and abi checks, so this is finally done inside geany.
 Added bonus is that geany knows the requested api and can possibly apply
 backcompat workarounds on a per plugin basis (instead of globally), warn
 about very old plugins or even deny loading them.
 3) Register the remaining hooks and callbacks (see below)
 4) Associate a userdata pointer to the plugin, geany will pass this
 pointer back to future calls into the plugin (good for proxies)
 
 In the future geany_plugin_register should be able to be used to
 register plugins recursivly, by passing the appropriate GeanyPlugin
 pointer, i.e. plugin A should be able to call
 geany_plugin_register(plugin_B, ...) to realize pluxies.

How does the proxy plugin create plugin_B?  plugin_A is given by Geany,
but how is plugin_B created?

Actually, when I started reading the mail I thought you'd have something
like this (which is basically like Matthew's proposal):

```
struct RealPlugin /* good name would be better */ {
/* we may need this indeed, set by register_plugin() */
GeanyData *geany_data;
/* plugin metadata */
const gchar *name;
const gchar *author;
const gchar *version;
/* ... */
/* plugin vfuncs */
gboolean(*init) (RealPlugin *self);
void(*uninit) (RealPlugin *self);
GtkWidget   (*configure) (RealPlugin *self, GtkDialog *dlg);
/* ... */
};
```

and that a plugin's geany_load_module() would do something like

```
geany_load_module(...) {
static struct RealPlugin self = {
N_(foo),
N_(john doe),
42,
...
my_plugin_init,
my_plugin_uninit,
my_plugin_configure,
...
};
geany_plugin_register(... self ...);
}
```

e.g. give Geany a structure representing the plugin, and that's all.
Note that with this apporach, you can even add class-style custom data
to a plugin simply by having a struct larger than RealPlugin:

```
struct MyRealPlugin {
RealPlugin parent; /* offset 0 has the Geany struct, so it's binary
compatible */
/* plugin-specific fields here */
int the_game;
};
```

Maybe proxy plugins need a data argument, but maybe not: they should be
able to pack whatever they need in the struct they register for the
sub-plugins.  Not extending the structure from plugins might make
easier extending the structure on our side, without needing padding though.

But anyway whether it's an extra data* argument (or member) or an
extended struct doesn't change much my point, which would be that all
the plugin description would be given to Geany as one single thing.

With your new proposal that gets rid of set_info() the how does a
proxied plugin give its info (mostly) moot, but there still is the
question why having separate argument holding pointless stuff
(GeanyPlugin) while all could be packed in a new and better structure.

E.g. my point could maybe be summarized with why split things up while
they actually represent the same thing?.

And BTW, remember that we need the (translated) plugin infos in all
cases, so it should be no difference giving it straight ahead -- even
proxied plugins.


 […] Additionally the existing
 PluginCallbacks pointer registered here for all plugins that want
 statically defined signal handlers.

I'm really not sure if we should bother keeping this.  Is there any
benefit over plugin_signal_connect()?


 […] Please also note
 that each hook receives the GeanyPlugin pointer and the userdata
 pointer, these are the same passed to geany_plugin_register.

Why pass the GeanyPlugin?  I mean, what useful info is in this?  there
is the PluginInfo, which seem hardly useful, and the GeanyPluginPrivate,
which is totally opaque, so totally useless.
OK you add the GeanyData too which is useful (but could be part of the
RealPlugin thing just as well).

Again, here I'd have expected something like my_plugin_init(self, ...),
as 1) it follows the common pass the self/this as first parameter
scheme, and it's actually the only 

Re: [Geany-Devel] [Geany-Users] My non-C plugin roadmap

[Colomban Wendling]

Le 29/03/2015 00:23, Thomas Martitz a écrit :
 […]
 
 - linkage-cleanup (PR#429) - This changes the way plugins access Geany
 API functions. Instead of exporting a pointer to a struct of structs of
 API function pointers, now the APIs are exported directly. This work
 also includes an effort to stop exporting all function (we do this
 currently as a workaround to allow gtkbuilder to work), so *only* API
 function are exported and plugins cannot call internal function anymore.
 This change is also required to allow gobject-introspection to find
 geany functions at runtime (through g_module_symbol()) in the future.

Agreed, but on the fact that it's not actually also required for GI,
it's *only* required for this kind of thing.  It's good and everything,
but not required but for dynamically looking up the functions.

 - new API functions for registering keybindings (PR#376). The current
 API functions do not allow context information to be stored and passed
 to the key handler function. This makes it very hard for non-C plugins
 to use these function. So what's  needed are key handlers that get the
 necessary context information. This allows interprepted language plugins
 to register keybindings.

Agreed.

 - A new plugin loader mechanism (a thread about this is already running
 on the devel list): Similarly to the keybindings, the plugin_* functions
 implemented by plugins do not carry any context information, making it
 hard for non-C plugins to implement them properly. Therefore a new
 loader mechaism is needed so that the context information can be passed.
 The loader works such that an API function is called to register a
 function pointer table. This is crucial to possibly support plugins that
 register other plugins (so called pluxies) which is simply not possible
 with the current mechaism. The current loader is kept for backwards
 compatibility (but will not receive new features).

Agreed.

 - New API functions to allow plugins to act as proxy plugins (pluxies).
 These pluxies can then implement whatever is needed to execute code in
 the in the actual plugin, like invoking an interpreter or firing up a
 java vm. The pluxies call the new loader's API function on behalf of the
 actual plugin. The API function to implement the pluxies is a simple
 geany_register_pluxy() that, much like the normal plugin loader, that
 pluxies use to pass a function pointer table which implements the
 necessary hooks (probe(), load() and unload())

That's the part I'm really fuzzy about.  I really don't see why we need
this specific layer (maybe in an ideal world not bothering about how
Geany currently does it): as asked on the other thread, why do we need
anything beside geany_plugin_register() (required for everyone) and
geany_plugin_unregister() (required only when registered sub-plugins, as
the parent need to clean them up when it itself quits)?


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

Re: [Geany-Devel] win32 right click on tab -- Open in New Window not working

[Colomban Wendling]

Le 17/03/2015 13:37, Colomban Wendling a écrit :
 Le 17/03/2015 11:16, Jiří Techet a écrit :
 […]

 I don't use Windows myself but did some work in this area recently to
 make it work it on os x so I'm familiar with the code a bit. I think the
 only thing you need to do is to put the location of geany.exe into your
 PATH environment variable so geany can find it (it just tries to run
 geany without checking any additional paths).
 
 What about this?
 
[…]
 
 What do you think?

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

Re: [Geany-Devel] PairTagHighlighter / Not auto clear previous highlight when click other tag

[Colomban Wendling]

Hi,

tl;dr: I found the issue in the end, which is in a call from the plugin.
 Here below is my train of responses because they still are of some
interest, but you can skip directly to the last paragraph.

Le 09/03/2015 14:48, Volodymyr Kononenko a écrit :
 A search with git bisect has shown, that the bug was introduced with
 updating Scintilla to 3.3.2:
 
 […]
 
 Similar issue http://sourceforge.net/p/scintilla/bugs/1604/ I've found
 on Scintilla bug tracker was fixed only for win32 - here is the patch
 http://sourceforge.net/p/scintilla/code/ci/23f89aef53c7ab73bdd45ae1302b97698682e3cd.

I highly doubt it's anything like the same issue, because the one
described here is a redraw issue, which should get fixed when triggering
another redraw, like e.g. scrolling the offending part offscreen and
back, while the issues I see with pairtaghighlighter persist after
redraws (which means the indicators themselves are still here).

Moreover, clearing the indicators on the whole buffer:

 scintilla_send_message(sci, SCI_INDICATORCLEARRANGE, 0, sci_get_length(sci));

instead of only the range passed to the function fixes the issue for me,
so I would really bet on inappropriate clear range.

Which is indeed kind of weird because it really does work with 1.23 and
not 1.24, even with the very same plugin .so.

 I tried to detect the first Scintilla commit, which introduced the
 issue, but I see that merging Scintilla to Geany sources is non-trivial.
 Build failed after the first attempt.
 
 Folks, what do you think about it? Is it enough information that it is
 Scintilla issue and we need to report it or something was not taken into
 account during upgrading to 3.3.2?

Actually it's the plugin's SCI_INDICATORCLEARRANGE
 http://www.scintilla.org/ScintillaDoc.html#SCI_INDICATORCLEARRANGE
that is incorrect: the second parameter should be the *length* to clear,
not the end position.  Apparently earlier Scintilla versions were
forgiving on the range, but new ones aren't and do nothing with invalid
ranges.

I made you a PR fixing the issue:
https://github.com/geany/geany-plugins/pull/200


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

Re: [Geany-Devel] PairTagHighlighter / Not auto clear previous highlight when click other tag

[Colomban Wendling]

Le 09/03/2015 17:40, Volodymyr Kononenko a écrit :
 Colomban,
 
 Really my fault (
 Thanks a lot for participation and detecting root cause! I've tested
 your patch, it fixes the issue.
 Thanks again!

You're welcome :)

 P.S. The only question, when the new version of geany-plugins is planned
 to be released?

That's something I was starting to talk about with Frank, and we didn't
yet plan anything but agreed it should be soonish (but it probably
means like 2 months).

We'll try and plan something and tell you guys.

Regards,
Colomban
___
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

[Colomban Wendling]

Hey,

Le 12/02/2015 22:21, Liviu Andronic a écrit :
 Dear all,
 Recently I've discovered Coverity, a code checking tool, and went
 ahead and submitted the Geany code for static analysis by this
 service:
 https://scan.coverity.com/projects/1388

Quoting Coverity's Scan User Agreement:

You will not publish any findings regarding or resulting from use of
the Service or the Software;

IANAL, but this looks like we couldn't discuss an issue it found on e.g.
this mailing list.  And your report about what it did find in Geany's
code is already a violation of that agreement.

More, just for the fun:

“Confidential Information” means: […] (d) any results of operation from
use of the Software or the Service;

Without limiting the generality of the foregoing, You agree that You
will not post […] the results of the Service […] on any network that is
accessible by anyone.

And this is the Scan User Agreement, I couldn't even find the Scan Terms
of Use (at least not without trying to actually register myself).

So… really?

Regards,
Colomban


PS: Of course one will tell me that in practice they won't come after
us for discussing a fix, but if it really is against the UA I'd rather
not try and see what happens.
___
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

[Colomban Wendling]

Le 26/02/2015 19:18, Colomban Wendling a écrit :
 […]
 
 Quoting Coverity's Scan User Agreement:
 
 You will not publish any findings regarding or resulting from use of
 the Service or the Software;
 
 IANAL, but this looks like we couldn't discuss an issue it found on e.g.
 this mailing list.

OK, someone gave me the argument well but it's just to avoid security
vulnerability disclosure, but even if it was true (the UA really isn't
specific on this), as the UA is written I don't think we could *ever*
talk about *anything* we see there.  Not even days after an actual bugs
was found, nor ever -- which in addition of being silly disallows
discussion on how not to reproduce it in the future.

 […]
 
 And this is the Scan User Agreement, I couldn't even find the Scan Terms
 of Use (at least not without trying to actually register myself).

Hum, I tried to register with my GitHub account just to see if I'd get a
link to these mythical Scan Terms of Use during the process, and… I
didn't have to accept *anything*, no nothing, like click and boom
you're registered.  So apparently now I do have an account there --
but I still can't find these Scan Term of Use.

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

Re: [Geany-Devel] Plugins tag for 1.24

[Colomban Wendling]

Le 13/01/2015 14:32, Lex Trotman a écrit :
 $subject seems to be missing, or am I blind again :)

geany-plugins$ git tag | grep -F 1.24
1.24

so… I guess you're blind :)

Cheers,
Colomban


PS: https://github.com/geany/geany-plugins/releases/tag/1.24 so it's not
even me :)
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] geany crashes when starting to debug

[Colomban Wendling]

Hi,

Le 18/11/2014 17:43, apanagio a écrit :
 I try to debug a simple c program and geany crashes all together when I
 press the run button.
 
 Also there are no icons on the buttons in the debug panel
 
 I'm using geany 1.24.1 on ubuntu 14.10 64bit
 with the latest source of geany-plugins from github.
 
 Is there something I'm doing wrong? How can I fix this?

I guess you are using the debugger plugin from Geany-Plugins?
Then, possibly https://github.com/geany/geany-plugins/pull/174

 [...]
 
 I hope this is the appropriate list for such discussion, and I apologize
 if it is not.

Not completely, but for the lack of a really better one I guess it's
okay.  Though we generally prefer to keep questions not related to
Geany's internal development to us...@lists.geany.org :)

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

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

[Colomban Wendling]

Le 09/11/2014 16:15, Enrico Tröger a écrit :
 On 29/10/14 16:17, Colomban Wendling wrote:
 [...]

 Enrico: would the change on geany_private.rc from
 https://github.com/b4n/geany/commit/a24d9217c3dfb959b4138fe3bffd871d9dc88ba4
 break Waf or something else?  (yes, I could check by running a VM, but I
 can also ask first :)
 
 I tested it on my VM and assumed it would break the build but
 surprisingly it does not.
 I don't know why but at least with Waf, using icons/geany.ico works as
 well as ../icons/geany.ico. I cannot really explain it but your change
 doesn't break the build.

Great then.  I also tried to build with Waf on Windows with this patch
and it didn't complain.

So, I made a PR https://github.com/geany/geany/pull/377 please give it a
quick look and tell me if you see anything absurd.  It should be OK
though, as I successfully built a mostly-working executable with it :)

Cheers,
Colomban



signature.asc
Description: OpenPGP digital signature
___
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

[Colomban Wendling]

Le 08/11/2014 12:27, Jiří Techet a écrit :
 […]
 
 Good, if there's an agreement here, I can have a look at it. But I'll
 wait until some of my TM patches get merged. There are a bit too many
 of them floating around and I'm slightly getting lost in all of my
 branches.

I'll try to merge the tm branch as soon as possible, just a few small
comments as you saw.

 Another thing I have noticed is that it would be good to make
 sTagEntryInfo as close to ctags as possible - for instance, the
 signature member in Geany is called argList in ctags and
 seekPosition is unused and not present in ctags.

Good idea indeed.  I just gave it a look, and it should be pretty easy
but for our varType field (a string) v.s. CTags' typeRef (a pair of
strings of the form [kind, name]).  Those are not really the same, and
are both somewhat interesting (though ours seems a little better to me):

Our varType is used to report a function's return type, or a variable
type, or the type mapped to a typedef for example.  And it includes the
whole type, including 'struct', '*'s and '[]' -- which is both useful
(for the user to see) and partly impractical (for using it from the code).

CTags' typeRef seems only used to report C typedefs, and has two parts,
a kind part and a name part.  For example, `typedef struct foo bar;`
would generate a typeRef of [struct, foo] -- which is partly useful
to resolve the correct definition of foo in case there are several,
but not so much as generally you can rule out anything but types when
resolving a typedef.

The problem here is that there isn't always a kind to associate with
the return type of a function, there only is if it's a custom type, and
even then only it if isn't a typedef.  E.g. we have nothing to put in
typeRef's kind for `int printf(const char *fmt, ...)`, or even
`GeanyDocument *document_get_current(void)`.

For now it's probably not so much of a problem as in CTags only the C
parser seems to use it -- and we won't want to just use this one right
away because it misses some things ours handle (yet the contrary is
probably also true) -- but it might be useful to solve this problem anyway.

So, what do you think about this?
___
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

[Colomban Wendling]

Le 08/11/2014 17:50, Colomban Wendling a écrit :
 Le 08/11/2014 12:27, Jiří Techet a écrit :
 […]

 Good, if there's an agreement here, I can have a look at it. But I'll
 wait until some of my TM patches get merged. There are a bit too many
 of them floating around and I'm slightly getting lost in all of my
 branches.
 
 I'll try to merge the tm branch as soon as possible, just a few small
 comments as you saw.
 
 Another thing I have noticed is that it would be good to make
 sTagEntryInfo as close to ctags as possible - for instance, the
 signature member in Geany is called argList in ctags and
 seekPosition is unused and not present in ctags.
 
 Good idea indeed.  I just gave it a look, and it should be pretty easy
 but for our varType field (a string) v.s. CTags' typeRef (a pair of
 strings of the form [kind, name]).  […]

I did the easy removals/renames in
https://github.com/b4n/geany/commits/ctags-tag-entry (that's on top of
TM branch, but easy to change or pick up specific commits) to see how
easy it'd be -- and this part was trivial.

Cheers,
Colomban
___
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

[Colomban Wendling]

Hey,

Le 07/11/2014 17:38, Jiří Techet a écrit :
 […]
 
 I noticed that it's necessary to change the tag types (the GoKinds[]
 array in the case of go) to match the supported types in the tag
 manager and Geany. This has to be done for every parser because the
 tag types aren't standardized in any way in ctags and can be more or
 less arbitrary.
 
 In my opinion, doing this in the parser itself is a bit unfortunate -
 when updating a parser from the ctags repository, these have to be
 changed. Worse, if ever something like ctags shared library happens
 and all the parser support is moved there, these will have to be
 always changed in every parser after updating to new ctags version.
 
 I think it would be better to keep the tag types inside the individual
 parsers as they are and have a separate table in the tag manager which
 will map the ctags type to the type used by Geany.

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

When upstream CTags was basically dead it didn't matter much as we
pretty much never updated anything, but now there is some activity again
(even though it's not upstream yet) it would probably make sense.

Note that there is another potential issue when importing a parser: use
of MIO.  It affects fewer parsers, but a few are using fpos_t (mostly
through getInputFilePosition()), and we can't use this for memory
parsing.  It's generally just a matter of s/fpos_t/MIOPos/ and the
compiler will whine, but that's a step.

 The only disadvantage of this approach I can think of is that the type
 names might change in ctags and we could easily miss this change and
 not update the mapping. For this reason it would be good to add some
 integrity check function which goes through all the kinds in ctags
 for every language and checks whether they are mapped to Geany's tag
 types and vice versa. But I think this can be done quite easily so it
 isn't a real problem.

Yeah, updating would still require some care, but not much more than
right now.  And as you say we could have a tool listing missing mappings.

 What do you think?

I didn't really think of the implications so I can't tell if it has
other problems, but I feel like it's a good way to go.

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

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

[Colomban Wendling]

Le 29/10/2014 06:48, Matthew Brush a écrit :
 On 14-10-26 04:16 PM, Enrico Tröger wrote:
 […]
 I don't use autotools based cross-compilation.

 
 I had a try at this for a while and after a number of changes it's
 almost working. I got past the build system, compiler, and linker
 problems, […]

FWIW I pushed the changes I did myself (hey ;) to
https://github.com/b4n/geany/commits/wip/autotools-mingw-cross just in
case it can be of some use.

Enrico: would the change on geany_private.rc from
https://github.com/b4n/geany/commit/a24d9217c3dfb959b4138fe3bffd871d9dc88ba4
break Waf or something else?  (yes, I could check by running a VM, but I
can also ask first :)


When we merge #356 we can probably drop libiberty altogether as the only
code we have that definitively depend on `fnmatch()` is in
`tm_file_entry.c` (which is unused, and removed by the PR).  BTW, if I'm
not mistaken our check for fnmatch are currently wrong on any platforms, as:

1) the check is not a strict requirement, yet I believe it is required
2) it never defines HAVE_FNMATCH yet it's what CTags' strlist checks for
(though it's not a strict requirement in CTags, it just make the test
useless there)

It'd be easy to fix however, but if we remove it in two dais it doesn't
matter much.

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

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

[Colomban Wendling]

Hey,

Le 14/10/2014 19:50, Enrico Tröger a écrit :
 [...]
 
 - auto completion popup is rendered incorrectly

I don't see that on my GTK 2.24.10, it works just fine here.

 - some icons are missing/not displayed correctly

I never really noticed, but I have this problem too.


BTW, I couldn't build current Git with Waf, with the error
SHGFP_TYPE_CURRENT undefined, I had to manually include win32-config.h
to have the right pre-processor defines.  Any insight on how it should
be fixed? (or rather, please fix it! ;)

Regards,
Colomban




signature.asc
Description: OpenPGP digital signature
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] ntrel - Don't prompt for reload from infobar when there are no unsaved changes

[Colomban Wendling]

Le 13/10/2014 08:06, Thomas Martitz a écrit :
 Hi,
 
 this is about commit ab7a0018b2518793f26af2fe20a06a8a1886e031 and the
 message reads 
 Don't prompt for reload from infobar when there are no unsaved changes.

The patch removes the confirmation dialog when clicking the Reload
button from the infobar if the buffer hasn't changed.  It doesn't affect
the reload keybinding or menu item.

 What does that mean? I do absolutely want to be asked before reloading
 even if the file has no changes or saved ones.

Even when clicking the Reload button from the infobar?
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

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

[Colomban Wendling]

Le 12/10/2014 17:28, Nick Treleaven a écrit :
 keybindings.c:cb_func_move_tab needs to be updated now ScintillaObject
 is not a child of main_widgets.notebook.

Indeed.  Should be trivial, I'll work on it.
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

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

[Colomban Wendling]

Le 12/10/2014 17:54, Colomban Wendling a écrit :
 Le 12/10/2014 17:28, Nick Treleaven a écrit :
 keybindings.c:cb_func_move_tab needs to be updated now ScintillaObject
 is not a child of main_widgets.notebook.
 
 Indeed.  Should be trivial, I'll work on it.

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

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

Re: [Geany-Devel] i want to contribute with this project

[Colomban Wendling]

Le 09/10/2014 16:11, robertodmachado . a écrit :
 I'm roberto, and would like to participate in this project with my
 knowledge in C.

Hi Roberto, and welcome here!

 How should I start ?

You should first read the HACKING file the the repository, but then it
depends on what you'd like to work on.

If there is something particular you're interested in, either start
writing a patch and propose it if it's relatively simple, or start a
discussion on this mailing list if the matter requires some more complex
decisions to be made.

If you'd just like to work on something, you can pick a bug
(http://sourceforge.net/p/geany/bugs/) or a feature request
(http://sourceforge.net/p/geany/feature-requests/) and try addressing
it.  You can also take a look at
http://www.geany.org/Support/PluginWishlist, although this is quite old
and outdated (some things are already addressed, some are crazy…).

Don't hesitate to ask anytime on the mailing list or on the IRC channel.

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

Re: [Geany-Devel] Windows GTK Runtime 2.24 and config directory

[Colomban Wendling]

Hey,

Le 22/08/2014 20:23, Enrico Tröger a écrit :
 lately, I started building a new Windows installer which includes a
 recent GTK 2.24 runtime for Windows which need for future releases.

Nice :)

 While most things went fine I noticed one problem:
 
 GTK, in detail Glib, changed the way g_get_user_data_dir() works on Windows:
 in older releases, something GLib 2.28 or 2.26 and older,
 g_get_user_data_dir() returned c:\users\username\AppData\Roaming, in
 newer GLib versions it returns c:\users\username\AppData\Local.
 
 This affects users who already have a config directory located in
 ...\Roaming and Geany would look in ...\Local now.
 
 This is the change I'm talking about:
 https://git.gnome.org/browse/glib/commit/glib/gutils.c?id=9d80c361418f94c609840ec9f83741aede7e482c

Oh my.  And we though it was a supporting library :)

 How do we want to handle this?
 
 - continue using the ...\Roaming directory (and so not using
 g_get_user_data_dir() anymore)
 
 - leave the code as it is, resulting in a new complete config for users
 
 - add some code to check if a config in ...\Roaming exists and if so,
 move it to ...\Local
 
 
 I'd implement the last choice if there are no objections. This is not
 nice because we implement again some magic config directory move code
 but at least the user won't notice that GLib change.

Agreed, both with solution and remark.

Regards,
Colomban



signature.asc
Description: OpenPGP digital signature
___
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

[Colomban Wendling]

Le 07/08/2014 23:38, Enrico Tröger a écrit :
 On 07/08/14 18:41, Colomban Wendling wrote:
 Le 07/08/2014 18:24, Enrico Tröger a écrit :
 [...] I'd like to make the nightly
 builds a bit stricter especially if it helps to spoil out such problems.

 Any idea how to make such warnings error without using -Werror? I'm
 afraid -Werror is too hard for cross-compiling.

 -Werror-implicit-function-declaration

 I use the following when building Geany, and although it shows a few
 warnings (one in Scintilla that is fixed upstream, a few harmless const
 promotions, and a few non-literals passed as printf-like formats) it's
 pretty neat, maybe we'd like to be able to look at these in the logs.
 Not sure it's so important though.

 -Wall -Wextra -g -O2 -Wunused -Wno-unused-parameter -Wunreachable-code
 -Wformat=2 -Wundef -Wshadow -Wpointer-arith -Wwrite-strings
 -Waggregate-return -Wstrict-prototypes -Wmissing-prototypes
 -Wmissing-declarations -Wmissing-noreturn -Wmissing-format-attribute
 -Wredundant-decls -Wnested-externs -Werror-implicit-function-declaration
 -Wno-deprecated-declarations
 
 Thanks.
 I applied these to the Windows nightly builds and also printed the used
 CFLAGS into the logfile (for reference).
 
 http://nightly.geany.org/win32/build_win32_geany_stderr.log

Hum, this is weird.  There are many more warnings that I saw locally,
and the compiled code looks outdated -- when I go to e.g.
src/symbols.c:579: warning: will never be executed, I see... an
accolade starting the function body.

Also, the headers used seem to generate a lot of shadowing warnings, so
maybe we should disable this one.  Though, some are really weird, like
having a math.h having a global y0 symbol!?

Anyway, as-is it's not really useful, so maybe we should either fix the
warnings or remove the flags triggering them when not important.

Regards,
Colomban
___
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

[Colomban Wendling]

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 :)
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] Why smart indentation is so stupid?

[Colomban Wendling]

Le 25/07/2014 21:33, Pavel Roschin a écrit :
 I'm very wondered how does smart indentation feature work. If previous line
 is empty, it removes indent assuming that single empty line is an empty 
 indent.
 Smart indentation for multiple lines is absolutely awful: it doesn't take into
 account internal sub-indents and makes selection flat.

It's a lie, this feature isn't smart, it just sets the same indentation
than the previous line.

 Is anybody using this?

I doubt it

 Under smart indentation people assume astyle, php-beautifier and so on:
 http://stackoverflow.com/questions/18828162/smart-auto-indentation-available-in-geany

Yeah, we know we should have a nice (and complex) system for
configurable smart indentation, but every time we tried to think about
it we discovered that some languages are so crazy that it's really not
simple, and probably would require some specific code for some languages
(did I say Haskell?).  And nobody did the filetypes plugins yet :(

However, you might be able to use some indenters tools from Geany using
custom commands to some extent.  In a similar way, I once started a
multi-indernters plugin, but I didn't finish it for various reasons, one
being my lack of much interest in it (I'd rather work on a solution for
configurable and nice thing for Geany than on wrapping gnuindent, astyle
or others, tools I never really used).
If anyone is interested, it's here: https://github.com/b4n/grind

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

Re: [Geany-Devel] RFC: Keybindings rewrite

[Colomban Wendling]

Le 07/06/2014 02:01, Matthew Brush a écrit :
 On 14-06-06 01:35 PM, Thomas Martitz wrote:
 Am 06.06.2014 16:24, schrieb Yosef Or Boczko:
 I think it better to port to GAction instead of GtkAction (GtkAction
 has been deprecated since version 3.10 and will be removed in GTK+ 4),
 so it will be ease to port geany to GTK+ 4 in the future.

 We have elaborated GAction. The problem is that it is only recent in
 Glib/Gtk versions. Geany is committed to support at least the last gtk2
 release for some time to come.

 
 Also, unless I missed it in the docs, GAction/GSimpleAction do not
 appear to support associating labels, tooltips, icons, etc with the
 action so would require duplicating these all over the place (similar to
 the current way we do it).

The action not having the UI details may not be the worst thing ever,
basically actions ways to interact with the application (commands if
you will), not necessarily a UI element.

But yeah, defining the action appearance and using this all over the
place is super handy.
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel