Re: [Geany-Devel] Order of plugin signal connections

[Matthew Brush]

On 2020-05-14 11:31 p.m., Austin Green wrote:

Hi Matthew,


Just to be clear, you are talking about this:
https://github.com/geany/geany-plugins/blob/062865e3b57a3baa882f69e4f3bc291278c200e4/keyrecord/src/keyrecord.c#L99


Yes, that's the one.


and depending on the order the plugins connect to same signal as well as
whether or not they return `TRUE` from their signal handler, there's no
guarantee the `keyrecord` plugin gets too see all
`ScintillaObject::key-press-event` signal emissions?


No, I was wrong with my first guess about the order mattering; it turns that 
it's just the fact that anything else (Geany or plugin) binds to a key makes 
that key unavailable to 'keyrecord'.



That doesn't sound right. Anything that connects to say 
`ScintillaObject::key-press-event` has the opportunity to propagate that 
signal to other handlers by returning `FALSE` from the handler function. 
Any plugins which swallow GTK+ events, preventing them to be handled by 
other plugins or core itself, should be highly suspect, as far I can see.


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

Re: [Geany-Devel] Order of plugin signal connections

[Matthew Brush]

On 2020-05-14 10:18 p.m., Austin Green wrote:

@Matthew:

Further to my previous message, you might also inspect the existing
plugins which are blocking GTK+ signals and see why they're doing that,
whether on purpose or on accident, and possible ways they can not do that.


They block the key-press-event signal merely by binding to a key.  Geany, in 
its handling of key-press-event, checks for a key binding that matches, and if 
found, calls the callback and then prevents the event from going any further 
(by returning TRUE).  If it didn't, any plugin could receive the same events 
and assign its own action to the key, and chaos would no doubt be the  result.



Just to be clear, you are talking about this:

https://github.com/geany/geany-plugins/blob/062865e3b57a3baa882f69e4f3bc291278c200e4/keyrecord/src/keyrecord.c#L99

and depending on the order the plugins connect to same signal as well as 
whether or not they return `TRUE` from their signal handler, there's no 
guarantee the `keyrecord` plugin gets too see all 
`ScintillaObject::key-press-event` signal emissions?



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

Re: [Geany-Devel] Order of plugin signal connections

[Matthew Brush]

On 2020-05-14 9:34 p.m., Austin Green wrote:

@Matthew:

You could use something like `gtk_key_snooper_install()`[0] to get
priority access to keys. It's deprecated because the GTK+ team don't
care about edge cases where it's useful, or other reasons, but it should
still work fine with GTK2/3 on all platforms, though I haven't tested it.


I'd rather not use deprecated functions, you never know what GTK might do with 
them in the future.


It will exist and (in theory) function correctly until gtk4.


If you don't mind writing #ifdefs/platform-dependent code, you could use
XLib and/or Win32 functions directly to grab the key events for the
window. I don't believe Wayland protocol supports this (on principle),
but it may be supported by some compositors in protocol extensions, not
sure.
I can think of a few ideas to do it with Geany/GTK+/plugin alone, but
I'd have to test it out to see if would work at all.


Hmm, sounds a bit can-of-wormsy.  I feel my solution is cleaner; needs only two 
extra statements in keybindings.c.



I guess we'll see what the PR looks like, I'm not entirely sure I 
understand the underlying issue (assuming you mean the existing 
'keyrecord' plugin?), or the proposed solution.


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

Re: [Geany-Devel] Order of plugin signal connections

[Matthew Brush]

On 2020-05-14 5:48 p.m., Austin Green wrote:

Hi Matthew,

On Thu, 14 May 2020 16:20:58 -0700
Matthew Brush  wrote:


Can you elaborate on what you are trying to do specifically? There may
be a better way.


Sure thing.

The plugin 'recordkey', and possibly others, connects to the 'key-press-event' 
signal.  Possibly depending on the order of plugins being loaded, or possibly 
not, but either way: some of the keys bound to other plugins are lost to the 
view of 'recordkey', presumably because Geany processes all of the keybindings 
in its handling of the 'key-press-event' signal.  The order of loading plugins 
cannot be controlled anyway, as the user may load/unload at any time.  Causing 
Geany to emit a new signal, on receipt of the 'key-press-event' signal, but 
prior to any processing, allows any plugin (that connects to the new signal) to 
view (but not suppress) all key press events.

I'll be pleased if there is another way which doesn't involve changing Geany, 
it will save me some work.   ;)   And of course it's always good not to have to 
bump the ABI version.



Further to my previous message, you might also inspect the existing 
plugins which are blocking GTK+ signals and see why they're doing that, 
whether on purpose or on accident, and possible ways they can not do that.


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

Re: [Geany-Devel] Order of plugin signal connections

[Matthew Brush]

On 2020-05-14 5:48 p.m., Austin Green wrote:

Hi Matthew,

On Thu, 14 May 2020 16:20:58 -0700
Matthew Brush  wrote:


Can you elaborate on what you are trying to do specifically? There may
be a better way.


Sure thing.

The plugin 'recordkey', and possibly others, connects to the 'key-press-event' 
signal.  Possibly depending on the order of plugins being loaded, or possibly 
not, but either way: some of the keys bound to other plugins are lost to the 
view of 'recordkey', presumably because Geany processes all of the keybindings 
in its handling of the 'key-press-event' signal.  The order of loading plugins 
cannot be controlled anyway, as the user may load/unload at any time.  Causing 
Geany to emit a new signal, on receipt of the 'key-press-event' signal, but 
prior to any processing, allows any plugin (that connects to the new signal) to 
view (but not suppress) all key press events.

I'll be pleased if there is another way which doesn't involve changing Geany, 
it will save me some work.   ;)   And of course it's always good not to have to 
bump the ABI version.




You could use something like `gtk_key_snooper_install()`[0] to get 
priority access to keys. It's deprecated because the GTK+ team don't 
care about edge cases where it's useful, or other reasons, but it should 
still work fine with GTK2/3 on all platforms, though I haven't tested it.


If you don't mind writing #ifdefs/platform-dependent code, you could use 
 XLib and/or Win32 functions directly to grab the key events for the 
window. I don't believe Wayland protocol supports this (on principle), 
but it may be supported by some compositors in protocol extensions, not 
sure.


I can think of a few ideas to do it with Geany/GTK+/plugin alone, but 
I'd have to test it out to see if would work at all.


Regards,
Matthew Brush


[0]: 
https://developer.gnome.org/gtk3/stable/gtk3-General.html#gtk-key-snooper-install

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

Re: [Geany-Devel] Order of plugin signal connections

[Matthew Brush]

On 2020-05-11 7:00 p.m., Austin Green wrote:

I need to ensure that one particular plugin will process keyboard events before 
other plugins get to see them (as some plugins may cause further handling of 
the event to be suppressed).  Is there a way to achieve that?  I'm guessing 
that the order of calling the plug init functions is what counts, but it's 
complicated by plugins being unloaded and reloaded dynamically.


Hi,

Can you elaborate on what you are trying to do specifically? There may 
be a better way.


Regards,
Matthew Brush

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

Re: [Geany-Devel] Self-introduction =)

[Matthew Brush]

On 2020-02-25 3:40 p.m., ivze wrote:

Good day!

My name is Ivan Zelinskiy.

Who am I?

First of all I am a practicing FPGA developer writing my code in Verilog 
and SystemVerilog. I also know C/C++.


Secondary I am a geany user, as it's my favorite editor in Linux - the 
OS (of choice!) of my workstation.


As a result of the former two statements, I support my own branch of 
patched geany, gradually fixing issues, "paper-cuts", extending language 
support beyond the mainstream features.



It was a steady gradual process, the first commit of my branch dates 
back to 2015.  It all started with fixing "localparam" keyword, that 
would not highlight properly in /data/filedefs/filetypes.verilog. It all 
ended in rewriting a good part of /ctags/parsers/verilog.c to fix tag 
generation to include some SystemVerilog features and implement a better 
support for classical Verilog constructs, that would otherwise often 
produce "haywire" results while being parsed.


The complete list of changes is to be created =).

My branch of geany is published on github: 
https://github.com/ivzeivze/geany


It's a diff-patched geany/master, that is back-merged to my local 
historical branch, kept out of public sight (it's messy! =)) I am 
currently testing the changes, introduced by exporting, by means of 
everyday use. But it seems pretty stable.


I would be glad to see my work merged back into mainstream geany. Yet 
likely some clean up should be done before issuing a pull request.



With best regards to devel subscribers,

Ivan Zelinskiy.



Hello and welcome!

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

Re: [Geany-Devel] New language in Geany

[Matthew Brush]

On 2019-08-06 6:01 a.m., Tim Tassonis wrote:

On 8/1/19 9:41 AM, KK2000 wrote:

Dear Geany developers,

I have developed a version of the Geany with native support for the 
GIBIANE language. The git patch is attached and has been tested with 
the latest version of Geany (commit 
9c91c287803ae05ce0f2aacd605564301e0ef4aa).


What is the GIBIANE language ?

   The GIBIANE language is the language to control the Cast3M Software.

   Cast3M ( http://www-cast3m.cea.fr/ ) is a finite element software 
for structural and fluid mechanics.


   It is developed by the Department for Modelling Systems and 
Structures (DM2S) from the French Alternative Energies and Atomic 
Energy Commission ( CEA http://www.cea.fr/english ), and it is widely 
used around the world.


   In Cast3M, the user have access to all source code that control 
algorithms for mechanics calculations.


I and the Cast3M team, would be very grateful if you accept to add the 
GIBIANE native support to the official Geany version.


If you have any questions or suggestions, please come back to me.


Just an observation: this has to be the first time ever to encounter a 
programming language that replaces the usual English keywords with 
french ones:


SI ((VALEUR DIME) EGA 2)
   SI (EXISTSE TAB1 < PLAN);
     IPLAN = TAB1.

It's apparently quite common (or was anyway):
https://en.wikipedia.org/wiki/Non-English-based_programming_languages

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

Re: [Geany-Devel] New language in Geany

[Matthew Brush]

On 2019-08-01 12:41 a.m., KK2000 wrote:

Dear Geany developers,

I have developed a version of the Geany with native support for the GIBIANE 
language. The git patch is attached and has been tested with the latest version 
of Geany (commit 9c91c287803ae05ce0f2aacd605564301e0ef4aa).

What is the GIBIANE language ?
   The GIBIANE language is the language to control the Cast3M Software.
   Cast3M ( http://www-cast3m.cea.fr/ ) is a finite element software for 
structural and fluid mechanics.
   It is developed by the Department for Modelling Systems and Structures 
(DM2S) from the French Alternative Energies and Atomic Energy Commission ( CEA 
http://www.cea.fr/english ), and it is widely used around the world.
   In Cast3M, the user have access to all source code that control algorithms 
for mechanics calculations.

I and the Cast3M team, would be very grateful if you accept to add the GIBIANE 
native support to the official Geany version.

If you have any questions or suggestions, please come back to me.



Nice work! We usually do pull requests on Github these days since it's 
harder to get lost and easier to see the individual changes than one big 
patch. Would it be possible to open a pull request on Github for this?


If the language is reasonably popular, it seems likely nobody would 
object to including it into core.


One thing with Geany is that the project has a policy of upstreaming 
changes to the libraries/other projects it uses, so new Ctags parsers 
and Scintilla lexers get merged upstream and then get pulled back down 
into Geany. This makes sure we don't hoard contributions as well as 
facilitates synchronizing the code between projects.


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

Re: [Geany-Devel] Windows: Webkit-related plugins are going to be removed

[Matthew Brush]

On 2018-11-25 9:22 a.m., Enrico Tröger wrote:

Hi,

I'm afraid we need to remove the Webkit-related plugins (Webhelper,
Markdown Preview) from the Windows installer.


This is because Webkit itself is going to be removed from MSYS2:
https://github.com/Alexpux/MINGW-packages/issues/4318

For the upcoming release we could ship the previous version of Webkit
along with the locally cached old version of ICU (i.e. we will ship ICU
61 *and* 62 in the installer).

But I personally would prefer removing the plugins from the Windows
installer immediately for the reasons mentioned in
https://github.com/Alexpux/MINGW-packages/issues/4318#issuecomment-436443226
and to prevent us from shipping two ICU versions which bloats the
Windows installer even more.


If there are no objections, I will remove all Webkit-related settings
from the Windows installer next week.



Hi,

It would be nice to keep these plugins as long as practical, but I don't 
feel strongly about it.


Once removed, we should make an Issue on Github for all affected users 
to make duplicates of :) I think we got at least a dozen or so bug 
reports when the webkit-using plugins were removed from one of the Linux 
distros.


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

Re: [Geany-Devel] Moving away from Github

[Matthew Brush]

On 2018-06-06 01:53 AM, Mark O'Donovan wrote:

Hi,

Regarding https://github.com/geany/geany/issues/1870

What are people's thoughts on transitioning away from GitHub?

I personally have given GitHub a free pass up to now due to the benefits 
they were providing to the FOSS community. Following the Microsoft 
buyout I no longer wish to do so and have moved all repositories I 
control to GitLab. I am considering closing my GitHub account altogether 
and will be considerably more likely to contribute to GitLab projects in 
future. In this i'm sure that I am not alone.


I also think that Geany, as a Free and Open Source Software program, 
should be hosted on a FOSS repository management site. The same open 
source arguments that we use to promote Geany apply here.




What changes with the new ownership? As I understand it, the website is 
to remain free for open source projects, is still proprietary software, 
and is still owned by an (albeit massively larger) for-profit corporation.


At the very least I think the gitlab.com/geany project domain should be 
claimed and mirrored.




That seems reasonable, as long as the bug tracker and pull requests and 
such can be disabled, and the mirroring can be automated.


Regards,
Matthew Brush

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

Re: [Geany-Devel] Scintilla Use

[Matthew Brush]

On 2018-03-21 09:04 PM, Lex Trotman wrote:

I would think by the time older LTS distros are up to C++17, that
Scintillua/LongTerm3 will have no reason to exist anymore.


Old LTS will never get it, thats why they are called "stable", what I
meant is the next LTS, for example Ubuntu is scheduled to release a
new LTS next month which will have gcc7 in its repositories even if it
uses gcc 6 by default.



Yeah, I mean by the time those currently new LTS distros with C++17 are 
the old lowest common denominator LTS distros we support - in the future.


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

Re: [Geany-Devel] Scintilla Use

[Matthew Brush]

On 2018-03-21 08:01 PM, Lex Trotman wrote:

On 22 March 2018 at 10:35, Matthew Brush <mbr...@codebrainz.ca> wrote:

Hi,

Going forward, are we going to use the Scintilla LongTerm3 branch or v4.x
releases?


Interesting question.  I had been assuming that once Neil settled it
down and after the next round of LTS Linuxen were released with C++17
(at least in the repos if not by default) we would go with Scintilla
4, but so far I havn't seen any changes there that excite me greatly.



I would think by the time older LTS distros are up to C++17, that 
Scintillua/LongTerm3 will have no reason to exist anymore. IIUC it's 
only the new maintainer of that branch needing to stick to C++11 for his 
own project(s) for now and so can't use the tip of Scintilla code. I 
assume that eventually the goal is to have Scintillua into the mainline 
or some future external library containing all of Scintilla's lexers 
(see scintilla-interest mailing list).




If LongTerm3, is there any opposition to integrating the new LPeg lexer so
we can use/write lexers in Lua/PEG? I might be interested in working on this
if it's not going to be controversial.


The downside to this is that we are then stuck on 3 until Mitchell
ports Scintillua to 4, and if its in his Scintilla LTS 3 tree he has
no incentive to port it to 4.  And once its made available in Geany it


See above.


can't be removed.  Even if technically it can be removed, once people
start using it there will be no going back.



Well yeah, but if one of our dependencies breaks, we break; be it 
Scintilla or GTK+ or whatever.



And it makes Geany depend on Lua.



Meh, it's small, stable and well maintained. I could imagine it being 
used for other stuff too, like maybe a core proxy plugin for first class 
Lua plugins.



And does it compile Lua in, distros will probably not like that?



It can be embedded or linked against a dynamic library, selected at 
build-time. This is easy to do in the build system.



And will the Lua plugin still work given it has another copy of Lua.



Should work fine. If the Lua versions are compatible, the plugin could 
even detect and optionally use the version inside Geany (if we exported 
it), its own, or some external dynamic library.


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

[Geany-Devel] Scintilla Use

[Matthew Brush]

Hi,

Going forward, are we going to use the Scintilla LongTerm3 branch or 
v4.x releases?


If LongTerm3, is there any opposition to integrating the new LPeg lexer 
so we can use/write lexers in Lua/PEG? I might be interested in working 
on this if it's not going to be controversial.


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

Re: [Geany-Devel] GTK version policy

[Matthew Brush]

On 2018-02-23 11:53 AM, Lars Paulsen wrote:

Hello All,

I have ported the scope plugin to GTK3.
During that work I also noticed some deprecation warnings for the 
workbench plugin which I did create not long ago

and as suggested by the HACKING file I did write it for GTK2.

If I port a plugin to GTK3 should it still support GTK2?
Should we change the HACKING file regarding the preferred GTK version to 
prevent people from writing new plugins based on GTK2?




Hi,

For the average plugin with minimal dependencies I would recommend to 
support both since it's so easy. You can put all of your version 
specific stuff into a single compatibility header (and/or re-use 
Geany's) so you don't need to litter your code with #ifdef stuff very much.


Most distros, as well as the Windows and MacOS releases are still 
shipping the GTK+2 version of Geany/Geany-Plugins and it's the build 
system default as well, so if you care about supporting a wide user 
base, supporting both versions is a good idea.


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

Re: [Geany-Devel] Create project files from within a plugin

[Matthew Brush]

On 2018-02-18 10:52 AM, Lars Paulsen wrote:

Hi All,

is there a API for plugins which lets a plugin create project files and 
fill in some values?


I do NOT want to add plugin specific data to an existing project.

I want to create a new project with some meaningful data (the 
fields/values of geany's own project data).

After that I would add plugin specific data to it.



Hi,

There is nothing in the API for this as far as I know. You could just 
write your own keyfile, and open that. If you wanted to open it 
programmatically you would have to expose a function like maybe 
`project_load_file_with_session`[0] in the plugin API.


Regards,
Matthew Brush

[0]: https://github.com/geany/geany/blob/master/src/project.c#L268
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

[Geany-Devel] [RFC]: Adding Filetype Extensions

[Matthew Brush]

Hi,

There are quite a few Issues/Pull Requests on Github about adding more 
extensions to `filetype_extensions.conf` so various types of files are 
detected/colourized/symbolized properly out of the box.


IMO, we need a policy/guidance on what is acceptable. The way I see it 
there are a few ways we could handle it:


1) Add all filetype extensions possible as long as there's proof 
somewhere they actually exist/are used.


2) Add only popular, generic ones, for example JSON or YAML or actual 
programming languages supported by Geany.


3) Don't add anymore except when adding entirely new filetype support; 
the `filetype_extensions.conf` file is user-editable precisely for this 
reason.


I don't really have an opinion on this, but it would be helpful to have 
some kind of consensus/policy on it, for the purposes of triaging Issues 
and Pull Requests on Github.


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

Re: [Geany-Devel] How can a plugin invoke menu items/geany actions?

[Matthew Brush]

On 2017-12-20 01:37 PM, Lars Paulsen wrote:

Hi All,

I would like to start actions in geany from inside a geany plugin?

E.g. start the Color Chooser as if it was selected from the geany tools 
menu.
I tried to call the callback function directly but that gives an linker 
error for geany plugins (just logical).


Can I fire/send an event/message to make it being started? How do I do 
that?




If you happen to find one that's not available as a keybinding command, 
you can also use `ui_lookup_widget()` to get a handle on the menu item 
and then activate it through code (ie. `gtk_actionable_activate()` or 
something). This is kind of brittle, but it does work.


Regards,
Matthew Brush

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

Re: [Geany-Devel] document_open_file

[Matthew Brush]

On 2017-10-25 12:47 PM, Lars Paulsen wrote:

Hi,

if I open a document via document_open_file() will it also be opened if 
it is already opened?
So, do I need to check myself if a file is already open to prevent it 
from being opened again?




No you don't need to check, it's done internally in 
`document_open_file_full` (which is called by `document_open_file`).


https://github.com/geany/geany/blob/master/src/document.c#L1323

Regards,
Matthew Brush
___
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

[Matthew Brush]

On 2017-06-25 03:07 PM, Abel wrote:



Which configuration in detail did you expect to be updated?



The filetypes files which contain the keywords definition for each
language. In particular, I was expecting to get the new keywords of python3
highlighted once I updated Geany, but it didn't...



Hi,

What would you expect to happen if you had added your own custom 
keywords in the filetypes file and Geany was to update it with the new 
Python 3 keywords?


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

Re: [Geany-Devel] Plugin interface

[Matthew Brush]

Am I the only one not getting Lars' messages? I looked in my Junk folder 
and they're not there, wondering if it's a misconfiguration on my end or 
something?


Regards,
Matthew Brush

On 2017-06-21 04:39 PM, Lex Trotman wrote:

Hi,

The plugin system has recently been updated but was made backward
compatible, so all the old plugins still run.  So that removed any
incentive for the plugin maintainers (and Geany devs for the core
plugins) to update, so as you say most still use the old system.

The new system supports sub-plugins properly, but the developer who
was working on it has had an attack of the real world and the code
supporting it (at least for Python IIUC) is still in his personal
github.  It may also be able to be extended to other languages such as
JS.

Cheers
Lex

On 22 June 2017 at 03:37, Lars Paulsen <lars_paul...@web.de> wrote:

Hi all,

I got a simple question:
As I understood from the development manual plugins should use
geany_load_module() instead of plugin_init()...

Is that correct?
I am just wondering because it seems that 90% of the geany plugins use
plugin_init() and co.

Kind Regards,
Lars


___
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



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

Re: [Geany-Devel] CodeAi Fixes a Null Pointer Dereference

[Matthew Brush]

On 2017-05-11 01:34 PM, Benjamin Bales wrote:

ok, I'll submit a PR with some of the fixes that I think are good.  Was the
format of the bug report acceptable?  Our tool integrates with static
analyzers, and sometimes its tricky to include their reports in a way that
is clear and concise.  Of course, I will provide my own summary of the
issues, but I would like to know if you found them helpful.



It seems OK, though I just looked for the file/line info and studied 
what the code did, I didn't notice the PNG attachment until afterward. 
It reminds me a bit of clang static analyzer html/xcode output but 
without the fancy arrows.


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

Re: [Geany-Devel] CodeAi Fixes a Null Pointer Dereference

[Matthew Brush]

On 2017-05-10 04:09 PM, Lex Trotman wrote:

On 11 May 2017 at 08:10, Benjamin Bales <benjamin.ba...@qbitlogic.com>
wrote:


CodeAi (https://github.com/C0deAi), an automated repair tool developed at
QbitLogic (www.qbitlogic.com), suggested the following fix. Could I
submit it as a patch if it looks alright?

plugins/saveactions.c: “doc->file_type” pointer might be dereferenced when
null on line 283.  Initialization may be provided by “doc” passed in as a
function argument, but a null check would be prudent just in case. The fix
checks “doc->file_type” for null before allowing a dereference on the
following line.  A snapshot of the bug report generated by CodeAi is
attached.  A full report is available upon request.



This function is called (via the signal framework) by the function that
created `doc` and as such cannot be null.  The design of the application
uses the signal framework to decouple caller and callee and this is likely
to confuse your tool since it cannot see where functions are called.
Whilst any contributions are welcome, a report with a lot of similar false
positives may end up being ignored and be a bad advertisement for your tool.



Naw, I think it's technically a real bug, albeit very minor. It's the 
`file_type` member of the `doc` that can be NULL. IIUC tools like this 
look to see if you checked the NULL-ness of something and then proceed 
to dereference it outside of that check later, which this code does 
(checks if `ft == NULL` several lines up and then unconditionally 
dereferences it on the line given by the OP).


Regards,
Matthew Brush

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

Re: [Geany-Devel] CodeAi Fixes a Null Pointer Dereference

[Matthew Brush]

On 2017-05-10 03:10 PM, Benjamin Bales wrote:

CodeAi (https://github.com/C0deAi), an automated repair tool developed at
QbitLogic (www.qbitlogic.com), suggested the following fix. Could I submit
it as a patch if it looks alright?

plugins/saveactions.c: “doc->file_type” pointer might be dereferenced when
null on line 283.  Initialization may be provided by “doc” passed in as a
function argument, but a null check would be prudent just in case. The fix
checks “doc->file_type” for null before allowing a dereference on the
following line.  A snapshot of the bug report generated by CodeAi is
attached.  A full report is available upon request.

diff --git a/plugins/saveactions.c b/plugins/saveactions.c

@@ -280,8 +280,10 @@ static void instantsave_document_new_cb(GObject *obj,
GeanyDocument *doc, gpoint



  doc->file_name = new_filename;



- if (doc->file_type->id == GEANY_FILETYPES_NONE)

+ if(doc->file_type) {

+if (doc->file_type->id == GEANY_FILETYPES_NONE)

  document_set_filetype(doc,
filetypes_lookup_by_name(instantsave_default_ft));

+ }



  /* force saving the file to enable all the related actions(tab name,
filetype, etc.) */

  document_save_file(doc, TRUE);

/* force saving the file to enable all the related actions(tab name,
filetype, etc.) */

document_save_file(doc, TRUE);

}

}

Base-commit: 84253714771f48dbc7fab02f7de43f253734dee2

Please let me know if you are interested in seeing more fixes from our
tool. Thanks!



Hi,

You can submit pull requests with properly formatted changes on Github. 
We've had a few PRs like these where analysis tools were run over the 
codebase and found issues (ex. see PR #166 & #186). If there are 
multiple trivial changes, it's probably fine to put it all in one PR as 
separate commits.


Regards,
Matthew Brush

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

Re: [Geany-Devel] Adding SystemVerilog Parser

[Matthew Brush]

On 2017-05-03 08:15 AM, Joshua A. Einstein-Curtis wrote:

To be more precise, is there a reason we aren't instead pulling ctags as a git 
submodule?



Geany's CTags fork is based off of Exuberant CTags from many years ago 
and was heavily modified (by others, anjuta etc) to make it into a 
library IDEs can use for tagging. Many of the parsers were modified in 
Geany without changes being upstreamed, as upstream is basically dead.


There's been a fair bit of work in synchronizing Geany's fork with 
universal-ctags code, with the end goal of being able to use it as a 
submodule or direct copy of upstream in whatever fashion. There's still 
more work to do though.


Regards,
Matthew Brush

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

Re: [Geany-Devel] Adding SystemVerilog Parser

[Matthew Brush]

On 2017-05-03 08:09 AM, Joshua A. Einstein-Curtis wrote:

Thank you!


It looks like Geany's Verilog parser is out of date. compared with those. How 
often does Geany push in updated ctags parsers?




I don't think all parsers are updated to universal-ctags, probably quite 
a few still come from exuberant-ctags. It would be welcome if you'd like 
to contribute your fixes to universal-ctags and then sync Geany's parser 
with that, maybe diffing Geany's parser against exuberant-ctags' to see 
if we added anything useful that never got upstreamed.


Regards,
Matthew Brush


Josh E-C


From: Devel <devel-boun...@lists.geany.org> on behalf of Lex Trotman 
<ele...@gmail.com>
Sent: Wednesday, May 3, 2017 10:03:48 AM
To: Geany development list
Subject: Re: [Geany-Devel] Adding SystemVerilog Parser

Hi,

If you mean the parsers in the ctags/parsers directory, those come
from the Universal Ctags project
https://github.com/universal-ctags/ctags so you should probably start
by asking there.

Cheers
Lex

On 3 May 2017 at 23:23, Joshua A. Einstein-Curtis <jeins...@fnal.gov> wrote:

Hi Geany developers,


I'm locally am updating the Verilog parser/creating a SystemVerilog parser
with updated keywords and kinds. I don't know if anyone has already started
this, but if so, I'd be interested in working off of a base.


Do we have a standard for changing file headers while still attributing
original file creation correctly?


Josh Einstein-Curtis


___
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



___
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] Helping Geany move forward: testing

[Matthew Brush]

On 2017-04-28 06:35 PM, Lex Trotman wrote:

...


Geany is almost entirely an interactive application, so until
interactive tests are possible I don't think technical tests like
these will add a great deal to the committability of PRs.



If the tests just test functions, all it needs is to get Geany started up,
then the tests can call the new/changed functions testing with different
inputs and such. There are at least two PRs to do similar.


Sadly Geany isn't a pure functional program, most functions leave
messy side-effects on global data, the Scintilla buffers :(

So you need to be able to examine those.




You can, the tests are just regular extra functions called at runtime, 
you have access to all state that normal code does, it just makes it 
more trouble to setup/assert that state. When you have this in mind 
while writing a test for the new/changed function, you're more likely to 
make it more "pure" and single-task specific. The end result is better 
code and more testable code, which would gradually spread through parts 
of the codebase.





Clangalizers and sanitizers and formatters won't tell you that the PR
actually puts 'z' in the buffer instead of 'a'.



No, but they'll catch a number of runtime bugs that are often hard to
identify upon basic code inspection or manual testing.


Perhaps Columban knows more about using the accessibility framework
for testing now Scintilla supports it?



There are several UI testing frameworks that work with GTK+, though I've not
used any: autopilot, dogtail, and LDTP.

I don't think we really need fully automatic UI testing (seems like too much
work), but we could get a long way just testing at the function level,
ensuring functions uphold their contract and flexing them with unusual
inputs. Making a testable function usually means writing it better too,
avoiding global state and writing more "pure" functions, and making
functions do one thing and not writing huge functions or many small
functions.


We really NEED automatic UI testing and we NEED function unit testing,
but realistically we are not going to get either.  If we don't have
enough resources to just run and test PRs we don't have the resources
to add these.



The contributors add the tests flexing the PR changes, giving the person 
merging the change more confidence and less reason to test every little 
corner case themselves, and are automated and repeatable to ensure the 
assumptions those tests make are not broken by other changes in the 
future. Instead of as the OP suggested, writing up a prose testing 
report by hand, they just write a test function that tests the 
assumptions they have checked, also showing missing assumptions.


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

Re: [Geany-Devel] Helping Geany move forward: testing

[Matthew Brush]

On 2017-04-28 05:35 PM, Lex Trotman wrote:

On 29 April 2017 at 09:55, Matthew Brush <mbr...@codebrainz.ca> wrote:

On 2017-04-28 02:35 PM, Thomas Martitz wrote:


Am 27.04.2017 um 22:51 schrieb Vasiliy Faronov:


Hi all,

 From discussions elsewhere, such as [1], it sounds like one of the
things holding back Geany development right now is a need for more
testing.



Helping to test PRs is truly needed, and much appreciated.

However, I do think that Geany lacks also actual developers that cna
merge stuff. I feel the current team is afraid of merging non-trivial
changes, leaving even semi-complex patches to Colomban. Unfortunately
Colomban has little time these days, too, so we're kind of stuck. There
are lots of PRs that have recent activity from the authors and are
tested appropriately but still don't get attention from developers.



My general problem is that we don't have a unstable/development branch per
se, nor proper automated testing, and I don't want to break master so I
won't merge a single thing without testing it thoroughly myself. This can
turn a 5-10 minute merge into a several hours or more testing session,
requiring special setups and re-compiling Geany on 3 different OSes, etc.


I have to agree with Matthew that:

1. Nobody wants to break master because its what everybody is using.
Problem is that if we had a development branch nobody would be using
it because it might break, so its insufficiently tested.  I don't have
a solution to that.

2. I am more willing to accept others testing and to make a judgement
call about testing on all platforms.  I have used that approach
successfully on other projects where I couldn't personally test some
configurations.  But I understand where Matthew is coming from
regarding the amount of work to do a good testing job.

3. A thorough test is becoming too big a job, and that is even worse
for the more complex PRs that Thomas mentions.  Simply don't have the
time.  And for changes to the plugin interface that need a plugin to
test, well, unless the OP provides such a plugin, it just isn't going
to happen.



Travis CI is great, but unless it can run make check with loads of static
analysis and runtime analysis while it runs unit tests and such, it's
basically just saying the code compiles. As we all know, it's relatively
easy to make C code that compiles but crashes horribly at runtime in weird
corner cases (off by one, null deref, etc.).

Personally I'd feel a lot better merging PRs I haven't thoroughly tested if
we had:

  - Clang static analyzer during the build
  - A Git hook or manual use of clang-format or other formatter to prevent
the "extra white space" or "wrong comment style" type of issues that
commonly occur in PRs.
  - Ability for PRs to come with tests (requires testing support).
  - Linking in Clang's address & memory sanitizers while running all of the
tests.


Geany is almost entirely an interactive application, so until
interactive tests are possible I don't think technical tests like
these will add a great deal to the committability of PRs.


If the tests just test functions, all it needs is to get Geany started 
up, then the tests can call the new/changed functions testing with 
different inputs and such. There are at least two PRs to do similar.



Clangalizers and sanitizers and formatters won't tell you that the PR
actually puts 'z' in the buffer instead of 'a'.



No, but they'll catch a number of runtime bugs that are often hard to 
identify upon basic code inspection or manual testing.



Perhaps Columban knows more about using the accessibility framework
for testing now Scintilla supports it?



There are several UI testing frameworks that work with GTK+, though I've 
not used any: autopilot, dogtail, and LDTP.


I don't think we really need fully automatic UI testing (seems like too 
much work), but we could get a long way just testing at the function 
level, ensuring functions uphold their contract and flexing them with 
unusual inputs. Making a testable function usually means writing it 
better too, avoiding global state and writing more "pure" functions, and 
making functions do one thing and not writing huge functions or many 
small functions.


Regards,
Matthew Brush

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

Re: [Geany-Devel] Helping Geany move forward: testing

[Matthew Brush]

On 2017-04-28 02:35 PM, Thomas Martitz wrote:

Am 27.04.2017 um 22:51 schrieb Vasiliy Faronov:

Hi all,

 From discussions elsewhere, such as [1], it sounds like one of the
things holding back Geany development right now is a need for more
testing.


Helping to test PRs is truly needed, and much appreciated.

However, I do think that Geany lacks also actual developers that cna
merge stuff. I feel the current team is afraid of merging non-trivial
changes, leaving even semi-complex patches to Colomban. Unfortunately
Colomban has little time these days, too, so we're kind of stuck. There
are lots of PRs that have recent activity from the authors and are
tested appropriately but still don't get attention from developers.



My general problem is that we don't have a unstable/development branch 
per se, nor proper automated testing, and I don't want to break master 
so I won't merge a single thing without testing it thoroughly myself. 
This can turn a 5-10 minute merge into a several hours or more testing 
session, requiring special setups and re-compiling Geany on 3 different 
OSes, etc.


Travis CI is great, but unless it can run make check with loads of 
static analysis and runtime analysis while it runs unit tests and such, 
it's basically just saying the code compiles. As we all know, it's 
relatively easy to make C code that compiles but crashes horribly at 
runtime in weird corner cases (off by one, null deref, etc.).


Personally I'd feel a lot better merging PRs I haven't thoroughly tested 
if we had:


  - Clang static analyzer during the build
  - A Git hook or manual use of clang-format or other formatter to 
prevent the "extra white space" or "wrong comment style" type of issues 
that commonly occur in PRs.

  - Ability for PRs to come with tests (requires testing support).
  - Linking in Clang's address & memory sanitizers while running all of 
the tests.


Just some thoughts.

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

Re: [Geany-Devel] introducing myself

[Matthew Brush]

On 2017-04-17 06:20 AM, Attila wrote:

Hi,

my name  is Attila from Hungary. My profession is electronic mechancian,
but my job is C/C++ developer nowadays. You can look at my LinkedIn
profile here:
https://www.linkedin.com/in/attila-v%C3%A9ghelyi-31597551/, and you
can visit my home page too: http://veghelyiattila.hu

I'd like to add a new feature to geany, because it's very lack for me.
This is the 'Reaload all', which is very usefull i.e. when I change the
git branch in the background terminal (and many files are open).

The code is almost ready (there is no code, which is totally ready :) ),
I must try it on Windows for example.



Hi Attila,

Welcome. I think this would be a useful feature, at least myself I have 
also wanted this many times also, whether for Git as you said or because 
of also using QtCreator at the same time as Geany (it has a fantastic 
graphical debugger).


When your change is ready, please make a pull request on Github. It's 
unlikely to be controversial and has a good chance of being merged if 
it's done well.


Please see also the issue below as it relates to, and may obviate or at 
least minimize the need for 'Reload All' for our use case:


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

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

Re: [Geany-Devel] New Direction for Geany

[Matthew Brush]

On 2017-03-31 06:25 PM, Lex Trotman wrote:

[...]

2) Eeany should embrace the bloat, incorporate the whole operating
system like Emacs and become an overblown interfering annoyance like
Eclipse,



Instead of something minimal like Elisp for scripting, it might be 
useful to use Clojure, because JVM is awesome and only adds a couple 
hundred megabytes to the release and 20 seconds of startup time.


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

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

[Matthew Brush]

On 2017-03-05 02:37 AM, Matthew Brush wrote:

On 2017-03-01 02:10 PM, Enrico Tröger wrote:

Hi,

here are new Windows installers for testing.
They are built from GIT master.

I could not do any thorough testing yet, just built the installers and
tested they are working on a first glance.

There are no big changes regarding the Windows platform as far as I can
tell. But the included libraries are up2date with latest MSYS2 and the
included "grep" binary is now at version 3.0.


Any feedback is very welcome.

Geany and Plugins downloads:
http://download.geany.org/snapshots/geany-1.30nightly20170301_setup.exe
http://download.geany.org/snapshots/geany-plugins-1.30nightly20170301_setup.exe





Works OK for me on a Win7 Pro machine.

Only observations are:

- Still 32-bit, why not using msys2 in 64-bit mode?
- The known slow webkit plugin loading issue, it took 30-60 seconds here
- In the installer for GP, the "configure components" page, the
description for Dependencies checkbox is very long and the window isn't
resizable so the text gets cut off.

Other than those (non-critical) issues, it looks great!



Oh also, and this will probably be done before release anyway, but the 
copyright date is still 2016 on the installer .exes and the geany.exe 
when you look in the Properties->Details tab in Windows.


Regards,
Matthew Brush

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

Re: [Geany-Devel] Storing per-project settings for plugins

[Matthew Brush]

On 2017-02-16 03:15 AM, Thomas Martitz wrote:

Am 16.02.2017 um 11:58 schrieb Vasiliy Faronov:

Jiří, Matthew, thanks!

I missed the GKeyFile thing.

Actually, my plugin is written in Python (via Geanypy), and doesn't
get the GKeyFile on project-open/project-save. Probably because there
are no Python bindings for it.

But I guess Python's built-in ConfigParser should be enough.


Geanypy is not actively developed at this time. Let me suggest to give


What does that mean? It's not 100% perfect, but it does what it's 
intended to do quite well. Should we just start committing random 
changes so it's "actively developed"?


Regards,
Matthew Brush
___
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

[Matthew Brush]

On 2016-11-13 04:44 PM, Dominic Hopf wrote:

Greetings,

just for completeness a short info here: I've managed to built the Plugins
package with temporarily disabling devhelp, markdown and webhelper. [1]

It'd be great if someone will be able to port stuff to WebKit2 or,
alternatively, if you think I've missed something point me to the correct
clue.



Devhelp plugin uses webkit indirectly via libdevhelp, if that matters. I 
started updating it some years ago[0] but got bored with constant API 
churn in dependencies. If anyone wants to update it, feel free.


Markdown plugin can probably be upgraded fairly painlessly.

Regards,
Matthew Brush

[0]: https://github.com/geany/geany-plugins/pull/92/files
___
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

[Matthew Brush]

On 2016-11-11 03:24 PM, Matthew Brush wrote:

Hi All,

I was seeking help for some issue for the Markdown plugin with WebKitGtk
today on IRC and someone pointed out this issue with Fedora:

https://bugzilla.redhat.com/show_bug.cgi?id=1375807

Basically the whole Geany-Plugins package will be removed since one of
the plugins uses an older version of a library that will be removed from
Fedora.

IMO, it would be wise to separately package plugins to prevent one
outdated plugin from getting the others removed. AFAIK this is how it's
packaged on Debians.



Actually according to the mailing list post (with a quite annoying tone) 
linked from the bug report, it lists:


geany-plugins-devhelp-0:1.27-1.fc24.x86_64
geany-plugins-geanypy-0:1.27-1.fc24.x86_64
geany-plugins-markdown-0:1.27-1.fc24.x86_64
geany-plugins-webhelper-0:1.27-1.fc24.x86_64

So perhaps Fedora does package them separately? The fellow on IRC said 
all of Geany would be removed, so I'm a little confused. Also I'm not 
sure why GeanyPy is listed, it doesn't use Webkit at all and Devhelp 
plugin uses it indirectly through libdevhelp.


The other thing is that none of the plugins really use general WWW 
untrusted code, but rather just whatever the user is working on (ie. 
Devhelp docs, HTML generated from Markdown, their own HTML files). I 
guess these are more "special flowers" as the OP so politely put it.


Anyway, we could indeed upgrade to the newer version if we want to 
re-write the affected plugin code, drop gtk2 support and stop being able 
to work on Windows. Probably using conditional compilation to support 
both is the way forward for the immediate future. I guess for Fedora, 
they'll have to either enable GTK3 build (and lose a bunch of unported 
plugins) or stay with GTK2 build (and lose any old Webkit-using plugins).


Regards,
Matthew Brush
___
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

[Matthew Brush]

I should note that current Markdown plugin appears to work with old or 
new WebkitGtk versions, let me know if there's something else I should do.


Regards,
Matthew Brush

On 2016-11-11 03:24 PM, Matthew Brush wrote:

Hi All,

I was seeking help for some issue for the Markdown plugin with WebKitGtk
today on IRC and someone pointed out this issue with Fedora:

https://bugzilla.redhat.com/show_bug.cgi?id=1375807

Basically the whole Geany-Plugins package will be removed since one of
the plugins uses an older version of a library that will be removed from
Fedora.

IMO, it would be wise to separately package plugins to prevent one
outdated plugin from getting the others removed. AFAIK this is how it's
packaged on Debians.

P.S. It is my Markdown plugin that is threatening the removal of the
entirety of Geany-Plugins (upgrade patches welcomed).

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


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

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

[Matthew Brush]

Hi All,

I was seeking help for some issue for the Markdown plugin with WebKitGtk 
today on IRC and someone pointed out this issue with Fedora:


https://bugzilla.redhat.com/show_bug.cgi?id=1375807

Basically the whole Geany-Plugins package will be removed since one of 
the plugins uses an older version of a library that will be removed from 
Fedora.


IMO, it would be wise to separately package plugins to prevent one 
outdated plugin from getting the others removed. AFAIK this is how it's 
packaged on Debians.


P.S. It is my Markdown plugin that is threatening the removal of the 
entirety of Geany-Plugins (upgrade patches welcomed).


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

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

[Matthew Brush]

On 2016-09-01 01:55 AM, Thomas Martitz wrote:

Am 01.09.2016 um 07:47 schrieb Matthew Brush:

On 2016-08-31 10:08 PM, Thomas Martitz wrote:

Am 31.08.2016 um 17:26 schrieb Lex Trotman:

I think we all agree that help of language-specific plugins is
desired/required. No need to restate "we need language specific
support" all
the time.

We just disagree on how the language-specific knowledge is
transported to
Geany, other plugins and the user.


Well, I read your previous comments such as "But *just* the data,
don't offload very specific use cases onto them" (and to some extent
this one too) as saying that all the plugin has to do is return some
data (tags) and Geany will take it from there and all I was doing was
making sure it was clear that its unlikely that Geany will be able to
"take it from there" in any meaningful way, based purely on data,
without filetype specific knowledge inside Geany.


Here we disagree. I think it is possible to extent TM/Geany sufficiently
to encode this information in generic ways. As an example, template
instantiation yields different types. TM could tread them as different
types. Any variable will be of one of the types, so calltips would just
work.



Let's use the simplest C example:

gint x = g_...

Please describe the algorithm (just in prose) that would give only the
valid completions (ie. would compile in a C compiler) for `g_...`
without providing any impossible completions, and without knowing
anything about C/C++/Obj-C.


Do you suggest the completion list would only contain function that
return gint?



Could be that, or it could be as simple as not listing things which 
aren't in scope or visible (say an #include is missing). What I was 
getting at is that unless you describe Geany's current algorithm, you'll 
almost surely start describing C/C++/Obj-specific semantics encoded 
inside Geany.



[...]

So, as for the algorithm, I'd really stick to prefix matching, as done
currently. Everything else assumes that I coded everything correctly
which is not always the case. I don't want to be auto completion to be
too smart and hide wanted functions.



Ok, I see where the problem is. You seem to only want the current 
functionality while I want to enhance it to be more in-line with the 
type of smarts you get in real IDEs that have deep knowledge of your 
code and programming language. So if this is the case you're 
fundamentally not going to like any features ft-plugins provide, and I 
suggest that you just not use them. The point of adding all this in 
plugins is specifically so you don't have to :)


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

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

[Matthew Brush]

On 2016-08-31 11:42 PM, Thomas Martitz wrote:

Am 01.09.2016 um 07:17 schrieb Matthew Brush:

On 2016-08-31 09:57 PM, Thomas Martitz wrote:

Am 01.09.2016 um 02:50 schrieb Matthew Brush:


I don't think they'll usually require a "build system" per se, but
they definitively need to be told how to compile the code where
applicable.

For libpython, I don't think it needs any flags. For libvala IIRC and
libclang (if not using compile_commands.json) they require the `argv`
you'd pass to the compiler itself. It may very well be possible for
ft-plugins using libraries with the `argv` approach to just grab the
compile command from Geany's build commands and convert it back into
an `argv` array or something.


Not sure how you use Geany, but I never set the cc command line for
individual files. I never type CFLAGS or CXXFLAGS into Geany's build
settings.



Yeah, that's why the absolute base functionality provided must always
exist. I'd probably be more willing to do a little setup for actual
projects if there was a benefit though.


Actually most of the time I don't set up the build system at all and
alt-tab to a terminal where I use my employers crazy build system which
uses make under the hood but can't be used from within Geany properly.



This use-case should continue to be the default supported one.


But this can't be supported by a libclang ft-plugin, can it? Are you
suggesting the default use-case bypasses the ft-plugin? That seems weird
to begin with.



It could fall-back to the default functionality if no ft-plugin performs 
a given feature.





Then, some other time (e.g. for compiling Geany) I sometimes use the
make command. But obviously Geany only knows that running "make" builds
something. It doesn't have enough information to construct a compiler
command line.



Indeed. To provide "real IDE" features and project requires more than
what Geany provides out of the box. I haven't really proposed a design
for this, so as it stands ft-plugins would have to provide some means
(ex. advanced project support, compile_commands.json, custom GUI, etc)
to get this info from the user.


A solution for this should be part of the discussion, otherwise we're
going end up with a dozen completely ways and UIs configure ft-plugins.
Which is going to be a PITA for users if the ft-plugins have to be
regularly reconfigured on a per-project basis.



It's going to be plugin/language specific anyways. I agree it should be 
considered eventually, but it's not required to provide basic hooks for 
ft-plugins to start providing some features.





Some other time again I'm working on cross compiled projects. Here I
again don't usually use Geany's build system support, but if I would it
would run (e.g.) avr-gcc, with avr-gcc specific compiler flags, not
known to clang (is there even a clang port for avr? I don't think so).



For an example libclang plugin, clang would have to be able to parse
the source. It would require valid C/C++/Obj-C code for sure (though
IIRC some of the helper functions for IDEs/tools handle partial source
files or simple lexing to handle on-the-fly IDE highlighting and such).


So a ft-plugin that only works if a file can be compiled is likely to be
unworkable for me. It needs to deal with when it can't build the source
files (either because of lacking *FLAGS or because the target isn't
supported by the compiler). Likewise, if a ft-plugin only supports x86
(i.e. is arch dependent) it's not interesting to me.



If your code can't be (cross) compiled, I'm afraid you're screwed anyway :)

For some stuff, like partial code (ex. you're still typing it) or 
guarded out by platform macros, I'd expect some some reduced 
functionality, or different behaviour, at least.


To test it out, just try a competent full-fledge IDE such as QtCreator, 
Visual Studio, XCode, or Eclipse (among many others) and see what it does.




For actual projects you would work on for a while, it would be worth
setting up some meta-stuff.


I'm afraid I won't be able. The CFLAGS depend on the source file I edit.
There are multiple projects involved (e.g. Linux kernel and user space),
there is not just the One Project.



If you can't describe your build, yeah it's not so useful.


The more I'm thinking about it...if key functionality depends on being
able to compile the file, I won't be able to use a libclang based
ft-plugin.



In order to provide "smart" features requires to understand the code. If 
you can't describe your build and make a regular c/c++/obj-c (cross) 
compiler able to handle your code, I'm afraid at least my CDK/libclang 
ft-plugin indeed wouldn't be of use to you. Doesn't mean others used to 
normal IDEs with describable builds won't benefit though.



Really, this is one reason why I use Geany in the first place. Other
IDEs such as eclipse require extensive, per-project build setup, to give
even basic symbol parsing support. Such IDEs are generally limited to
select w

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

[Matthew Brush]

On 2016-08-31 08:42 PM, Lex Trotman wrote:

On 31 August 2016 at 11:27, Matthew Brush <mbr...@codebrainz.ca> wrote:

On 2016-08-30 06:43 AM, Colomban Wendling wrote:

[...]



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.


Agree with Matthew.

The point of not using the standard Scintilla lexer [...]



I wouldn't even call it "standard" lexer. Though it conforms to the same 
C++ interface as a few other modern, well-maintained lexers, AFAIK only 
handful of Scintilla's lexers (ex. LexCpp) are actually able to compile 
as dynamic libraries.


One of the few useful dynamic lexers I've ever seen is Scintillua[0] and 
it actually makes some kind of sense to be a generic dynamic lexer here 
since it can proxy for other lexers using a completely different 
non-Scintilla mechanisms internally (ie. Lua and PEGs).


Cheers,
Matthew Brush

[0]: http://foicica.com/scintillua/
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

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

[Matthew Brush]

On 2016-08-31 10:47 PM, Matthew Brush wrote:

On 2016-08-31 10:08 PM, Thomas Martitz wrote:

Am 31.08.2016 um 17:26 schrieb Lex Trotman:

I think we all agree that help of language-specific plugins is
desired/required. No need to restate "we need language specific
support" all
the time.

We just disagree on how the language-specific knowledge is
transported to
Geany, other plugins and the user.


Well, I read your previous comments such as "But *just* the data,
don't offload very specific use cases onto them" (and to some extent
this one too) as saying that all the plugin has to do is return some
data (tags) and Geany will take it from there and all I was doing was
making sure it was clear that its unlikely that Geany will be able to
"take it from there" in any meaningful way, based purely on data,
without filetype specific knowledge inside Geany.


Here we disagree. I think it is possible to extent TM/Geany sufficiently
to encode this information in generic ways. As an example, template
instantiation yields different types. TM could tread them as different
types. Any variable will be of one of the types, so calltips would just
work.



Let's use the simplest C example:

gint x = g_...

Please describe the algorithm (just in prose) that would give only the
valid completions (ie. would compile in a C compiler) for `g_...`
without providing any impossible completions, and without knowing
anything about C/C++/Obj-C.



To make it more interesting, you can assume that the full C/C++/Obj-C 
AST is somehow represented with full fidelity in a TM tags array, as a 
given.


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

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

[Matthew Brush]

On 2016-08-31 10:08 PM, Thomas Martitz wrote:

Am 31.08.2016 um 17:26 schrieb Lex Trotman:

I think we all agree that help of language-specific plugins is
desired/required. No need to restate "we need language specific
support" all
the time.

We just disagree on how the language-specific knowledge is
transported to
Geany, other plugins and the user.


Well, I read your previous comments such as "But *just* the data,
don't offload very specific use cases onto them" (and to some extent
this one too) as saying that all the plugin has to do is return some
data (tags) and Geany will take it from there and all I was doing was
making sure it was clear that its unlikely that Geany will be able to
"take it from there" in any meaningful way, based purely on data,
without filetype specific knowledge inside Geany.


Here we disagree. I think it is possible to extent TM/Geany sufficiently
to encode this information in generic ways. As an example, template
instantiation yields different types. TM could tread them as different
types. Any variable will be of one of the types, so calltips would just
work.



Let's use the simplest C example:

gint x = g_...

Please describe the algorithm (just in prose) that would give only the 
valid completions (ie. would compile in a C compiler) for `g_...` 
without providing any impossible completions, and without knowing 
anything about C/C++/Obj-C.



[...]


My TM query interface wants to return all matching tags, including those
found by ft-plugins. Can this be done?



There's no reason an API couldn't be provided to query such information 
even from ft-plugins, for ex.


   void query_symbols(criteria, out_tags_list);

Geany doesn't have to know every tag in order to call into ft-plugins 
for such query results, and can even fallback to TM/ctags if no plugins 
support this feature.


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

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

[Matthew Brush]

On 2016-08-31 10:00 PM, Thomas Martitz wrote:

Am 01.09.2016 um 05:42 schrieb Lex Trotman:

On 31 August 2016 at 11:27, Matthew Brush <mbr...@codebrainz.ca> wrote:


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.

Agree with Matthew.

The point of not using the standard Scintilla lexer is to be able to
add semantic information made available for the language support
library in the FT-Plugin.

The major example of this is fixing the current situation where any
name that is a type in any scope is coloured as a type in every other
scope, even if the type is not visible there.

That means that the lexer is intimately tied into the FT-Plugin so it
likely won't run without the FT-Plugin anyway, so actually including
it in the plugin and accessing it via the container lexers interface
looks better than having a separate DLL that won't run by itself
anyway and then has to be sure its loaded at the right time.


Can this support color schemes and custom keywords (although the latter
is probably not very important).

I don't know what SCLEX_CONTAINER is.



It's the built-in (application-provided) lexing support in Scintilla. It 
means "Tell me when, and I'll highlight the source for you". It only 
requires a GTK+ signal from Scintilla rather than having to implement a 
concrete C++ class of ILexer and conforming to some interface in a 
separate DLL, to perform roughly the same task.


http://www.scintilla.org/ScintillaDoc.html#SCN_STYLENEEDED

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

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

[Matthew Brush]

On 2016-08-31 06:30 AM, Thomas Martitz wrote:

Am 31.08.2016 um 13:23 schrieb Lex Trotman:

[...]

Both of these are C++ specific semantics, (types generated by template
instantiation and argument dependent lookup).  I don't believe TM
should be be expanded to include such knowledge.



Why not? TM could have separate tags for each known template instance
and know which of these applies to someAs, based on information provided
by a ft-plugin. Then the rest would work.

Besides, template instantiation requires compiling the units IIUC, which
is probably not gonna happen ever? At least not on every keystroke as
done currently.



I can't speak to all compiler libraries, but at least libclang, 
libpython and libvala "compile" the source (well just the front-end of 
the compiler is needed). They literally use the built-in compiler front 
ends to understand the code. In the case of libclang, it additionally 
provides helpful methods for performing IDE-related features on the AST, 
while say with libvala, the ft-plugin would be required to perform it's 
own analysis of the AST to implement those feaures, which is still a lot 
less work than in Geany/TM since it has access to the full AST/context 
and the ft-plugin need not fear encoding language specific semantics 
into its logic.


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

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

[Matthew Brush]

On 2016-08-30 06:43 AM, Colomban Wendling wrote:

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.



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.


Cheers,
Matthew Brush

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

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

[Matthew Brush]

On 2016-08-30 06:29 AM, Colomban Wendling wrote:

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;
...
}


As long as it's uniform across all features (ie. all or none are using 
structs whether or not they have multiple features), that's pretty much 
what I had in mind, and is basically how I represented the internal 
tracking structures in my experimental code I was playing with.


API-wise I find it neater to keep the parameterization in the parameters 
list and keep any structures like that as simple vtables, but the 
difference is rather minute (probably whatever would work better for 
auto-binding generators to read).




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



I personally believe interfaces/abstract-bases to be the most 
appropriate technical solution (at least from OOP-languages) at our 
disposal, but I chose to stay away from that mostly to avoid the 
social/political/emotional ramifications of it on the discussion. 
Besides, re-implementing a small portion of it isn't that big a deal and 
doesn't feel so unnatural for C.


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

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

[Matthew Brush]

On 2016-08-30 06:24 AM, Colomban Wendling wrote:

Le 29/08/2016 à 02:47, Matthew Brush a écrit :

[…]

To give an idea, the registration function called by plugins might look
something like this:

gboolean ftplugin_register_provider(GeanyPlugin*,
GeanyFiletypeID, GeanyFiletypeFeature, GCallback, gpointer);


Maybe we could simply use GSignals?  Something like


[...]


Just a though, and seeing some of the questions raised further down
might suggest it's not flexible enough, but using the GSignal mechanism
we already have at hand seemed like at least a good idea to consider.



It's a good thought, and I did consider it, but I believe for it to 
work, we would have to store an object of a different GObject type for 
each combination of Filetype and Feature, so that each object could have 
their distinct signals installed in their classes and be connected to. 
Otherwise we'd have to provide some kind of DSL embedded inside the 
signal-name like property notifications (ex. `c::autocomplete`) or 
something, and have Filetype*Feature signals for the GeanyObject.


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

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

[Matthew Brush]

On 2016-08-30 02:29 PM, Thomas Martitz wrote:

Am 30.08.2016 um 21:10 schrieb Jiří Techet:
[...]


And even if we did this, I don't know how we could handle ASTs of
different languages in a generic way because these will differ
significantly.



One more time, seems I wasn't clear enough yet: I'm *not* suggesting
that we create generic code inside Geany that handles any kind of AST.
What I suggest is that plugins that use AST internally (or not) pass
tag-like information to Geany, extracted and flattened from its internal
AST (or whatever it uses). Then Geany and other plugins can use that
information for their own purposes.



We do need more than just "tags-like information" though, for example, 
what's Geany gonna give for completions here (C++):


auto bar = foo()->...

Or even on the next line:

bar.blah = baz... + 3

In the first case, it needs to know the type of not only `foo`'s return 
value, but it needs to know the type of `foo`'s return type (could 
depend on `X`'s type and/or lots of other stuff).


For the second line, a super-smart auto-complete might only give 
suggestions for a `baz` that has a type that has an `::operator+` member 
that works with ints (or `baz` is a primitive numeric type), what's 
more, it could also filter the suggestions down so that it only shows 
identifiers (in any accessible scope) which start with `baz` and when 
the global or member `::operator+` is applied to it and 3, and the 
result of that which is also compatible with the `blah` member of `bar` 
(which is the type of the return of `foo()` and never even mentioned 
locally).


As a further example, if we ever upgrade Geany's auto-complete list to 
be more than Scintilla's default (to something similar the one in 
GtkSourceView IIRC), which say for example showed the doc-comments for a 
given symbol (something libclang provides in/along with the AST, and is 
also accessible in Python AST as well, IIRC), not only now does 
TagManager have to store all that comment text (redundantly, or else 
call into the ft-plugin to get it on demand), but it has to pick-out the 
_exact_ right completion for the comment to be correct, based on all 
kinds of factors, such as the language's scope lookup rules (even inside 
of `if` blocks, which it also now has to store in the Tags array or 
recover from the source code some how), but also based on templated 
types once interpreted (TM would need to store some kind of decypherable 
mangled names after templates are expanded), and overloads (which it 
would need to determine given the given set of overloads, based on 
argument types which compile (and also SFINAE and all that jazz), and 
inheritance rules (TM would need to keep track of polymorphic, 
potentially multiply-inherited relationships), etc.


Basically, TM would have to have a semantic analyzer with the strength 
of that of a real compiler, for each language an ft-plugin might 
implement. That is what's needed for real Intellisense-like features and 
I believe what some of the responders are getting at. The same kind of 
smarts would be needed to also implement calltips or goto def/decl, 
though perhaps with slightly different logic.


What's more, for the specific libclang case, since it's meant to be used 
as a support library for IDEs (and other tools), it already provides a 
function like `completeAt(where, ...)` for auto-completion that when 
called provides a list of AST nodes referring to the valid completions 
at that point. It would be horrible to have to re-implement that 
function independent of the AST in TM/Geany, instead of just passing 
Geany a list of strings or TM tags to show in the popup list.


Cheers,
Matthew Brush

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

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

[Matthew Brush]

On 2016-08-30 08:51 AM, Thomas Martitz wrote:

Am 30.08.2016 um 01:53 schrieb Matthew Brush:

On 2016-08-29 03:17 PM, Thomas Martitz wrote:

Am 29.08.2016 um 17:05 schrieb Jiří Techet:

[...]


There is also another aspect about the proposal that worries me: a
plugin shall provide N features for M languages. And X plugins might be
compete (not even considering the desire that plugins can build upon
each other). This means (slightly exaggerated) that N*M*X possibilities
have to be managed by Geany's conflict resolution. I don't want to
implement that. It seems much simpler to me to collect tags from
plugins, merge them (maybe throw out duplicates) and pass them to the
actual feature code all within Geany.



In principle it's not that hard to manage, as mentioned in my
"Proposed Design" message, Geany just needs to keep the providers in a
list and the callbacks work like GTK/GDK callbacks (and some in Geany)
where the callback's return value determines whether the next provider
is called or not. In that message I attached a mockup of a kind of UI
that could be used to allow users absolute control, and for Geany it's
just a (set of) ordered lists.


You say this should be easy, I say I expect it to be complicated. This
is quite the same (just the other way around) with my suggestion to just
pass tags to Geany. There you keep claiming that it'll be a massive
change why I expect it to be relatively easy to do. At least not harder
than changing 6+ core parts in Geany to execute plugin callbacks and
make something useful from the results.



I've tinkered with implementations, it's generally as easy as walking a 
list in a loop, calling a function and breaking early if the function 
returns `FALSE`.


I don't think I claimed it will be a massive change, I think I just said 
it will add more complexity to ft-plugins, as opposed to less, as you 
claimed.


Since the very first response I made to you about TM, I've been open to 
the idea. I raised a few concerns which you never responded to, namely 
that it may not be possible for TM to handle all the tags in Clang's AST 
(it has a very rich and complex AST, heavily optimized by some of the 
smartest people in the C++ world). Also the AST is HUGE and representing 
it twice in memory would at least (if not more than) double the memory 
footprint.





What worries me is that we jumped from mere brainstorming to a
relatively concrete proposal, without evaluating requirements or any
other research. Or was this evaluation just invisible to me?



I evaluated and experimented with several different approaches and
discussed various details with some of the main developers (including
you) on IRC. Based on the way that in my opinion, as someone who has
tried and failed to implement the needed features in the past, and as
a Geany developer, I recommended a proposed design for further input.
And here we are :)



Please show me the point in the IRC logs where I agreed with your
approach. In fact, I can't remember discussing ft-plugins with you on
IRC at all (I just asked at one point how libclang works in more detail).



I never said I proposed a design on IRC, that's what the "Proposed 
Design" email was about. I discussed approaches and details with some of 
the developers. You and I talked about whether TM might be up to the job 
of representing scope, for example (and you pointed out that it can, 
crudely, by using strings rather than parent/child relationships).



Your evaluation is still invisible to me.



I evaluated the various approaches myself and by discussing specific 
topics with some devs lately and previously when we talked about 
ft-plugins so that I would be able to propose a design on the mailing 
list, and here we are discussing that. I don't see the problem.




As I asked in an earlier message, I'd be interested if you could
provide some more concrete examples of what you were thinking with
using TM, which would accomplish the goals mentioned in the Github
Issue and fleshed-out more in the top of this thread.



Essentially I'd propose a signal that's emitted when Geany begins
(re-)parsing a file (I believe it does this after each keystroke, after
a debouncing timeout). Plugins could connect to that signal, perhaps
parse the file again, using their special, language specific library
code, and pass the tags they've got to Geany using a to-be-designed API
function (probably involving TMTag and TMSourceFile). Alternatively, the
plugin signal handlers could run before Geany's own one, potentially
blocking Geany from parsing the file at all. Or both approaches.



Unrelated to whether to use TM or not, I think you're right that a hook 
to tell ft-plugins to re-parse would be useful, otherwise plugins will 
all have to implement that logic/signal connections themselves.



Geany would then merge the tags, perhaps giving the plugin ones more
weight, and store it in TM.



I think you underestimate how many tags we're talking here. The 

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

[Matthew Brush]

On 2016-08-29 03:17 PM, Thomas Martitz wrote:

Am 29.08.2016 um 17:05 schrieb Jiří Techet:

[...]


There is also another aspect about the proposal that worries me: a
plugin shall provide N features for M languages. And X plugins might be
compete (not even considering the desire that plugins can build upon
each other). This means (slightly exaggerated) that N*M*X possibilities
have to be managed by Geany's conflict resolution. I don't want to
implement that. It seems much simpler to me to collect tags from
plugins, merge them (maybe throw out duplicates) and pass them to the
actual feature code all within Geany.



In principle it's not that hard to manage, as mentioned in my "Proposed 
Design" message, Geany just needs to keep the providers in a list and 
the callbacks work like GTK/GDK callbacks (and some in Geany) where the 
callback's return value determines whether the next provider is called 
or not. In that message I attached a mockup of a kind of UI that could 
be used to allow users absolute control, and for Geany it's just a (set 
of) ordered lists.



What worries me is that we jumped from mere brainstorming to a
relatively concrete proposal, without evaluating requirements or any
other research. Or was this evaluation just invisible to me?



I evaluated and experimented with several different approaches and 
discussed various details with some of the main developers (including 
you) on IRC. Based on the way that in my opinion, as someone who has 
tried and failed to implement the needed features in the past, and as a 
Geany developer, I recommended a proposed design for further input. And 
here we are :)


As I asked in an earlier message, I'd be interested if you could provide 
some more concrete examples of what you were thinking with using TM, 
which would accomplish the goals mentioned in the Github Issue and 
fleshed-out more in the top of this thread.


Cheers,
Matthew Brush

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

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

[Matthew Brush]

On 2016-08-29 05:38 AM, Thomas Martitz wrote:

Am 29.08.2016 um 14:23 schrieb Lex Trotman:

This adds per use case hooks to plugins, which then became part of the
stable API. I don't think that we have to codify every single use case
of tags into the plugins. That's just making it harder (maybe
impossible?) to change or add use cases.
The point of this proposal is to change and add use-cases that are not
currently possible with the current plugin API.  But instead of each
use-case generating its own piece of API and its own infrastructure,
the point of the FT-plugins proposal is to provide a common
infrastructure and approach for all filetype specific use-cases, those
needed for currently suggested uses, indentation, clang based styling
and symbols, and as framework for future use-cases we either havn't
thought of, or havn't a concrete intention to add immediately.


I thought we agreed that plugin should simply provide tags to Geany/TM

This proposal is about many types of filetype specific functionality,
not just tags.  Tagmanager will not help in any way with indenting
Haskell, or even C++.




4 of 5 of the proposed features are strictly tag-related. And Geany can
do all of them already, it's just that the current implementation leaves
things to be desired so there is the idea to let plugins improve upon them.

I disagree with the proposed solution for those 4, because they are
offloading logic on a per feature basis to plugins, only because Geany
isn't capable at the moment. If Geany was capable, then there could be 1
solution for the 4 features and less complexity in each plugin (and we
know the quality of plugins varies a lot so they should have little
complexity as possible).



Using TagManager would likely add more complexity to the plugins. Using 
the libclang example, it already has its own internal representation of 
"tags" (ie. the AST). Making plugins munge their internal representation 
to convert/conform to TagManager's would add extra burden.


For example "go to definition/declaration" is a simple task with 
libclang, you would just get the source location and pass back to Geany 
the filename and position and it could go there easily, without any need 
for TagManager as a middle-man. Likewise, libclang has a function to 
return valid completions for a given position in the source code, 
passing a list of strings for Geany to show in the Scintilla 
auto-complete list would be a simple matter of building a string array. 
Using tag manager would require building a tags array that probably 
wouldn't/shouldn't become part of any larger tags array 
(workspace/global/whatever) and then getting Geany to show that tags 
array without messing with it (ordering, etc).


Another issue that might arise is that TagManager might very well choke 
if it had to deal with every single tag/symbol in the entire source 
(make a "hello world" in C++ using iostream and look at the preprocessed 
source, for example). The number of tags it would need to store/track 
would way more than double when you consider local variables, 
parameters, inner-classes, etc. I have no clue if TM is actually able to 
handle this at all, efficiently enough. Ontop of that, all this 
information is stored twice in memory, once in the libclang AST and once 
in TagManager tag arrays. This could result in quite some additional 
memory overhead.


Jiří gives an example (the symbols sidebar) where this may be warranted 
and ultimately cause less work, since the sidebar updating code is 
apparently quite complicated. I still need to study this code to 
understand why so much effort is needed to keep the symbol tree at the 
same relative scroll location when updated.



The solution I have in mind simply allows plugins to pass tags to Geany
which they parsed with more advanced code. The tags itself would
advanced too, to allow for the improvements current TM+ctags can't
offer. Symbol tree, calltips, autocompletion, jump-to-decl can all be
improved based on the advanced tags.



I'm not strictly opposed to wrangling stuff through TagManager. Could 
you provide example hooks showing the kind of interface you would 
thinking about for the mentioned features? Also in which cases do you 
expect TagManager is not up to the task and would need to be modified?


Cheers,
Matthew Brush

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

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

[Matthew Brush]

On 2016-08-28 08:17 PM, Lex Trotman wrote:

On 29 August 2016 at 12:30, Matthew Brush <mbr...@codebrainz.ca> wrote:

[...]

That's the idea with boolean results, a plugin could actually provide the
feature but return `FALSE` and Geany would call the next provider to perform
the feature as well. It's kind of like a poor-man's inheritance.


Actually, after more thought it doesn't make sense to me.

If a more specific provider wants to build on a more general one, it
wants the general one to run before it, so it has to be ordered after
the general provider, which has to return FALSE to allow the more
specific one to run.  But if the more specific provider isn't loaded
the general provider has to return TRUE to stop the geany built-in
functionality from running.  This means the general provider has to
know about the specific providers and if they are loaded, which is the
wrong way around.

Also a more specific provider that does it all itself and doesn't want
the general one to muck stuff up has to be ordered before the general
one to return TRUE so the general one doesn't run.  So providers have
to be able to re-order themselves or to specify an order.

I think if a provider depends on another it should be ordered first
and directly call the other, then it can return TRUE so the other
isn't called twice.



It's a good point. I think at first just using the activation and manual 
user-customized order will likely suffice. I expect the common case to 
be activating a single plugin (ex. my CDK plugin) to cover a set of 
features/filetypes and no other plugins conflicting or dependent. In the 
future it will probably be useful to make this more automatic by adding 
some kind of inter-plugin dependency manager and GUIs whatnot.


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

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

[Matthew Brush]

On 2016-08-28 06:59 PM, Lex Trotman wrote:

On 29 August 2016 at 10:47, Matthew Brush <mbr...@codebrainz.ca> wrote:

[...]

"Registration" - the act (ie. function call) of an ft-plugin declaring its
interest in providing a feature for a filetype. An ft-plugin can register to
provide one or more features for one or more filetypes.


I think the registration data should go in the plugin data file that
Thomas added, not require plugins to be loaded to register, otherwise
all language plugins will be loaded at all times just so they can call
the function to be registered.



That's a thought. I think the plugin data file you refer to may only be 
for the libpeas proxy plugin which is not part of Geany (yet).


IIUC, at least when the plugin manager is opened, Geany loads all of the 
plugin DLLs anyway. Plugins could register their providers at 
`geany_load_module()`-time before they're actually initialized. Needs 
more consideration.






In this design, a new module (c/h file) would be added to manage the
filetype plugins and which features they provide for which filetypes. A
mapping (ex. GHashTable) could be used to map from Filetype to a list (ex.
GQueue) of data describing the needed information for a registered provider.
The list would be ordered in the same order as registration and could also
be re-ordered by the user using a GUI (more on this below).


Would need to ensure plugin loading will re-load in the
original/specified order, IIRC it currently re-loads in alpha order.



Yeah, possibly storing this info in separate ftplugin-specific keys in 
the config file.




The order of the list of plugins registered to provide a feature for a given
feature/filetype pair would determine the priority given when Geany asks the
provider to perform its function. The callback functions could return a
boolean telling Geany whether the provider performed its function or whether
it should try the next provider in the list, similar to many GTK+ callbacks.
If no provider performs its function, or there are no providers registered
for a given feature/filetype, then Geany would take its existing code path
to provide the feature itself.


This makes sense, but so does Colombans desire for plugins to be able
to improve on the work of other plugins so you don't have to have all
plugins re-implement the basic functionality.  Not immediately sure
how to reconcile these two options, unless Colombans desire is
provided by having the dependent plugin have to call the basic plugin
function directly, so its not Geany's problem.



That's the idea with boolean results, a plugin could actually provide 
the feature but return `FALSE` and Geany would call the next provider to 
perform the feature as well. It's kind of like a poor-man's inheritance.






When a plugin registers its intent to provide a feature (or perhaps after it
has registered all the features it wishes to provide), Geany could check
whether there is already another plugin providing this feature. Geany could
ask the user if they would like to resolve the conflict, and if they would,
then it could show a management dialog (see attachment for mockup), allowing
the user to control the priority of the plugin's provider for a given
feature/filetype by moving them up or down in a list, and possibly being
able to completely disable a provider entirely (via a checkbox in the list
or something).


Not sure about this dialog happening automatically, think it would
need a "Shut TF up" option, and also be quiet at re-load.  But
certainly providing the advanced user control of the providers is
fine.



Yeah, I thought it might be annoying too. Will need experimentation.





To enable Geany to use the providers, in the existing code just before it's
about to provide the feature itself as it does now, we could insert a
check/call to try the ft-plugin providers.


This may require some unwinding of the spaghetti to clearly identify
the beginning of a "feature" and ensure it happens in one place.  Some
places there is stuff split between different callbacks depending on
how the feature was triggered.



Most likely yeah. In some cases though, it might be as simple as 
sticking an "if" statement at the beginning of a single function with an 
early return.




 If nobody performed the feature,

then it would continue to the existing code path. This should limit the
number of changes needed to Geany. Some features would necessarily require
more changes, for example syntax highlighting would require Geany to switch
from the Scintilla lexer to the container lexer and back as plugins
start/stop providing the feature. It will require care for features that are
activated often to ensure minimal performance degradation when looking up
and calling into the provider, as this would happen in the main code paths
(unless someone has a better way).


It is always a requirement for plugins to not hog or block the main
thread, they can do that b

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

[Matthew Brush]

nough details of my proposed design to allow 
everyone to understand what I mean. If there's any questions or 
suggestions, please let me know.


Thanks,
Matthew Brush

[0]: I'm still waiting for someone to propose a better name :)


























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

Re: [Geany-Devel] [FT-plugins] Allowing plugins to supply filetype specific functionality

[Matthew Brush]

On 2016-08-28 08:47 AM, Jiří Techet wrote:

Hi Matthew,

some random thoughts.

I'm not sure I agree with doing lots of changes on a separate branch
basically without any review. While you will be able to commit things fast
to the branch, the most probable outcome will be the branch will get never
merged because either nobody will be able to review the changes during
merge or there will be some disagreement about something that could have
been caught early. And then it's just lost effort.



A branch can be merged into master more than once (or we could use 
multiple-branches). No reason it has to happen in a single merge, or 
without any review.



The individual points here

https://github.com/geany/geany/issues/1195

look like they should be able to do one by one. The most useful seems to be
the code completion so this might be the one to start with. In parallel it


That or highlighting, not sure.


would be good to develop a plugin that uses the new API and get it to a
really usable state - you won't be able to tell what exactly you need for
the plugin unless you have some working code. In parallel you can get some
feedback from users and they will have something useful rather than lots of
half-finished prototype features that aren't really usable.



I have previously started writing the CDK plugin[0] but gave up for the 
time being since most of what I wanted to implement either a) wasn't 
possible b) wasn't possible without ugly hacks or c) wasn't possible 
without the user manually disabling stuff in the prefs dialog and 
completely replacing the feature from the ground up.


I would probably like to use this as a proof of concept, although only 
having one plugin for one family of statically typed languages using one 
support library might not give the fullest view of what's needed.



My other question is who wants to work on this? The issue mentions only
those providing patches should be involved but is there anyone except you
who will contribute patches? I confess this isn't very interesting for me -


We'll see. I know Columban has expressed interest (or at least stated 
that it's probably the best approach) in the past, not that that means 
he's interested in actively contributing to the effort. Anyone is 
welcome to contribute.



I'm not so terribly tied to Geany and if I wanted e.g. a dedicated C++
editor, I'd grab something else - you always get better language support if
the editor is made specifically for your needs. I use Geany as a general


This isn't necessarily true, there's lots of language-agnostic 
editors/IDEs that people use that allow customized language support 
(vim, eclipse, emacs, etc). The problem with Geany is it doesn't allow 
any filetype customization besides what you can set in the filetypes.* 
files, it doesn't allow extension of any of the built-in features.



purpose editor but otherwise use also Android Studio and XCode when writing


I sometimes use QtCreator when I need proper C/C++ support but it's 
annoying having to use an editor I don't like when I know that Geany can 
(and does now, just not well) do the same things with the assistance of 
language-specific support libraries.



for Android or iOS. So no patches from me I'm afraid :-(. Apart from that
this is a huge amount of work and I'm just lazy, sorry ;-)



That's fine. I don't expect it to be a _huge_ amount of work, but 
probably not a simple one-off PR. I expect it to be similar in scope and 
size to the proxy plugin improvements, most likely.


Cheers,
Matthew Brush

[0] https://github.com/codebrainz/cdk-plugin
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] [FT-plugins] Vala for prototyping

[Matthew Brush]

On 2016-08-27 04:09 PM, Matthew Brush wrote:

Hi All,

With respect to the efforts described in PR #1195[0] is anyone opposed
to using Vala as a GObject code generator?

I propose we use Vala as a way to generate GObject boilerplate while we
hammer out the design of FT-plugins, and later once the design is more
concrete, that we port the GObjects generated by valac to their
hand-written C equivalents (after they won't be changed as much).

It amounts to a few lines of code in `configure.ac` and `src/Makefile.am`.

Is OK?

P.S. This is only for the proposed 'ft-plugins' branch, not in
master/release code.



Nevermind, I can just use it locally for prototyping. Don't want to get 
too sidetracked on something that's not strictly required and/or turn 
off anyone who doesn't want to use Vala.


Sorry for the noise.

Cheers,
Matthew Brush

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

Re: [Geany-Devel] [FT-plugins] Vala for prototyping

[Matthew Brush]

On 2016-08-28 01:51 AM, Thomas Martitz wrote:

Am 28. August 2016 01:09:36 MESZ, schrieb Matthew Brush <mbr...@codebrainz.ca>:

Hi All,

With respect to the efforts described in PR #1195[0] is anyone opposed
to using Vala as a GObject code generator?

I propose we use Vala as a way to generate GObject boilerplate while we

hammer out the design of FT-plugins, and later once the design is more
concrete, that we port the GObjects generated by valac to their
hand-written C equivalents (after they won't be changed as much).


Do you suggest to use it only initially, and then continue working on the C 
code? In that case the vala code doesn't need to be checked in does it?



I suggest to use Vala to write any GObject stuff for prototyping 
purposes in order to avoid writing and re-writing gobs of boilerplate. 
The Vala code would have to be checked-in in order to modify it until a 
design is hammered out then the code could be converted to plain C 
boilerplate once it's not changing often (before merging back to master 
branch).



The classbuilder plugin (shipped with geany) can also generate the boilerplate, 
bit much prettier with less noise.



The classbuilder plugin only generates basic GObject boilerplate, it has 
no concept of interfaces, abstract base classes, properties, signals, etc.



If you suggest to continue working on the vala code that's ok with me but not 
everyone is fluent with vala.



It would be OK with me too, but I suspect not everyone.

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

Re: [Geany-Devel] [FT-plugins] Vala for prototyping

[Matthew Brush]

On 2016-08-27 04:09 PM, Matthew Brush wrote:

[...] I propose we use Vala as a way to generate GObject boilerplate [...]


See attached for the minimal diff to start supporting Vala.

Cheers,
Matthew Brush
diff --git a/.gitignore b/.gitignore
index f013c72..9a0d638 100644
--- a/.gitignore
+++ b/.gitignore
@@ -87,6 +87,10 @@ Makefile.in
 /src/geany
 /src/geany_private.res
 /src/signallist.i
+/src/geanyvala-1.0.vapi
+/src/geanyvala.h
+/src/placeholder.c
+/src/*_vala.stamp
 
 #---
 # /doc/
diff --git a/configure.ac b/configure.ac
index 28b6202..f26fc9e 100644
--- a/configure.ac
+++ b/configure.ac
@@ -35,6 +35,8 @@ GEANY_PROG_CXX
 AC_PROG_INSTALL
 AC_PROG_LN_S
 
+AM_PROG_VALAC
+
 # autoscan start
 
 # Checks for header files.
diff --git a/src/Makefile.am b/src/Makefile.am
index 9454c44..156bb70 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -22,6 +22,10 @@ AM_CPPFLAGS = \
 	@GTK_CFLAGS@ @GTHREAD_CFLAGS@ \
 	$(MAC_INTEGRATION_CFLAGS)
 
+AM_VALAFLAGS = \
+	--vapi=geanyvala-1.0.vapi \
+	--header=geanyvala.h --use-header
+
 bin_PROGRAMS = geany
 lib_LTLIBRARIES = libgeany.la
 
@@ -43,6 +47,7 @@ geany_include_HEADERS = \
 	encodings.h \
 	filetypes.h \
 	geany.h \
+	geanyvala.h \
 	gtkcompat.h \
 	highlighting.h \
 	keybindings.h \
@@ -88,6 +93,7 @@ libgeany_la_SOURCES = \
 	msgwindow.c msgwindow.h \
 	navqueue.c navqueue.h \
 	notebook.c notebook.h \
+	placeholder.vala \
 	plugins.c plugins.h \
 	pluginutils.c pluginutils.h \
 	prefs.c prefs.h \
@@ -117,6 +123,7 @@ endif
 
 libgeany_la_CFLAGS  = $(AM_CPPFLAGS) @LIBGEANY_CFLAGS@
 libgeany_la_LDFLAGS = @LIBGEANY_LDFLAGS@
+libgeany_la_VALAFLAGS = $(AM_VALAFLAGS)
 
 libgeany_la_LIBADD = \
 	$(top_builddir)/scintilla/libscintilla.la \
@@ -126,6 +133,8 @@ libgeany_la_LIBADD = \
 	$(MAC_INTEGRATION_LIBS) \
 	$(INTLLIBS)
 
+geanyvala.h: placeholder.vala
+
 # tell automake we have a C++ file so it uses the C++ linker we need for Scintilla
 nodist_EXTRA_libgeany_la_SOURCES = dummy1.cxx
 
diff --git a/src/placeholder.vala b/src/placeholder.vala
new file mode 100644
index 000..e8b7a72
--- /dev/null
+++ b/src/placeholder.vala
@@ -0,0 +1,7 @@
+namespace Geany
+{
+	public int reserved_placeholder()
+	{
+		return 42;
+	}
+}
diff --git a/src/plugindata.h b/src/plugindata.h
index c8bd687..d09e6c5 100644
--- a/src/plugindata.h
+++ b/src/plugindata.h
@@ -37,6 +37,7 @@
 #include "document.h" /* GeanyDocument */
 #include "editor.h"	/* GeanyEditor, GeanyIndentType */
 #include "filetypes.h" /* GeanyFiletype */
+#include "geanyvala.h"
 
 #include "gtkcompat.h"
 
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

[Geany-Devel] [FT-plugins] Vala for prototyping

[Matthew Brush]

Hi All,

With respect to the efforts described in PR #1195[0] is anyone opposed 
to using Vala as a GObject code generator?


I propose we use Vala as a way to generate GObject boilerplate while we 
hammer out the design of FT-plugins, and later once the design is more 
concrete, that we port the GObjects generated by valac to their 
hand-written C equivalents (after they won't be changed as much).


It amounts to a few lines of code in `configure.ac` and `src/Makefile.am`.

Is OK?

P.S. This is only for the proposed 'ft-plugins' branch, not in 
master/release code.


Cheers,
Matthew Brush

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

Re: [Geany-Devel] [FT-plugins] Allowing plugins to supply filetype specific functionality

[Matthew Brush]

On 2016-08-27 03:13 AM, Colomban Wendling wrote:

Le 27/08/2016 à 06:17, Lex Trotman a écrit :

[...]

Yes, and might be even simpler if it can take advantage of any of the
new plugin capabilities.  IIRC filetypes are never unloaded after
loading, so the plugins would have to be the same.  Possibly they
shouldn't even show in the PM, or show as not user removable.


IMO this is kind of unrelated to the issue at hand.  Yeah it *might* be
nice to auto-load/auto-unload filetype plugins when staring using the
filetype, but it's much more of a toy than an actual important design
piece if it loads normal plugins (which it probably should, unless
proven otherwise).
My point is that it adds extra complexity to an already complex-enough
issue, seem kinda orthogonal, and only removes the need to manually
check a plugin in the PM dialog.



It's true that at least initially we could just ignore the loading part 
and do it manually for testing purposes. We could still figure out how a 
plugin would tell Geany what it provides for what filetypes without 
loading it automatically from a filetype, but eventually we need some 
mechanism for this.



And it's even a complex issue, because you still need to let the users
chose not to load those plugins if they don't want them, etc.



If we went the filetype-based loader route, the user would choose in the 
filetype configuration files (or possibly by some future GUI) which 
plugins to provide support for which filetypes features.


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

Re: [Geany-Devel] [FT-plugins] Allowing plugins to supply filetype specific functionality

[Matthew Brush]

On 2016-08-27 12:38 AM, Lex Trotman wrote:

[...]

My proposition is that people without time or knowledge not contribute to
the development of this enhancement. Of course everyone would be able to
comment on stuff as it is merged back into master, but only those willing to
actively develop the solutions have any kind of strong voice during the
actual development.



That approach is very likely to produce a commit/merge bomb, a big
complex change that only those intimately involved with have looked
at, discussed, reviewed or tested.

[...]



Without responding to each thing, the idea behind adding those 
guidelines was to avoid the problems we have currently whenever trying 
to make any large changes. The current way is broken and isn't conducive 
to more than one person actively working on the code and others just 
pointing out mistakes from their armchair. I wanted to encourage active 
(ie. code-based) participation rather than one person doing all of the 
coding in a silo.


Using a separate branch means that every single little thing merged 
doesn't have to be perfect, stable, ready to release. It would be a work 
in progress branch that everyone interested is working on code for. It 
would avoid the current massive PR bomb where everything needs to be 
100% complete. This is why I said those minor comments wouldn't be 
wanted early on. Rather than nitpicking minor details, one could just 
push a commit fixing them (if non-controversial) or make a PR showing 
alternatives. That's what I meant by letting the code do the talking.









[...]


You can submit PRs to people's PRs, it's easy.



I didn't know you could do that, how?


You forgot to explain how to do this.



It's just making a PR the usual way, except when doing the web-based 
part, you choose a different fork rather than Geany's main repo. The web 
UI isn't super intuitive, but it's not hard at all. If you want to test 
it out, feel free to make some testing PRs against one of my repos. I'll 
just close them afterwards, no biggie.


Cheers,
Matthew Brush

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

Re: [Geany-Devel] [FT-plugins] Allowing plugins to supply filetype specific functionality

[Matthew Brush]

equired to make a comment "typo" and the OP
making the change as they do other stuff vs

2) the commenter making another PR and the OP having to then combine those.



That's an example of the kind of comments I was hoping to avoid. Either 
the person can wait until the changes are committed and then add a 
commit that fixes such trivial errors, send a general cleanup patch to 
pull requester, or they can wait until the changes are being merged into 
the master branch to raise such minor issues (eg. during some kind of 
code review). The goal is that if someone makes some large and/or 
complicated improvement towards the end goal on a non-master branch, not 
to bog them down with silly stuff anyone can fix or mention later when 
it actually matters.


To give an example, it's not uncommon for Columban to do a review and 
then provide a link to his working branch implementing the changes 
mentioned, the way he thinks are best. This is a goal, IMO.







[...]

You can submit PRs to people's PRs, it's easy.


I didn't know you could do that, how?

[...]

Probably sufficient for Geany to support "container lexers" and
flick-pass it to plugins.  But then the plugins probably have to have
a way to define styles similar to how `highlightmappings.h` is used
for included lexers.



It might be better to provide some kind of interface for this if we go the
container lexer route to make it less crazy to implement. The dynamic lexer
way is perhaps more work, but it's also more structured and one can use all
of Scintilla's lexers as examples. Needs more research.


Yes, don't know which is better.




Allow plugins to provide the symbols for the tagbar tree...



Do you mean the symbols pane? Or do you mean to inject symbols into
tagmanager so all existing functionality also sees them?



I mean something more like where Geany tells the plugin it wants to update
the symbol tree and so asks the plugins for the symbols to show. It's
sounding (from Jiří and Thomas) that using TM as a conveyance mechanism for
this may make some sense.


Possibly, so long as its flexible enough to be able to support the
particular language symbol and scope structures, then allowing
existing code to keep accessing the symbols in the same manner has
advantages.  But, ATM it doesn't support lexical scope IIUC, the TM
experts should comment.

One very important use-case for this is in type inferred languages
which are becoming more common (Julia, rust, go, ocaml, haskell, even
C++ auto), no ctags parser is going to get types for declarations in
those (and may not even recognise `a=b` as a declaration of a) so some
external method is gonna be needed.



I also have doubts whether TagManager/CTags is up to the task, but I'd 
like to be proven wrong (would save a lot of work/breakage).





[...]


Small potatoes. If the partial word is not given, many plugins will have to
get it each themselves. It's not a big deal to do but maybe at least a
helper function or something would be useful to avoid redundant code.


Yeah, just so long as it doesn't assume C name rules :)

[...]

At least for the CDK (libclang) plugin I was working on, there's no
requirement to actually run any external commands, you just call a libclang
API function to re-compile and then use its API to extract diagnostics
information programmatically. It would be a similar case for Python also.
That being said, it's probably beneficial to still allow more generic
compiler output parsing in case such nice support libraries are not
available.


Yes, thats the idea.




General:

I used to have a prototype of a change to load filetype specific
plugins specified in the filetype file.  I can't find it now (backups,
whats that?) but it actually was so simple that it doesn't matter.



I remember that. Most likely something along those lines will be a good way
to load the plugins, though it might require to be a bit more advanced to
deal with plugin lifetimes and other stuff.


Yes, and might be even simpler if it can take advantage of any of the
new plugin capabilities.  IIRC filetypes are never unloaded after
loading, so the plugins would have to be the same.  Possibly they
shouldn't even show in the PM, or show as not user removable.



Probably, yeah.

Cheers,
Matthew Brush

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

Re: [Geany-Devel] [FT-plugins] Allowing plugins to supply filetype specific functionality

[Matthew Brush]

On 2016-08-26 01:34 PM, Thomas Martitz wrote:

Uhm, where did this thread start? Who are you replying to?



My bad, I should've also sent a mail to the list. I assumed most of the 
main dev contributors got mail from Github about the Issue I posted, and 
anyone else would jump in as interested.




[...] We want interfaces where plugins can provide [...]



Without responding to specifics, I totally agree and I think we are on 
the same page WRT the mechanisms used to interface between Geany and the 
FT plugins (in the Issue I mention libpeas and gtksourceview providers 
as an example).


Cheers,
Matthew Brush

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

Re: [Geany-Devel] [FT-plugins] Allowing plugins to supply filetype specific functionality

[Matthew Brush]

echanism for this may make some sense.



provide the auto-complete list, given the current location in the document and 
the part of the word already typed.


Location in document is probably enough, the plugin probably has to
check for preceeding context `aaa.bbb.ccc` anyway, so the partially
typed name is no issue, and it can then be language specific, like
lisp can include *s and -s and other things that C doesn't allow in
names.



Small potatoes. If the partial word is not given, many plugins will have 
to get it each themselves. It's not a big deal to do but maybe at least 
a helper function or something would be useful to avoid redundant code.



plugins to hook into the build system runner


Plugins can now get and set any build command, not sure what else is
needed, except maybe a way of telling Geany to not save the plugin set
values, since the plugin is handling them.



That's good then, I haven't looked at that API much yet.


plugins to provide diagnostics when build commands are run.


Allowing the plugin to parse the command response *before* it goes in
the message window would be good.



At least for the CDK (libclang) plugin I was working on, there's no 
requirement to actually run any external commands, you just call a 
libclang API function to re-compile and then use its API to extract 
diagnostics information programmatically. It would be a similar case for 
Python also. That being said, it's probably beneficial to still allow 
more generic compiler output parsing in case such nice support libraries 
are not available.



General:

I used to have a prototype of a change to load filetype specific
plugins specified in the filetype file.  I can't find it now (backups,
whats that?) but it actually was so simple that it doesn't matter.



I remember that. Most likely something along those lines will be a good 
way to load the plugins, though it might require to be a bit more 
advanced to deal with plugin lifetimes and other stuff.



Cheers,
Matthew Brush

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

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

[Matthew Brush]

On 2016-07-06 05:37 PM, Lex Trotman wrote:

We could add the hamburger button to the toolbar so it could hide the menu.



Not everyone has the toolbar visible. And it'd have to be visible in the 
default toolbar layout (-1) or else people who do have it visible 
wouldn't realize they had to customize the toolbar in order to get their 
menu back. Additionally, anyone who has already customized their toolbar 
would have to somehow get their toolbar.xml file overridden by the 
default one. Otherwise, we'd have to add special code to add it 
unconditionally to the toolbar when the menu is hidden, which would 
require special casing to ensure it's not overflowed off of the toolbar 
and such. Of course then people would want preferences to disable that 
behaviour, etc.


IMO, adding a "Show Menu" item to the right-click menus is a simple and 
effective way to restore a lost menu bar.


P.S. Personally I have no reason to hide the main menu, I just put the 
message window on the right to use all that wasted screen-estate, 
leaving ample vertical space for the menu/toolbar/code.


Cheers,
Matthew Brush

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

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

[Matthew Brush]

On 2016-07-06 05:10 PM, Steven Blatnick wrote:

What does hamburger mean in this context?



https://en.wikipedia.org/wiki/Hamburger_button

Cheers,
Matthew Brush


On 07/06/2016 05:54 PM, Matthew Brush wrote:

On 2016-07-06 09:23 AM, Steven Blatnick wrote:

[...]
We should put in core geany or a plugin the ability to move the menu
to the
toolbar in a single icon like Chrome, instead or in addition to the
existing
functionality to move the toolbar to the menubar. [...]



NO HAMBURGERS!

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


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


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

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

[Matthew Brush]

On 2016-07-06 09:23 AM, Steven Blatnick wrote:

[...]
We should put in core geany or a plugin the ability to move the menu to the
toolbar in a single icon like Chrome, instead or in addition to the existing
functionality to move the toolbar to the menubar. [...]



NO HAMBURGERS!

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

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

[Matthew Brush]

On 2016-07-05 08:31 AM, Steven Blatnick wrote:

I've wondered about this feature myself.  My temporary solution was to
write a plugin that hides the menu bar until mouse over, like the Start
bar used to be configurable in Windows.  I haven't had a chance to
update all of my plugins to the latest geany, but if you care to look at
the plugin, you can see it here
<https://github.com/sblatnick/geany-plugins/blob/master/hide-menu/src/hide-menu.c>.


Alternatively, I thought the best idea would be a single icon, like
chrome's menu icon.  The problem is finding a place for it that doesn't
occupy an entire row or column of screen space.



When I implemented this in Mousepad, I just had it add a menu item to 
the right-click menu to allow turning it back on whenever the menu bar 
was hidden. The auto hide/show seems also like a good idea.


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

Re: [Geany-Devel] Autocomplete on the fly

[Matthew Brush]

On 2016-04-25 03:15 PM, Arthur Peka wrote:

You seem to misunderstand me. I mean autocompletion without pressing
anything. Like it happens in *any *proper IDE - Eclipse, IDEA, VS Code -
you name it. You *don't* loose seconds to press some key combination there.
It happens as you type. I suppose that's not supported in Geany?



Geany's behaviour is as expected; you type some number of prefix 
characters (Lex mentioned the pref. that controls it), and it offers a 
list of suggestions. If the selected suggestion is the one you want, 
press Enter and it will be completed, otherwise keep typing and the list 
is narrowed until the completion you want is available (or not) and then 
press Enter to accept it. It's basically the same as all editors/IDEs 
I've used which offer auto-completion (QtCreator, VisualStudio, 
Code::Blocks, SublimeText).


Maybe you disabled autocompletion or messed with one of the related 
settings? You can run Geany with the -c argument, passing some new 
directory there and Geany will write out a fresh config which you can 
use to test that.


Cheers,
Matthew Brush
___
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

[Matthew Brush]

On 2016-03-24 03:13 AM, Jiří Techet wrote:

On Thu, Mar 24, 2016 at 1:04 AM, Matthew Brush <mbr...@codebrainz.ca> wrote:


On 2016-03-23 07:21 AM, Jiří Techet wrote:


On Tue, Mar 22, 2016 at 9:02 AM, Enrico Tröger <enrico.troe...@uvena.de>
wrote:

Hi,


here are new Windows installers for testing.
They are built from GIT master and this time against GTK3.

There are two reasons for this:
- test Geany+GTK3 more on Windows
- there seems to be a bug in GTK2 on Windows with that very high
DPI/resolutions: on text input widgets (GTK ones and the Scintilla
widget) the mouse cursor gets very tiny.
This doesn't happen with GTK3.
Jiří showed me the bug and he knows more about the details.



Hi Enrico,

nice - the mouse problem is solved in Gtk 3 for me but I think not so many
users have an HiDPI screen so it's not so important. And if there are some
more important problems with Gtk 3, better to stick with Gtk 2 for now.



I never had any mouse-related problems with GTK2, for what it's worth. I
have 4k monitor on Win10.



What do you have set up for windows display scaling (the dialog e.g. here
https://www.thurrott.com/windows/windows-10/4597/windows-10-feature-focus-display-scaling)?
I need to have 200% because otherwise all the UI elements would be too
small on the HiDPI screen. Now Geany window gets resized alright, just the
"special" mouse cursors like the caret-like cursor in scintilla or back
arrow cursor on scintilla sidebar are not scaled and twice as small (in
both directions which makes the mouse cursor's area effectively 4x smaller).



I have no scaling enabled (ie. 100%). If I wanted a 2k monitor, I 
wouldn't have got one with 4k resolution :)


Cheers,
Matthew Brush
___
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

[Matthew Brush]

On 2016-03-23 07:21 AM, Jiří Techet wrote:

On Tue, Mar 22, 2016 at 9:02 AM, Enrico Tröger <enrico.troe...@uvena.de>
wrote:


Hi,

here are new Windows installers for testing.
They are built from GIT master and this time against GTK3.

There are two reasons for this:
- test Geany+GTK3 more on Windows
- there seems to be a bug in GTK2 on Windows with that very high
DPI/resolutions: on text input widgets (GTK ones and the Scintilla
widget) the mouse cursor gets very tiny.
This doesn't happen with GTK3.
Jiří showed me the bug and he knows more about the details.



Hi Enrico,

nice - the mouse problem is solved in Gtk 3 for me but I think not so many
users have an HiDPI screen so it's not so important. And if there are some
more important problems with Gtk 3, better to stick with Gtk 2 for now.



I never had any mouse-related problems with GTK2, for what it's worth. I 
have 4k monitor on Win10.



Some problems I noticed with the Gtk 3 build:
- any file dialog like File->Open, Project->open, File->Save as etc.
crashes Geany on my machine
- there's a bit strange shadow around the tooltips - see the attached
screenshot
- the Adwaita theme is just ugly (on any platform). Is there any Windows
native-like theme for Gtk 3 (the one used for Gtk 2 builds is pretty good
in this respect).



Yeah, +1, especially about Adwaita. It's so ugly I wouldn't even use 
Geany on Windows anymore if I was stuck with that. I mentioned some of 
the same in my mail about my installer generator script TODO[0].


I'm guessing the file dialog crash is a GTK+ bug related to architecture 
(sizeof(long) or such), since it seems to only happens on 64-bit. I 
think Thomas might have done some research on that issue.


Cheers,
Matthew Brush

[0]: https://www.mail-archive.com/devel@lists.geany.org/msg02624.html
___
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

[Matthew Brush]

On 2016-03-12 9:26 AM, Enrico Tröger wrote:

On 12/03/16 17:38, Matthew Brush wrote:

On 2016-03-12 03:28 AM, Enrico Tröger wrote:

On 12/03/16 02:56, Matthew Brush wrote:

On 2016-03-06 02:52 PM, Enrico Tröger wrote:

Hi,

as you might have noticed, Geany 1.27 is near.
And among all the many cool code changes this will bring, we also
switched to the MSYS2 environment on Windows to build Geany.
Paired with this we changed the build system from Waf to Autotools on
Windows and also the bundled GTK runtime environment is taken from the
MSYS2 environment.

So quite a few changes regarding the Windows support.
Ideally, users won't notice this much as Geany should work as before.

There should be only place where users notice the changes: in the
plugin
manager. Beginning with 1.27, we will ship many more plugins like
Markdown, Webhelper, GeanyPG and some more which were not built before
because of missing dependencies.
The drawback is that the size of the Plugins installer increased from
about 3 MB to 30 MB, but hey, you get WebkitGTK for Windows included.
This is more than just batteries :).



Is GeanyPy in there? I remember some discussion about it but I can't
find it anywhere to see what the result was.


Nope, sorry.
It was already a lot of work to get the majority of the plugins working
and all the related work with changing from Waf to Autotools on MSYS2.
I skipped the GeanyPy part.



Bummer. GeanyPy was written to be Windows-friendly from day one, and
upstream even has a Make file to create a Windows release. Maybe I could


Still it requires additional work.
It's not that I explicitly ignored it, just put the main focus on G-P in
general to get it working. Unfortunately, for 1.27 there is no time left.



generate a new installer from upstream and host/link it on geany.org
releases page?


Sure.
Or just contribute to the missing bits to G-P.
Not that it is new that we are running out of time with Windows stuff
close to a release. This is partly my bad but I also never cried to be
only one to care for Windows releases...



How dare you! After we paid you all that money to oh wait :)

It's no biggie, GeanyPy has some annoying dependencies, and waiting till 
the day before release to check if it was going to be included certainly 
isn't the best way for me to contribute to getting it in the release.


Cheers,
Matthew Brush

___
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

[Matthew Brush]

On 2016-03-12 03:28 AM, Enrico Tröger wrote:

On 12/03/16 02:56, Matthew Brush wrote:

On 2016-03-06 02:52 PM, Enrico Tröger wrote:

Hi,

as you might have noticed, Geany 1.27 is near.
And among all the many cool code changes this will bring, we also
switched to the MSYS2 environment on Windows to build Geany.
Paired with this we changed the build system from Waf to Autotools on
Windows and also the bundled GTK runtime environment is taken from the
MSYS2 environment.

So quite a few changes regarding the Windows support.
Ideally, users won't notice this much as Geany should work as before.

There should be only place where users notice the changes: in the plugin
manager. Beginning with 1.27, we will ship many more plugins like
Markdown, Webhelper, GeanyPG and some more which were not built before
because of missing dependencies.
The drawback is that the size of the Plugins installer increased from
about 3 MB to 30 MB, but hey, you get WebkitGTK for Windows included.
This is more than just batteries :).



Is GeanyPy in there? I remember some discussion about it but I can't
find it anywhere to see what the result was.


Nope, sorry.
It was already a lot of work to get the majority of the plugins working
and all the related work with changing from Waf to Autotools on MSYS2.
I skipped the GeanyPy part.



Bummer. GeanyPy was written to be Windows-friendly from day one, and 
upstream even has a Make file to create a Windows release. Maybe I could 
generate a new installer from upstream and host/link it on geany.org 
releases page?


Cheers,
Matthew Brush

___
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

[Matthew Brush]

On 2016-03-06 02:52 PM, Enrico Tröger wrote:

Hi,

as you might have noticed, Geany 1.27 is near.
And among all the many cool code changes this will bring, we also
switched to the MSYS2 environment on Windows to build Geany.
Paired with this we changed the build system from Waf to Autotools on
Windows and also the bundled GTK runtime environment is taken from the
MSYS2 environment.

So quite a few changes regarding the Windows support.
Ideally, users won't notice this much as Geany should work as before.

There should be only place where users notice the changes: in the plugin
manager. Beginning with 1.27, we will ship many more plugins like
Markdown, Webhelper, GeanyPG and some more which were not built before
because of missing dependencies.
The drawback is that the size of the Plugins installer increased from
about 3 MB to 30 MB, but hey, you get WebkitGTK for Windows included.
This is more than just batteries :).



Is GeanyPy in there? I remember some discussion about it but I can't 
find it anywhere to see what the result was.


I'll try and test it on Win10 Pro 64-bit tonight if I get a chance.

If you update the snapshot installers to latest master, please ping this 
thread so I know to update the copy to test.


Cheers,
Matthew Brush


Here we go:

http://download.geany.org/snapshots/geany-1.27nightly_setup.exe
http://download.geany.org/snapshots/geany-plugins-1.27nightly_setup.exe

If you can, please test and report issues as soon as you on Github as
time is already close to the 1.27 release.

Thanks a lot,
Enrico



___
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] Zombified pull requests

[Matthew Brush]

On 2016-01-06 02:44 AM, Thomas Martitz wrote:

Am 06.01.2016 um 04:32 schrieb Matthew Brush:


Agree, I sometimes avoid putting LGTM when I think something is a good
idea, because I don't want to give the impression that I have (or even
will) reviewed or tested it. Maybe just a "thumbs up" could mean "good
idea, though I haven't reviewed or tested it"?



Github is a terrible code review platforms. Other platforms do much better:
1) Differentiate between [x] I have reviewed [x] I have tested [x] I
like the change (no test or review)
2) Handle updated changesets without losing comments, to the point that
you can even browse older revisions

1) is a problem for reviewers and 2) is a problem for everyone

There are a lot of other, much better code review systems, but I guess
we're stuck with github (bought into proprietary solution, anyone?)



Not strictly. Given enough demand, and buy-in, we could switch to most 
other such tools. We do have adequate hosting for something better, 
though I doubt there's much desire to switch to a solution that doesn't 
support Git as the VCS. For the most part I find Github to be basically 
adequate myself, though it's not without issues.





To give an example of such a "functionality review", the fractional font
sizes patch

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

LGTM - even though I probably won't use it myself, I understand it
may be
useful for someone and it modifies just 23 lines so it's nothing
intrusive
and can go in from my point of view.



Agree, and I've actually wanted for this before.


Such a review can be done in a few seconds so if everyone goes
through the
new pull requests from time to time, the patches will receive some
feedback
and it will be clearer whether it's something others want it in Geany.

2. Unclear status of some patches. Sometimes it might not be clear in
what
state the pull request is - I'd suggest adding at least the following
two
tags:

needs-work (reviewed with some comments that need to be addressed)
work-in-progress (not meant for review in the current state)

This will help to distinguish pull requests awaiting merge and pull
requests that aren't there yet.



Sounds like a good idea, I just added those labels. We also already
have "reviewed", which I believe means whoever added the label has
fully reviewed a PR and it's ready to be merged.


I can't put labels on github. The feature seems to be limited to those
with write access to the repository, so it's useless if we want more
reviewers.



If not a misconfiguration, I think this is a bummer.




3. Fear that the pull request isn't tested enough. I believe that if a
patch did undergo a review and there doesn't seem anything obviously
wrong
with it, it can be merged to master. I think there's no need for some
long-term private testing of a patch before it gets merged - people
using
the development versions of Geany should be aware it may contain bugs
and
should know how to deal with them. There are also more eyes so a
potential
bug is spotted earlier. Of course it makes sense getting more
conservative
towards the end of the development cycle to stabilise things.



This is a big one too. Since we don't have a "development" branch (or
rather "master" is the development branch), we often have too high
standards, only merging stuff that is 100% finished, debugged and
ready to release. This kind of defeats the purpose of a development
branch.

Assuming there's a general consensus that a PR is a good idea, I agree
we should start integrating it early, even if there's some possibility
it could break things. This way it can get tested in real-life by more
than just the person who initiated the PR and others could/would make
their own PRs to fixup any perceived issues. When a PR sits off on
someone else's repo, it doesn't get real testing, and people (rarely)
make PRs against the repo where it came from, where they more likely
would if it was in the main repo.



I agree. Currently there is a culture that everything must be perfect
prior to merging. This is fine in theory but simply doesn't scale. It
requires endless iterations which in turn require a lot of re-testing,
and results in PRs sitting for way longer than necessary. Up to the
point where the rate of new PRs can't be handled.

I agree that PRs should be merged earlier, with possible
fix-up/follow-up commits in a new PR. This way changes acutally get the
testing they need.


OK, these are things that come into my mind regarding the zombie pull
requests but there may be other problems. What do you think? Do the
points
above look reasonable to you and do you think they might help a bit? Is
there anything else that might help killing the bloody zombies?



4. Lack of collaboration; We tend not to use Git to its full potential
by making pull requests against active pull requests. I don't know if
it's a lack of Git knowledge or that it's too much hassle, but we
rarely seem

Re: [Geany-Devel] Zombified pull requests

[Matthew Brush]

On 2016-01-06 03:47 AM, Lex Trotman wrote:

On 6 January 2016 at 20:44, Thomas Martitz <ku...@rockbox.org> wrote:

[...]
I agree that PRs should be merged earlier, with possible fix-up/follow-up
commits in a new PR. This way changes acutally get the testing they need.


The problem with a development branch and with making master more
buggy/less stable is that they will be used less, since its dangerous
to use them day to day.  So the testing will go down even more.



I personally don't mind the odd bug cropping up here and there on a 
project which I actively contribute and keep up to date with the 
bleeding-edge development code. Of course if you're doing 
mission-critical stuff, you don't want to be using the bleeding-edge, 
potentially buggy code anyway, the latest release from your distro is 
much less likely to cause grief.






6. Monster PRs [...]


Yes, monster PRs are difficult to deal with [...]


You are right that individual commits on a monster PR don't help much
unless they can be reviewed, tested and committed individually.

The way massive changes are handled on Julia is for the OP to put up a
PR (or just an issue) with a list of the steps required for the whole
change.  Individual PRs that make preparatory changes then refer to
this so there is a context for them and they can be smaller and easier
to review/test.



+1


7. Lack of committers/commits [...]


I agree. The more the merrier, if it helps spreading the workload. Jiří is
an awesome candidate, especially since he's the official MAC guy.

I'd volunteer as well. However, given how I'm constantly failing to do good
PRs initially or even after 2 or 3 revisions (by Colomban's standards), I'm
not sure I'm suitable.


The MOST important thing for a commiter is not killer programming
skills, its maturity.  Can the person be trusted to not commit their
own PRs without others agreement?  Can the person be patient enough to
wait for comments and other people to test, not everybody is available
every day. Does the person understand their own limits, will they ask
before committing to an area they have never touched before?  Having
commit rights is not about getting the persons own PRs into Geany, its
about getting others changes in.



+1


So if you think you can handle the above, I don't see why both you and
Jiri would not be acceptable (assuming Jiri is interested, I don't
know if he was asked :).



+1

Cheers,
Matthew Brush

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

[Matthew Brush]

On 2016-01-06 12:23 PM, Thomas Martitz wrote:

Am 06.01.2016 um 21:12 schrieb Jiří Techet:



It's indeed at least interesting to consider, because at least for .h
headers there really is some mixed stuff all over the place -- even,
simply look in Scintilla's source tree.


+1 for having the headers parsed/lexed by the C++ parser (with sources
it may be a bit dangerous and typically the sources have the right C++
extension).




Not replying to Jiří specifically.

-1. .h is legitimately a C, it's just that many people get it wrong. And
I don't want C++ keywords highlighted in C headers while they are not
highlighted it C source files. This is just confusing.



Why is .h any more C than C++ or Obj-C? Because it came first? I agree 
it's stupid that in the later part of last millennium, they decided on 
the convention to use .h for C++ and Obj-C (and others?) headers since 
it was already a convention in C, but it did become a convention in C++ 
and now it's widely used, for example [0][1][2][3] among many, many others.


What's more, it's especially useful to see C++ keywords highlighted in 
.h header files, since they can be included in C++ as well as C[4][5][6] 
unless their author wants to make them less useful by using said 
keywords in the header. I think the most common case would be someone 
doing it inadvertently (as happened in Geany), which is where having 
them highlighted differently gives a visual queue that something is 
wrong[7].


Cheers,
Matthew Brush

[0]: https://git.gnome.org/browse/gtkmm/tree/gtk/gtkmm
[1]: https://github.com/qtproject/qtbase/tree/dev/src/corelib/global
[2]: https://gcc.gnu.org/onlinedocs/libstdc++/latest-doxygen/files.html
[3]: http://sourceforge.net/p/scintilla/code/ci/default/tree/src/
[4]: https://git.gnome.org/browse/gtk+/tree/gtk/gtkwidget.h#n38
[5]: https://github.com/spurious/SDL-mirror/blob/master/include/SDL.h#L61
[6]: 
http://sourceware.org/git/?p=glibc.git;a=blob;f=include/stdlib.h;h=352339e8595eb8229018cb27f7d2decf63f511c7;hb=HEAD#l16
[7]: Or if the author is being evil on purpose, it gives them the smug 
satisfaction that they're making life hard for C++ programmers :)

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

Re: [Geany-Devel] Zombified pull requests

[Matthew Brush]

e or that it's too much hassle, but we rarely 
seem to do this (I've only done it a couple times, Colomban does it more 
often I think). Instead we make comments like "you should do this or 
that", assuming that the only person who must make changes is the pull 
requester. If instead of making "do this" comments, we made pull 
requests to show/implement it, it would give something concrete to 
discuss and increase collaboration on the code.


5. This one applies to many of your PRs Jiří :) Speaking only for myself 
here, any PRs made against CTags or TagManager I pretty much ignore. Not 
only that I'm completely unfamiliar with their code, but also the 
changes are often very subtle and require in-depth knowledge of those 
code bases, and I'm neither qualified nor inclined to make any judgments 
about the PR, let alone review or merge them.


6. Monster PRs. This goes along with #3. Sometimes PRs are just too big 
to be digested by volunteer developers all at once. If we started 
integrating such larger changes earlier, and in smaller pieces, I think 
it would increase the likelihood of getting the feature/changes merged 
into the master branch. When a PR is so big, it basically takes as much 
time to fully review and test it as it did to make the changes in the 
first place. I personally rarely merge pull requests unless I've 
reviewed and understand each line of code that changed, and tested all 
the cases I can think of. As volunteer like the rest of us, I just 
simply can't afford to spend days/weeks reviewing, understanding, and 
testing such large PRs, especially if I'm rather indifferent on the 
feature/improvement they implement.


7. Lack of committers/commits. There's 7 people who have write access to 
the repo. Of them, Colomban probably does > 95% of the actual 
merges/commits. IMO, we either need more people able to assign 
themselves and merge pull requests, or we need to spread the workload 
out between those who already can. Personally, when I get some time, I 
go through and cherry pick the very simple/trivial PRs and try and merge 
them, but it's not very fair to leave all the really hard ones for 
Colomban (not to put words in his mouth). If this existing committers 
don't have enough time or interest to keep on top of pull requests, then 
all we can do (besides status quo) is to have more interested, trusted 
developers able to merge pull requests.


Cheers,
Matthew Brush

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

[Matthew Brush]

On 2015-12-29 3:24 AM, Lex Trotman wrote:

My only comment is to add to the point that the build commands are
different.  For example C that uses "template" as a variable won't
compile with C++, a trap for beginners or existing code (just like
Geany used to have).



It's probably best that beginners learn early why using "template" or 
other C++ keywords is a rather bad idea, even in plain C. But yeah, 
there's otherwise a pretty big difference between languages/compilers.



But I would like to also propose (again) an orthogonal split, C/C++
headers from C/C++ bodies.  The headers need different compile
commands from the bodies.  Using the same command as happens now
generates a pre-compiled header file, and then any changes to the
header source are not seen when the body is compiled.



As mentioned below, individual file-specific compile-commands is not 
very useful, at least with C or C++.



This can waste significant time, just because the user hit compile
after fixing a header issue, but before switching back to the body
file.  Its a really nasty trap waiting for the unaware or beginner,
and one which we shouldn't be creating.



This is more of a bug that (some) build-commands are bound to individual 
files, which is generally never useful. In most IDEs (including Geany), 
when you trigger a rebuild/re-run, it saves all the files and runs the 
project's build system. Geany supports this fine, and I've never 
personally found any of the file-specific build commands useful. IMO, if 
you trigger a filetype-specific build command on a header, building a 
pre-compiled header file is a perfectly reasonable thing to do (why 
would you individually compile a header otherwise, anyway? Only reason I 
can see is "on accident").



As an alternative to separate filetypes, both of these problems could
be avoided if build commands could be different for different
extensions.  then one C/C++ filetype is definitely more viable.



Sounds like it would be useful.

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

Re: [Geany-Devel] RFC: New Custom Filetypes Repository

[Matthew Brush]

On 2015-12-19 09:04 PM, Lex Trotman wrote:

Sounds like a reasonable idea, but it triggered me to ask about
licenses and copyright. [...]


As a lesson learned from geany-themes project, I suggest we use a single 
license for all files. I'm pretty sure there isn't much IP issues with 
filetype configurations, but just in case, having a single permissive 
license removes all doubt and makes it easier for packagers.


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

[Geany-Devel] RFC: New Custom Filetypes Repository

[Matthew Brush]

Hi all,

We often get contributions for adding custom filetypes to Geany, and we 
even have some in the source tree already. We tend to not want to add 
them to Geany repo, usually due to limited functionality, or limited 
popularity.


I would like to propose that we add a new repository to Github, similar 
to geany-themes, where we add any custom filetypes that are useful, but 
perhaps aren't up to par or popular enough to add to Geany proper. This 
would give a single place to get them all at once (via Git or Github Zip 
file download), and also a repo for packagers to use should they want to 
provide a package.


Inside the repo we could have the README or some other file cataloging 
all the filetypes, along with who contributed them, their status, like 
whether tag parsing works, syntax lexing, and such meta info. As a 
start, we could add all of the filetypes from the Wiki[0], any useful 
ones from pull requests, and even any questionable ones already in Geany 
(if there are any). We could also add some shell script or something to 
install them into a user's home dir all at once, if that's useful.


What do you think?

Cheers,
Matthew Brush

[0]: http://wiki.geany.org/config/start
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] Certain functions won't compile since 1.25+

[Matthew Brush]

On 2015-12-14 4:45 AM, Per Löwgren wrote:

Hi!

First and foremost, thank you for the absolutely wonderful job you're doing
with Geany!

I'm working on my plugin Djynn, which is registered as a third-party plugin
at the moment. Recently some functions won't compile, it seems since 1.25,
though I didn't have this problem a few months ago. Most compiles however,
it's only these functions I've noticed: filetypes_detect_from_document,
project_close, project_load_file, document_close_all.

All those functions generate this error: "error: implicit declaration of
function ‘...’"

This means the functions aren't somehow included with "#include
", though they are when I look in the headers, but I do
notice a "#ifdef GEANY_PRIVATE" wrapping these functions. So I wonder if
they are removed as available to plugins, or can I simply define
GEANY_PRIVATE? Would that cause any problems? Or is there a work around
I've missed?

I regularly read this list, it may be I've missed any updates or changes in
the API; sorry for taking up your time in case you've already declared such
changes.



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. If 
you need those functions though, they can likely be added to the public 
API with a pull request.


Cheers,
Matthew Brush


[0]: http://www.geany.org/manual/reference/

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

Re: [Geany-Devel] Win32 GTK3 32/64-bit Installer Generator

[Matthew Brush]

On 2015-11-22 10:30 PM, Matthew Brush wrote:

Hi,

I made a script [...]


I did some more hacking on it and made it to allow to specify which GTK+ 
major version to use. It accepts short command line arguments now like 
-a for architecture, -g for GTK+ version, and -d to enable a debug build.


Some of the TODO items:

- Make it use existing NSIS script somehow.
- Find cause of and fix GTK+ 3 64-bit file dialog crashes
- Remove related source code changes
- For GTK3, take icons from Tango icon set, not Adwaita, to better
  fit with our custom icons.
- Enable better theme (ms-windows?) for GTK. I forget how to do this
  per-app without modifying the source code.
- Convert nice shallow intuitive program files directory structure
  back to confusing standalone Unix-style root file system (Bleh :)
- Remove related source code changes
- Move parts of the script into an Arch package recipe?

And whatever else...

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

[Geany-Devel] Win32 GTK3 32/64-bit Installer Generator

[Matthew Brush]

Hi,

I made a script and to generate a Geany installer. I had to make a few 
patches to Geany and it's probably not exactly stable/release-worthy, 
but it seems to work OK here, if not a bit slow.


I tested the 32 and 64-bit installers on Windows 10 and also the 32-bit 
one on Windows Vista.


Branch is here:

https://github.com/codebrainz/geany/tree/win32-installer

The script is in the branch, here:

https://github.com/codebrainz/geany/blob/win32-installer/scripts/win32-installer-msys2.sh

With a MSYS2 install and desired toolchain installed in it, after 
possibly editing the top of `scripts/win32-installer-msys2.sh` for a 
couple paths, run from appropriate 32 or 64-bit msys2 shell in a 
directory where the build cruft can go. After too many minutes it will 
output installer .exe in the current dir. Pass `i686` or `x86_64` as 
argument depending on the output architecture (default is i686). See top 
of the `win32-installer-msys2.sh` script for more details.


Please excuse my lack of Bash scripting skills.

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

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

[Matthew Brush]

On 2015-11-21 5:42 AM, Frank Lanitz wrote:

Hi folks,

Since a few releases I'm experiencing some not optimal way of
development which is surely caused by the long history we already have
on g-p as well as by the many people around luckily contributing to the
plugins collection: More and more plugins are going into some kind of an
orphaned state. There is some maintainer available but not really
responsive e.g. due to workload at reallife etc. However, at the end
some of the plugins are still compiling but not effectively working any
more with recent Geany version or its documentation is really outdated
-- when I was preparing the commits for waf removing I have seen plugins
still depending on Geany 0.16 ... I'm pretty sure, if they would, they
would compile any more ;)

Also the documentation of each plugin are differing in style, size and
quality much. (and I have to include the plugins I'm maintaining here
100% too). At github we already got a bunch of bug reports and pull
requests for plugins waiting for any response. Also there is a long
backlog at sf I've been told.

This is what I was thinking of to improve the situation (the overall
experience for our users)

1) Deactivating all plugins / out comment all plugins from MAINTAINERS
2) Cleaning off NEWS, Changelog etc. from individual plugin folders


I don't think I ever edited these files for my plugins, at least not 
after adding the plugin initially. All changes are in the Git log.



3) Moving documentation of all plugins into a structure like
doc/ to get a real fitting (online) manual. At this
point update documentation and bring them to some markup stil (Rest?
md? Docbook? I don't care at this point)


I don't like that all plugin files aren't self-contained inside own 
plugin dir. The "build" directory is already like this, plugins have to 
put M4 files separately into that dir. Maybe we could have a script 
that, when generating the manual, can just automatically combine all the 
markup files from each plugin dir?



4) Moving all plugins into a subfolder like plugins/ to
clean up / of g-p a little


This sounds OK, clean up the root dir a bit.


5) Reactivating plugins by a pull request of the actual (old|new)
maintainer maybe doing steps 2-4 and comment back in the plugin in
MAINTAINERS. Also I would be happy if at this point po/POTFILES.in
is reviewed etc.
6) Release a cleaned up g-p
7) Post 1.27 puring not update plugins from src tree

What do you think about this idea? I would combine this with some
release goals like complete support of Geany Gtk3 stack (if applicable).



I would add;

8) Rename all plugins that start with "Geany" to remove the "Geany" 
prefix. It's annoying in the plugin manager and in the source tree 
having all kinds of plugins clustered at the letter G, and obviously the 
plugins are for Geany.


9) Remove redundant plugins. Have a rule that only one plugin to do one 
thing is allowed and if someone wants to work on a plugin, they should 
either work on the existing plugin, or else give reasoning why a new 
plugin should replace the existing one. It's too confusing for users, 
and they end up using the wrong (old unmaintained) plugins.


10) Support for Git submodules so plugins don't have to be forked to be 
included in Geany-Plugins collection, they just need to use Autotools as 
their build system. This would also require making the build system to 
support building the plugins using (parts of) their build system.


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

Re: [Geany-Devel] Up to date geany plugin tutorial

[Matthew Brush]

On 2015-11-19 10:20 PM, Arthur Peka wrote:

Hi,

is there any up-tp-date plugin tutorial? The official one -
http://www.geany.org/manual/reference/howto.html - seems to be outdated,
example plugin doesn't compile.



Hi,

Are you using the latest Geany? The online manual is for the latest 
release (1.26).


Cheers,
Matthew Brush

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

Re: [Geany-Devel] More Contributions (DevynCJohnson)

[Matthew Brush]

On 2015-11-11 9:16 PM, Lex Trotman wrote:

On 12 November 2015 at 14:49, Matthew Brush <mbr...@codebrainz.ca> wrote:

On 2015-11-11 3:36 PM, Lex Trotman wrote:


On 12 November 2015 at 02:07, Devyn Collier Johnson
[...]



I remember someone on GitHub in the Geany project (I do not remember who
or
where) mentioned something about adding WTFPL to the license templates.
Is
that still desirable? Are there other licenses any of you would like me
to
add in the future?



No.  Its not really a "license" to be encouraged IMHO.



Because of the swear word?


Well that doesn't help of course. :)

But mostly because (subject to the standard IANAL disclaimer) as I
read it, it allows you to do anything you want with the license, but
says nothing about any other material.

And without a disclaimer it would allow me to sue the pants off of you
if the software under it didn't do what you said it did.



From the FAQ[0]:

> Is the WTFPL a valid license?
>> Although the validity of the WTFPL has not been tested in courts,
>> it is widely accepted as a valid license. Every major Linux
>> distribution (Debian, Fedora, Arch, Gentoo, etc.) ships software
>> licensed under the WTFPL, version 1 or 2. Bradley Kuhn (executive
>> director of the Free Software Foundation) was quoted saying that the
>> FSF’s folks agree the WTFPL is a valid free software license.

Cheers,
Matthew Brush

[0]: http://www.wtfpl.net/faq/

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

Re: [Geany-Devel] More Contributions (DevynCJohnson)

[Matthew Brush]

On 2015-11-11 10:06 PM, Lex Trotman wrote:

On 12 November 2015 at 15:50, Matthew Brush <mbr...@codebrainz.ca> wrote:

On 2015-11-11 9:46 PM, Lex Trotman wrote:


Because of the swear word?




Well that doesn't help of course. :)

But mostly because (subject to the standard IANAL disclaimer) as I
read it, it allows you to do anything you want with the license, but
says nothing about any other material.

And without a disclaimer it would allow me to sue the pants off of you
if the software under it didn't do what you said it did.



  From the FAQ[0]:


Is the WTFPL a valid license?


Although the validity of the WTFPL has not been tested in courts,
it is widely accepted as a valid license. Every major Linux
distribution (Debian, Fedora, Arch, Gentoo, etc.) ships software
licensed under the WTFPL, version 1 or 2. Bradley Kuhn (executive
director of the Free Software Foundation) was quoted saying that the
FSF’s folks agree the WTFPL is a valid free software license.



Hmmm, ok, clause 0, the operative clause is so brief I missed it :)

But the fact that it doesn't have a disclaimer is still risky.



 From the next question in the FAQ[0]:


Why is there no “no warranty” clause?

  The WTFPL is an all-purpose license and does not cover only computer
  programs; it can be used for artwork, documentation and so on. As
  such, it only covers copying, distribution and modification. If you
  want to add a no warranty clause for a program, you may use the
  following wording in your source code:

  This program is free software. It comes without any warranty,
  the extent permitted by applicable law. You can redistribute it
  and/or modify it under the terms of the Do What The Fuck You Want
  To Public License, Version 2, as published by Sam Hocevar. See
   http://www.wtfpl.net/ for more details. */




Bottom line is its still crap, and should not be supported.




You expressed my sentiments about the GPL perfectly ... oh wait :)

Cheers,
Matthew Brush

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

Re: [Geany-Devel] More Contributions (DevynCJohnson)

[Matthew Brush]

On 2015-11-11 3:36 PM, Lex Trotman wrote:

On 12 November 2015 at 02:07, Devyn Collier Johnson
[...]


I remember someone on GitHub in the Geany project (I do not remember who or
where) mentioned something about adding WTFPL to the license templates. Is
that still desirable? Are there other licenses any of you would like me to
add in the future?


No.  Its not really a "license" to be encouraged IMHO.



Because of the swear word?

Cheers,
Matthew Brush

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

Re: [Geany-Devel] DevynCJohnson's Ideas (November)

[Matthew Brush]

On 2015-11-08 2:34 PM, Devyn Collier Johnson wrote:

Geany Dev Team:

I have some additional ideas that I would like to share with you all and
get feedback before I implement the code.

*./data/filetype_extensions.conf*

- Adding "*.s03;*.s79;*.s82;*.s90;*.s;*.S;" to "ASM="
*.s## - GNU-style Assembly (GAS/AT)
Capital "S" - Must be preprocessed
Lowercase "s" - Does not require preprocessing
The numbers appended to *.s indicate the assembly version or intended
microprocessor [...]


Does the ASM lexer support the AT syntax? I thought it was for Intel 
syntax (NASM/MASM/etc), but if not, adding .S seems to make sense, it's 
what GCC outputs when you tell it to generate only assembly (-S option 
IIRC).




- Adding "*.ll;" to "ASM="
I suggested this before, but I want to ensure that the team is okay with
this idea before I commit and PR
LLVM assembly ( http://linux.die.net/man/1/llvm-as )



Does the ASM lexer support LLVM IR? It's quite a bit different from 
either Intel or AT syntax.



[...]

- Adding "*.r;*.f15;*.F15;" to "Fortran="
*.r - Fortran source code which must be preprocessed with a RATFOR
preprocessor


The *.r one is probably more commonly used for R language code, which is 
already in the filetype_extensions.conf. Adding it for Fortran means it 
will get used first, and R programmers will have to start editing the 
file manually to restore previous.



http://labor-liber.org/en/gnu-linux/development/extensions
*.f15 - Fortran 2015
http://fortranwiki.org/fortran/show/File+extensions

- Adding "*.xaml;" to "XML="
XAML (Extensible Application Markup Language)
This is a markup-language made by Microsoft
XAML is used in .NET Framework 3 and 4
[...]


It's also used for non .NET-specific stuff like the Ribbon framework. 
Seems OK to add this one to me.




*Previous Ideas*

These proposed Python file-extensions are not officially mentioned in
the Python Documentation. I shared this idea previously in the mailing
list, but I would like to know if this idea is a possibility or a
definite "no". However, some programmers use the extensions.
- py2 and py3
Used to specifically distinguish Python3 code from Python2, especially
when code is written that only works on one of the two versions.
- pygtk
Used to specifically show that a script contains PyGObject or PyGTK
code, as opposed to Qt
- pyqt
Like pygtk, but used to specifically show that a script contains PySide
or PyQt code

After reading my explanation, what do you think about the suggested
Python extensions?



I've been programming in Python for almost a decade and have never come 
across any of those extensions. Not that it means nobody uses them, just 
that they mustn't be very popular. Even IDLE doesn't recognize those 
extensions (at least on Windows 10).



*Possible Ideas*

[...]

- I would like to add support for Qt's QML (Qt Meta Language or Qt
Modeling Language). It is a scripting language that resembles JavaScript
( http://doc.qt.io/qt-5/qmlapplications.html ). If the Geany lexers and
parsers highlight this language well, would it be a good idea to add it?



See http://wiki.geany.org/config/qml?s[]=qml

I've done similar before and the result was tolerable, though QtCreator 
has far better support for QML, so I use that when coding QtQuick stuff.



[...]

- Add support for FASTA ( https://en.wikipedia.org/wiki/FASTA_format &&
https://en.wikipedia.org/wiki/FASTA [...]



Seems a little esoteric.

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

Re: [Geany-Devel] C++ Header Extension (was Re: DevynCJohnson's Ideas (November))

[Matthew Brush]

On 2015-11-08 12:25 PM, Matthew Brush wrote:



On 2015-11-08 3:19 PM, Lex Trotman wrote:

On 9 November 2015 at 05:34, Devyn Collier Johnson
<devyncjohn...@gmail.com> wrote:

[...]
- Adding "*.i;" to "C="
*.i - C source code which should not be preprocessed
http://labor-liber.org/en/gnu-linux/development/extensions


g++ treats this as C++, all languages are *not* C :)

This is the same problem as .h, it could be either.



I've been meaning to bring this up. We should move *.h to C++ now that
C++ can use C tags. Having it under C means C++ headers don't work, but
having it under C++ works for both C and C++ headers.



Oops, I forgot the tags from the C++ header wouldn't be visible in C 
files (the opposite is not true). I still think *.h should be for C++, 
but it's probably a hard sell for Geany crowd, it being written in plain 
C and all :)


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

Re: [Geany-Devel] [geany] document: show informational doc message after first reload (#672)

[Matthew Brush]

On 15-10-31 02:08 AM, Thomas Martitz wrote:

Am 31. Oktober 2015 02:52:01 MEZ, schrieb Matthew Brush 
<notificati...@github.com>:

[...] so unless there are actual problems I don't see an evidence to

keep the off default.

I mentioned a number of issues with it in the mailing list thread
linked from the PR you made to disable it by default.

I don't think we should cram this in just because of string freeze,
especially with the open issues, the UI issues, and that we will be
releasing again in a few months. I'm not opposed to the feature, I'm
opposed to the implementation (re-using an existing feature to do
something else, something unexpected of the existing feature, as well
as the infobar without a checkbox that can be hidden from the user
without ever seeing it).

---
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/672#issuecomment-152685983


Carrying this discussion to the ML.

Can you elaborate on the issues you see?



Mostly the stuff I mentioned in the previous mailing list thread on this 
subject. The semantics of the Reload feature have changed and no longer 
does reload mean "drop everything about this file and load it again" it 
means, "store another copy of this file in RAM and load it again". I 
feel like it's not a good idea to re-use the File->Reload feature like 
this, and under not uncommon scenarios, Geany is no longer "lightweight" 
with respect to RAM usage.


To give an example, if someone opened a big log file and Reloads it, or 
if they have many files from version control open and switch branches, 
every reload will "leak" the size of each document worth of memory, 
making Geany use much more RAM than before. Scintilla's undo mechanism 
just isn't designed to efficiently handle the case of the entire 
document being replaced. The only workaround to regain all the memory 
wasted by Geany is to close all the files and start over.


I think the new preference is fine, I just don't think it ought to be 
enabled by default, or else it ought to be associated with a new (Edit, 
not File) action altogether as opposed to changing the semantics of the 
existing feature as everyone is used to.



As to the UI. It's important that we get any UI for 1.26, therefore we had to 
manage before string freeze. [...]



Why is it important to rush it in before 1.26? One of the points of the 
accelerated release cycle is so that people would stop wanting to cram 
stuff in right before release. It's only a few months until next 
release, so there's no need to keep trying to rush in controversial stuff.


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

Re: [Geany-Devel] Introduction (DevynCJohnson)

[Matthew Brush]

On 15-10-31 10:27 AM, Devyn Collier Johnson wrote:

Geany Dev Team:

I would like to contribute to Geany. I have a GitHub account (
https://github.com/DevynCJohnson ), and I have committed some changes to
Geany. I love computers and programming. Geany is the IDE of my choice.
More about me can be learned from my website (
http://dcjtech.info/about-the-crew/#devyncjohnson ). By the way, my
website has "pop-under" ads; your computer cannot get "infect" nor is my
server infected (yes, people have been concerned about the ads).

I am experienced with computer programming, and I know several computer
languages and compilers (I prefer GNU-GCC). I am Linux+ certified (one
of y four computer certifications).

I intend on contributing a lot to Geany, so please feel free to tell me
if I am not following your coding and project standards. I will not be
offended (I promise). Currently, I am wanting to add support for
additional programming languages and file-extensions. After that, I
would like to add additional license notices.

Please feel free to give me tips and pointers pertaining to the project
and the team's "culture".



Welcome!

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

Re: [Geany-Devel] [geany] document: show informational doc message after first reload (#672)

[Matthew Brush]

On 15-10-31 11:54 AM, Thomas Martitz wrote:

Am 31.10.2015 um 18:59 schrieb Matthew Brush:

On 15-10-31 02:08 AM, Thomas Martitz wrote:

Am 31. Oktober 2015 02:52:01 MEZ, schrieb Matthew Brush
<notificati...@github.com>:

[...] so unless there are actual problems I don't see an evidence to

keep the off default.

I mentioned a number of issues with it in the mailing list thread
linked from the PR you made to disable it by default.

I don't think we should cram this in just because of string freeze,
especially with the open issues, the UI issues, and that we will be
releasing again in a few months. I'm not opposed to the feature, I'm
opposed to the implementation (re-using an existing feature to do
something else, something unexpected of the existing feature, as well
as the infobar without a checkbox that can be hidden from the user
without ever seeing it).

---
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/672#issuecomment-152685983


Carrying this discussion to the ML.

Can you elaborate on the issues you see?



Mostly the stuff I mentioned in the previous mailing list thread on
this subject. The semantics of the Reload feature have changed and no
longer does reload mean "drop everything about this file and load it
again" it means, "store another copy of this file in RAM and load it
again". I feel like it's not a good idea to re-use the File->Reload
feature like this, and under not uncommon scenarios, Geany is no
longer "lightweight" with respect to RAM usage.


Reload barely means "replace the buffer with the current file's
content", it's not connected to the undo history. And it still does that.



Semantically Reload should do exactly what Close and then Opening the 
file again would do. We've changed the meaning of an existing feature to 
do something different (replace text from current disk file).



You can disable that feature. What's your problem?



I don't think it should be enabled by default.



To give an example, if someone opened a big log file and Reloads it,
or if they have many files from version control open and switch
branches, every reload will "leak" the size of each document worth of
memory, making Geany use much more RAM than before. Scintilla's undo
mechanism just isn't designed to efficiently handle the case of the
entire document being replaced. The only workaround to regain all the
memory wasted by Geany is to close all the files and start over.


So you are concerned about very large files. I understand that. But
that's really an edge case, and I don't feel that everybody else should
suffer for edge cases. Especially not because Geany is an designed to be
an editor, not a very-large-file viewer.



Large files or many files. If someone has a huge project with many files 
open and changes Git branches, then for each of the documents, each time 
this is done, it will store a copy of the document in memory.



The various preferences are exactly for that, to make up for such edge
cases.



The change is the edge case, the existing behaviour which has been in 
place for almost 10 years is the "normal" case. I agree this should be a 
various preference (or an edit action), I just don't think it should be 
enabled by default, changing the existing (common) meaning of Reload.



BTW, I think we only store the undo on reload if the file has actually
changed since it was opened. So for simply viewing dumps there shouldn't
be an increased memory footprint:

 /* We only add an undo-reload action if the document
has actually changed.
  * At the time of writing, this condition is moot
because sci_set_text
  * generates an undo action even when the text hasn't
really changed, so
  * actions_count is always greater than zero. In the
future this might change.
  * It's arguable whether we should add an undo-reload
action unconditionally,
  * especially since it's possible (if unlikely) that
there had only
  * been "invisible" changes to the document, such as
changes in encoding and
  * EOL mode, but for the time being that's how we roll. */



If that's the case, and we somehow tell if the file changed, then we 
shouldn't be prompting the user or anything either.




I think the new preference is fine, I just don't think it ought to be
enabled by default, or else it ought to be associated with a new
(Edit, not File) action altogether as opposed to changing the
semantics of the existing feature as everyone is used to.


As to the UI. It's important that we get any UI for 1.26, therefore
we had to manage before string freeze. [...]



Why is it important to rush it in before 1.26? One of the points of
the accelerated release cycle is so that people would stop wanting to
cram stuff in right before release. It's only a few months until

Re: [Geany-Devel] About Malloc memory for each tab?

[Matthew Brush]

On 15-10-23 09:21 AM, Pengfei Sun wrote:

Hi Lex,

I have one question about tab switch in the geany. I know the different tab
has different doc->id. I think there is only one thread which manages all
tabs, right?  I wonder when we switch different tabs to edit the document.
How does geany manage or recognize different tabs? g_main_context_check
will be called in g_main_loop_run. Whether the data structure GMainContext
will include some information which can recognize the different tab?



Hi,

I know you weren't addressing me, but you might want to look into GTK+, 
the event-driven GUI toolkit Geany uses. When user changes a tab, the 
GtkNotebook widget emits a signal telling Geany about the event, and 
then Geany asks the GtkNotebook for the widget contained in the selected 
tab page, which (eventually) contains the Scintilla widget, via the GTK+ 
widget hierarchy.


If you're trying to track down the control flow via GDB or other 
debugger, the event-driven model is going to send you on a wild goose 
chase through hell :)


FWIW, doc->id is basically not very useful, it just tells the index into 
some internal array of GeanyDocument objects, but is not unique to each 
document/tab per se (it gets recycled for new documents and such).


Cheers,
Matthew Brush

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

Re: [Geany-Devel] About Malloc memory for each tab?

[Matthew Brush]

On 15-10-09 04:43 PM, Matthew Brush wrote:

On 15-10-09 03:42 PM, Pengfei Sun wrote:

[...] Do you have any further suggestions for my case?



I made a quick and dirty patch that will log on the terminal wherever in 
(virtual) memory the buffer is stored, whenever it moves, per-file. See 
attachment.


Cheers,
Matthew Brush

diff --git a/src/editor.c b/src/editor.c
index 1336588..840e979 100644
--- a/src/editor.c
+++ b/src/editor.c
@@ -1075,6 +1075,23 @@ static gboolean on_editor_notify(G_GNUC_UNUSED GObject *object, GeanyEditor *edi
 			if (nt->modificationType & (SC_MOD_INSERTTEXT | SC_MOD_DELETETEXT))
 			{
 document_update_tag_list_in_idle(doc);
+
+/* Tracking Scintilla buffer in memory */
+{
+	static const gchar *old_start = NULL;
+	static const gchar *old_end = NULL;
+	const gchar *start =
+		(const gchar *) scintilla_send_message(sci, SCI_GETCHARACTERPOINTER, 0, 0);
+	gsize len = scintilla_send_message(sci, SCI_GETTEXTLENGTH, 0, 0);
+	const gchar *end = start + len;
+	if (start != old_start || end != old_end)
+	{
+		g_print("** The buffer for file '%s' is at %p:%p\n", doc->real_path, start, end);
+		old_start = start;
+		old_end = end;
+	}
+}
+
 			}
 			break;
 
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] About Malloc memory for each tab?

[Matthew Brush]

On 15-10-09 03:42 PM, Pengfei Sun wrote:

Hi Lex,

Thanks for your suggestions.

I work on memory forensics. My part of project is to locate memory of the
sensitive data. For example, when I use the geany open one sensitive file,
and the content will be in the memory (heap). I hope I can locate all
memory related this sensitive file. And later I can do some analysis or
protection.

Now, I override malloc and can log all malloc functions to get return
address and size (I think g_malloc is a wrapper of malloc). But I still
cannot building the mapping between the special file and related heap
memory. I know each open or created file have different ID
(GeanyDocument->id). However, I still cannot figure out how to trace the
related memory of different ID. Assume I have open three files, so there
are three windows and three different GeanyDocument->id. I write or change
some things among these three windows. Meanwhile, I log all
malloc/realloc/calloc functions. I try to figure out which malloc belong to
window 1, which belong to window2 or window 3?  Do you have any further
suggestions for my case?



Hi,

To get from GeanyDocument to where the text buffer is stored:

  - First get to the Scintilla widget: doc->editor->sci
  - Then get a pointer to Scintilla buffer:
   scintilla_send_message(doc->editor->sci,
  SCI_GETCHARACTERPOINTER, 0, 0);
  - That call will close the editing gap, so if you call:
   scintilla_send_message(doc->editor->sci,
  SCI_GETTEXTLENGTH, 0, 0);
You can have the lower and upper addresses of the complete
contiguous document buffer.

But as Lex mentioned, the address no doubt changes as Scintilla grows 
and shrinks the buffer, so you can only know for sure where it lives 
between call to SCI_GETCHARACTERPOINTER and the next time the buffer is 
changed.


You mentioned in Github Issue about wanting to know about tag 
allocations, in `tagmanager/src/tm_tag.c` at the top is where you could 
hook into allocation of the tag structures (TAG_NEW/TAG_FREE macros, or 
else the log_tag_*() functions).


Happy Hacking,
Matthew Brush
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

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

[Matthew Brush]

On 15-09-22 03:42 PM, Lex Trotman wrote:

On 23 September 2015 at 00:35, Dimitar Zhekov <dimitar.zhe...@gmail.com> wrote:

Hi, all,

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

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


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

[...]



Agree SIGTERM sounds more polite. I think well behaved DEs (or is it in 
the window manager?) will prompt you to really kill a process if it's 
not responding, so we could leave that to them.




[...]




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


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



For now we could do something like:

/** @deprecated @see spawn_terminate_process() */
gboolean spawn_kill_process(GPid pid, GError **error) {
return spawn_terminate_process(pid, error);
    }

Cheers,
Matthew Brush

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

Re: [Geany-Devel] Github Comment Mails

[Matthew Brush]

On 15-09-02 01:13 PM, Enrico Tröger wrote:

On 22/08/15 12:13, Matthew Brush wrote:

On 15-08-22 12:51 AM, Enrico Tröger wrote:

On 22/08/15 02:03, Lex Trotman wrote:

On 22 August 2015 at 09:54, Matthew Brush <mbr...@codebrainz.ca> wrote:

On 15-08-21 02:26 PM, Enrico Tröger wrote:


On 19/08/15 05:46, Matthew Brush wrote:


On 15-08-18 08:43 PM, Lex Trotman wrote:


On 19 August 2015 at 13:37, Matthew Brush <mbr...@codebrainz.ca>
wrote:


Hi,

Is it possible to make an archived mailing list which can contain
threads of
comments posted to Github (maybe using Github API)? We have
sometimes
when
squash commits it deletes Github comments, but I thought maybe we
could have
some stable backup + URL to link to (ex. in commit messages, on the
mailing
list, etc) which could be searchable and googlable and not be
deleted
by
rebase.



Or by the remote deleting the branch



Yeah, it would be archived and not affected by force pushes, delete
branches or editing of comments.



Nice idea.
The mailing list itself would be no problem at all. It's more
difficult
to get the data from Github.
On https://github.com/geany/geany/settings/hooks there is
"services" and
they support "Email" but it will send mails only on pushes, not
what we
want.
An alternative would a web hook where you can choose detailed on which
events the hook is triggered. But then you need something on the
receiving side which takes the event and transform it into a mail to
send it to the mailing list. Possible but requires some work.

I just had a quick look at the available other services
(https://api.github.com/hooks) to find one which support commit and PR
comments and support something self-hosted (i.e. no new dependency on
some third-party service) but didn't find anything suitable.

One more option might be to use the Geany Github account and watch the
Geany repositories with this account to get notifications this way.
We just need to take care to setup a separate email address in the
Github account settings for notifications because the primary address
will be used for account settings/notifications/password resets. Those
should not be sent to a public mailing list :).
Should be possible and probably the easiest way.

If you agree, I could work on this.



Sounds like a good idea.

Did you look at the Github API proper? We could probably hack up a
script to
harvest the comments that way (it's really easy to use IIRC, it's
just some
URL queries and JSON responses). It might still need a service hook
or cron
event or something to trigger, but it might be workable.


Could probably just get them daily for this purpose.


I don't which way to go.
Grabbing the comments from the API is possible as I said above, I know
the API is quite easy to use, did so for the IRC commit messages and the
commit mails.

The Geany account notifications are very quick to setup. I don't
volunteer to write a script using the Github API although easy. If you
want to, I'd be happy to help setting it up if necessary.




The email notifications way sounds clean and simple. If it turns out not
to work right, we could try more elaborate API scripts and such.


Done: http://lists.geany.org/pipermail/github-comments/

This is the new mailing list.
I added the list address as notification email address to the geanyadmin
user and make this user to watch all repositories of the Geany Github
organization.
We just need to remember to make the geanyadmin user watch any new
repositories we create or even any other repositories on Github as
necessary.

I don't think it's that useful to subscribe to this list, the archive is
probably more interesting.

For now, I didn't set up Gmane to archive this list. It might be useful
to have the archive searchable. If anyone wants to do it, feel free.




Thanks!

It would definitively be useful to be searchable, but I have no idea how 
to hack on that mailman (Gmane?) thing, or however it goes.


Cheers,
Matthew Brush

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

Re: [Geany-Devel] Github Comment Mails

[Matthew Brush]

On 15-08-21 02:26 PM, Enrico Tröger wrote:

On 19/08/15 05:46, Matthew Brush wrote:

On 15-08-18 08:43 PM, Lex Trotman wrote:

On 19 August 2015 at 13:37, Matthew Brush mbr...@codebrainz.ca wrote:

Hi,

Is it possible to make an archived mailing list which can contain
threads of
comments posted to Github (maybe using Github API)? We have sometimes
when
squash commits it deletes Github comments, but I thought maybe we
could have
some stable backup + URL to link to (ex. in commit messages, on the
mailing
list, etc) which could be searchable and googlable and not be deleted by
rebase.


Or by the remote deleting the branch



Yeah, it would be archived and not affected by force pushes, delete
branches or editing of comments.


Nice idea.
The mailing list itself would be no problem at all. It's more difficult
to get the data from Github.
On https://github.com/geany/geany/settings/hooks there is services and
they support Email but it will send mails only on pushes, not what we
want.
An alternative would a web hook where you can choose detailed on which
events the hook is triggered. But then you need something on the
receiving side which takes the event and transform it into a mail to
send it to the mailing list. Possible but requires some work.

I just had a quick look at the available other services
(https://api.github.com/hooks) to find one which support commit and PR
comments and support something self-hosted (i.e. no new dependency on
some third-party service) but didn't find anything suitable.

One more option might be to use the Geany Github account and watch the
Geany repositories with this account to get notifications this way.
We just need to take care to setup a separate email address in the
Github account settings for notifications because the primary address
will be used for account settings/notifications/password resets. Those
should not be sent to a public mailing list :).
Should be possible and probably the easiest way.

If you agree, I could work on this.



Sounds like a good idea.

Did you look at the Github API proper? We could probably hack up a 
script to harvest the comments that way (it's really easy to use IIRC, 
it's just some URL queries and JSON responses). It might still need a 
service hook or cron event or something to trigger, but it might be 
workable.


Cheers,
Matthew Brush

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