Re: [Geany-Devel] Moving away from Github

[Thomas Martitz]

Am 06.06.2018 um 16:16 schrieb 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. 



I agree. For now, Github is just as proprietary as before so I see no 
reason for an immediate changeover.


I would welcome to use more open services in general. Although I'm not 
sure if Gitlab or anything else is any better if you can't afford 
self-hosting anyway.


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

Re: [Geany-Devel] How to force geany-plugins to build against GTK3?

[Thomas Martitz]

Am 20.02.2018 um 18:00 schrieb Lars Paulsen:

Hello All,

I have a simple question: how can I force geany-plugins to be built 
against GTK3?


I tried "CFLAGS=-dGP_GTK_VERSION_MAJOR=3 ./configure" but that did not 
help. I saw the line "Geany version:    1.33 (GTK2)" in 
the configure output. Do I have to re-build geany with the CFLAGS 
above to make the geany-plugins use GTK3? 



Geany-plugins must be compiled against the same GTK version as Geany 
core. There is simply no way that GTK2 and 3 co-exist in the same process.


Therefore geany-plugins always follows Geany in this regard.
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

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

[Thomas Martitz]

Am 25.01.2018 um 18:27 schrieb Colomban Wendling:

Le 25/01/2018 à 04:38, Lex Trotman a écrit :

On 25 January 2018 at 22:19, Nick Treleaven  wrote:

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

Long time no hear.  I can't help with Windows build speeds but can say
that the Linux build does not appear to be significantly slower
AFAICT.

No.  By default libtool might build object files twice, one static and
one shared, just in case it might need both, but I disabled it ages ago
as we don't need both
(https://github.com/geany/geany/commit/723f4302e0d7bbd938c789b9730366f7c7e03080).
  Maybe check if libtool on Windows doesn't enforce something stupid like
that.

But it might also be that MSYS2 is slow or something, but that Thomas
might know more about.


From my experience (it's been some time) shell scripts (i.e. configure) 
is horribly slow (disabling AV helps a lot but it's still bad), the 
compilation itself shouldn't be significantly slower than on Linux.


Can you compare a against Linux builds and post some numbers? Also, what 
kind of system is this?


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

Re: [Geany-Devel] Hooks on calling some functions for plugins?

[Thomas Martitz]

Am 03.07.2017 um 12:33 schrieb Денис Феклушкин:

Hi!

I am writing D language plugin on D:
https://github.com/denizzzka/geany_dlang

This plugin isn't adds any new functionality but I planning replace 
already implemented Geany functionality.


Especially, it will replace autocomplete list, tips list, symbol 
searching, syntax highlighting by same D's infrastructural libraries 
calls.


Questions: It is possible to...

... intercept some Geany to Scintillia messages by a plugin? 
(SCI_AUTOCSHOW, SCI_CALLTIPSHOW)


... replace call "Go to Symbol Definition"?

... fill out ctags info from external library instead of internal 
functions?


I would rather ask how the plugin could provide Geany the information to 
do proper autocompletion, symbol pane updates and tags on its own.


Maybe we need an interface so that TMTags can be provided by a plugin?

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

Re: [Geany-Devel] Plugin interface

[Thomas Martitz]

Am 22.06.2017 um 17:50 schrieb Lars Paulsen:


But please keep the assigned maintainers in the loop in case of 
plugins inside geany-plugins.
Shouldn't they get a notification anyway from github as soon as I 
place a PR?
If you prefer, I could additionally announce that PRs here in the 
devel mailing list? 


Usually no, since most maintainers are not affiliated with the Geany org 
on github, so they don't get notifications for new PRs, if you don't 
open them on their personal fork.


The ideal method would be to open the PR on the maintainers site, and 
have the maintainer ask Frank for pulling his collected changes just 
before the next release. Unfortunately, the maintainers are sometimes 
skipped over, and then people wonder why they go inactive (I wouldn't 
like if changes are made behind my back).


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

Re: [Geany-Devel] Plugin interface

[Thomas Martitz]

Am 22.06.2017 um 07:17 schrieb Lars Paulsen:

Hi Lex,

> It has been pointed out that I totally avoided actually explicitly
> answering the question, yes use the new interface.

:-)
Ok, will do that. If I find the time I probably will update the one or 
other existing plugin to the new interface and send a PR. 


Hi Lars,

yes, work on that is appreciated. But please keep the assigned 
maintainers in the loop in case of plugins inside geany-plugins.


Besides, your initial question, and lots more, should be answered in the 
API documentation at [1]. Have you seen that?


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

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

Re: [Geany-Devel] Plugin interface

[Thomas Martitz]

Am 22.06.2017 um 01:39 schrieb Lex Trotman:

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



I'm here, and I'm fine. I don't think there are open issues beside my 
PRs. I'm on hold as long as nobody looks at my various PRs are not being 
looked at. If there is any open work item, I'm able to work on it.


For what's it worth, I'm also waiting for waiting for #1112 [1] too 
before adding peasy to geany-plugins. So long it's publicly available at 
here[2]. I'm not motivated to work on #1112 because nobody would look at 
it at the moment.


I wonder if/when Colomban can be back in action?

[1] https://github.com/geany/geany/pull/1112
[2] https://github.com/kugel-/peasy

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

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

[Thomas Martitz]

Am 29.04.2017 um 02:35 schrieb Lex Trotman:

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.


master *is* the development branch. It's not a stable branch that must 
not be broken at all costs. It's also not true that everyone is using 
master. The vast majority is using releases, and in fact we do regular 
releases so that we can use master as a true development branch. Even I 
don't use master (a very regular contributor) for my clone that I use 
daily. I always fork the last release, merge my changes, and backport 
individual commits from master (via cherry-pick). Of course I develop 
features based on master, so I do test the master branch on a regular basis.


So yes, if you are afraid of doing development on the development 
branch, it's clear that we're struggling to get anything done. Sure, one 
can expect that PRs are perfect before getting merged, but the current 
situation shows that this is not working if you want to get something 
done in a timely manner.


From another angle, both of you could easily create a development 
branch. But you didn't so far. Anyway, how is that workflow supposed to 
work? If lots of PRs go through an intermediate branch then merging that 
intermediate branch into master is going to be a nightmare too.


Best regards.

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

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

[Thomas Martitz]

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.


So I think we need more people that can push code to Geany directly, 
effectively dividing the workload onto more people. It's just too much 
work for a single developer, especially these days.


Unless this situation improves, I'm afraid that intensive testing of PRs 
is nice but kind of a wasted effort. This is worsened by the fact that 
"unpreviliged" testers can't assign labels in Github, it's really hard 
to get an overview about which PRs have received extended testing.


In the meantime, we're scaring contributors away because contributes 
aren't looked at in a timely manner.


Take this as an application. I would love to actively help if I'm 
granted push or github-label-set access.


Best regards.
___
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

[Thomas Martitz]

Am 16.02.2017 um 15:55 schrieb 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"?



It's not being updated for new Geany APIs, nor does the upstream 
developer (you :-) review PRs in a timely manner, for a start.


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

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

[Thomas Martitz]

Am 01.09.2016 um 15:00 schrieb Lex Trotman:

[...]

It is of course always "possible", after all its a mere matter of
programming :)

And of course an instantiated class template is just a type, but what
is the name of std::vector and std::vector so it can be looked
up?


vector and vector, with scope being std (I think trailing scope
delimiters are not saved in the scope string of TMTag, just intermediate
ones).


Sorry Thomas, I was a little mean and laid a trap.



No problem. The devil is always in the details and we can only define 
requirements when looking and complicated cases.





std::vector has a second parameter, which has a default value so its
legal to omit it, but the type you will get from an accurate parser to
store in TM will be the complete type which will be something like
std::vector not just plain std::vector.
This is the type you see printed in g++ and clang++ error messages for
template expansions, very messy.

So the way TM does a pure textual comparison of the prefix in the
source code `std::vector` simply won't work to find
`std::vector`

It also won't work if there are spaces as I showed in a previous post
`std::vector< int >` is perfectly legal C++ but won't match
`std::vector`.  And before you ask, yes lots of code has the
spaces so that nested angle bracket closes (as in my
...allocator> above) look like > > not the >> operator.  Being
able to omit the space and not have it seen as a shift right operator
is only a recent addition to the standard.


OK, so we'd have to have a canonical representation of types (how this 
looks like is defined by the ft-plugin, e.g. whitespaces stripped, 
default parameters expanded) to compare against, and a method to find 
that tag when looking up std::vector< int >. It seems be complicated 
indeed, but doable. Most of the complexity will be in the ft-plugin 
providing canonicalized, tag-like data.




And for template functions declared as `templateT& f(T& t){
return t<<1; }` they are used as simply `int a = f(1);` not an angle
bracket in sight, and a textual comparison to find the declaration for
a calltip isn't going to work because no such explicit declaration
exists. So how can TM answer whats legal here `f(std::cout).` (answer
all of std::ostream) versus here `f(1).` (answer nothing).


I would say that a calltip for a templated function should show the 
generic function since you don't know what the user is going to type, 
regardless of the design (except perhaps if the specialized function can 
be inferred from the scope). Which specialized function is to be called 
changes as the user types. As I said in the other mail to Matthew, 
trying to infer from the lhs of the assignment is dangerous and 
impractical too (I would not want this behavior), especially if the lhs 
is determined only by the rhs (auto x = foo(1)).


Perhaps you can show specialized calltips once user has entered a few 
parameters but that's still guessing. I don't think this is a good idea.


But plain textual comparison against the function name seems to work 
best here to me.




[...]

Good point, the FT-Plugin API needs functions for goto declaration and
goto definition.  Unlike TM, the plugin can take language and scope
rules into account when it answers, so you get the right declaration,
continuing the theme above, where would you go to find the declaration
of std::vector ?

Certainly not the line:

std::vector list_of_ints;

thats the declaration of `list_of_ints` but thats the only place that
`std::vector` exists in the code.



Ideally the header which defines std::vector would be found (and maybe
opened) right? Currently this isn't possible with TMTag (as var_type can
only contain either vector or vector) but it shouldn't be too hard
to make it work.

But now you are encoding language specific semantics into TM, and as I
noted above its more complicated than just that example.


Generic ways to deal with language specific properties isn't quite the 
same. Also, this doesn't apply to just C++, other languages have complex 
meta programming / generic types too (Vala, Java, C#, etc.).


And even then, I'm totally fine with TM knowing language specifics. TM 
can hold every information needed to make smart language specific 
features work, preferably in generic ways. That doesn't mean TM has to 
semantically understand the language's source code, if the information 
is provided by external parsers. In fact, it doesn't have to understand 
source code itself at all.


There may be a point we want to limit the smartness anyway, if requires 
very complex solutions for little gain, extremely rare use cases or they 
it can become annoying to the user (e.g. if it requires to much setup).



Please don't get the idea from simple examples posted here that they
cover even a fraction of the craziness of languages (and not just C++
either, its simply the one I'm most familiar with).

  Like adding a generic_type field which is set 

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

[Thomas Martitz]

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?


This is not what I would want. I can remember function names but not 
necessarily their exact return value. It's possible (even likely) that I 
got gint wrong and correct it to glong after auto completion, when the 
call tip for the completed function tells me that glong. It'd be 
annoying if auto-completion can't find the function I want just because 
I misremembered the return type and the thing tries to be too smart.


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.


As Colomban and Jiri also mentioned it: auto-completion is also a useful 
tool for correcting typos and other programming errors.





[...]


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. 


Okay. Might as well pass the tags to Geany in the first place but it's 
important to make them available at all.


Best regards.

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

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

[Thomas Martitz]

Am 01.09.2016 um 08:05 schrieb Lex Trotman:

On 1 September 2016 at 15:08, Thomas Martitz <ku...@rockbox.org> 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.

It is of course always "possible", after all its a mere matter of programming :)

And of course an instantiated class template is just a type, but what
is the name of std::vector and std::vector so it can be looked
up?


vector and vector, with scope being std (I think trailing scope 
delimiters are not saved in the scope string of TMTag, just intermediate 
ones).






Geany must ask the plugin for the answer for each element of
functionality the plugin provides.  This means that those elements
have indeed simply moved "Geany's deficiencies to the plugin space" as
you put it.  This is good and necessary.


To me this is not good because it makes it impossible to use the information
for other use cases in Geany or other plugins.

For example, I want to keep my quickswitch plugin that allows me to jump to
arbitrary tags, even if a ft-plugin is doing all the hard work to parse
them.


Good point, the FT-Plugin API needs functions for goto declaration and
goto definition.  Unlike TM, the plugin can take language and scope
rules into account when it answers, so you get the right declaration,
continuing the theme above, where would you go to find the declaration
of std::vector ?

Certainly not the line:

std::vector list_of_ints;

thats the declaration of `list_of_ints` but thats the only place that
`std::vector` exists in the code.



Ideally the header which defines std::vector would be found (and 
maybe opened) right? Currently this isn't possible with TMTag (as 
var_type can only contain either vector or vector) but it 
shouldn't be too hard to make it work. Like adding a generic_type field 
which is set for each template instance (containing vector), then 
instead of looking up the decl of generic_type if it's not NULL, 
otherwise var_type.


Of course, the TMTags associated with vector and vector would 
have to provided by the ft-plugin too (maybe there needs to be a new 
TMTagType for vector too).





Of course moving the problem to plugin space doesn't mean the plugin
can't use Geany facilities where their capabilities fit the
requirement.  But we should not try to expand Geany to handle all
types of functionality.

Like your TM query interface, the plugins should answer the questions
like "whats the autocomplete here", "what calltips are relevant here"
with a flat list of data relevant to the question.


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

Only if your query plugin queries the FT plugin.



So that means

1) My plugin contains code specifically for each known ft-plugin (i.e. 
not the plugin API)
2) There needs to be a shared library which my plugin can use to call 
into the other plugin

3) My plugin needs to know if and when to ask a ft-plugin

This is not acceptable. Or are you saying Geany could provide a wrapper 
for this as Matthew suggested? That might be workable.


Best regards.


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

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

[Thomas Martitz]

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.





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.





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.



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.


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.


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 work flows, such as Makefile-based, which are often incompatible 
with mine e.g. the work flow at my workplace. I hugely appreciate that 
Geany gives actually (IMO) decent auto-completion and calltips out of 
the box (and can be improved with just setting a few file patterns with 
ProjectOrganizer), for any file I throw at it.


I do see that this is valuable for other people and languages so I'm not 
fundamentally opposed to do actual compiling (if done right). But there 
needs to be a decent fallback when this is not possible, even if it just 
means to fallback to Geany's builtin support (so I'd likely always fall 
back).


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

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

[Thomas Martitz]

Am 01.09.2016 um 05:42 schrieb Lex Trotman:

On 31 August 2016 at 11:27, Matthew Brush  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.

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

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

[Thomas Martitz]

Am 31.08.2016 um 16:52 schrieb Lex Trotman:

On 1 September 2016 at 00:43, Thomas Martitz <ku...@rockbox.org> wrote:

Am 31.08.2016 um 16:39 schrieb Matthew Brush:


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.


How do you pass {C,CXX,CPP}FLAGS to libclang? And where do you get them
from?

Libclang needs the full-fat build knowledge that "project" systems on
other IDEs provide.  Another reason to keep it separate from Geany.


So one would have to adjust the build settings and one or more 
ft-plugins all the time?


IMO, complex build system integration is out of scope for ft-plugins. 
But I see that not all features can be supported properly without build 
system.


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

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

[Thomas Martitz]

Am 31.08.2016 um 15:31 schrieb Lex Trotman:

I love Lex's ADL example, C++ can seem just crazy :)

Crazy like a Fox, makes the compiler near impossible, but makes lots
of stuff "just work" :)

So a much simpler example then (using C syntax to explain since we all
know it, but could be any language):

int a;
{
 first_piece_of_code_using_a...
 float a;
 second_piece_of_code_using_a 
}

For C/C++ the first piece of code will see `a` as an int and the
second piece of code will see `a` as a float, but there are languages
(Julia for one) where both pieces of code will see `a` as a float.
Again you need language specific knowledge to lookup `a` in the first
piece of code.


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.


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

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

[Thomas Martitz]

Am 31.08.2016 um 16:39 schrieb Matthew Brush:


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. 


How do you pass {C,CXX,CPP}FLAGS to libclang? And where do you get them 
from?


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

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

[Thomas Martitz]

Am 31.08.2016 um 13:23 schrieb Lex Trotman:

[...]

But
to be able to do 2) and 3) accurately needs more knowledge of each
language semantics than is currently available in Geany or tagmanager.


That's right. But it doesn't mean the features should be *entirely* moved
into plugin space. TM should be improved to be able to hold sufficient
information, and plugins should help by providing that data. But *just* the
data, don't offload very specific use cases onto them, this will make us
less flexible in the long run. If Geany has the data, we can implement new
features inside Geany or non-ft-plugins. Otherwise we would have to modify
every single ft-plugin for new features and exclude non-ft-plugins.

The problem isn't having the data, its what you do with the data.  To
repeat two C++ examples I posted on IRC:

namespace foo {
struct A { int a=1; int b=2; };
void f(A& anA, int inc){ anA.a+= inc; }
};

foo::A anA;
std::vector someAs;

The current Geany correctly parses this and shows the correct thing in
the symbols pane, so it has the data, it doesn't even need to use a
plugin for the data.

int i = someAs[1]. // Ok TM show me whatcha got, whats legal here?

Answer: a and b because the vector returns a reference to its template
parameter, here foo::A that has members a and b, you have to expand
the template to find the answer.  This is used all over the standard
library.

f( // no calltip because no f is defined in this namespace
f(anA, // so thats the calltip now?

Answer: void foo::f(A& anA, int inc) even though f() is in namespace
foo, because the first argument is type A which is declared in
namespace foo, ADL then will find foo::f().  This is also used in the
standard library and many other libraries.

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.


Best regards.


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

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

[Thomas Martitz]

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.





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


Your evaluation is still invisible to me.



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.


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


Then the symbol tree, completion, other plugins can use the tags and 
make their stuff.


For highlighting, I would really try to use Scintilla dynamic lexers. 
Otherwise we're going to have trouble with inconsistent editor widgets 
and non-working color schemes.


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

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

[Thomas Martitz]

Am 30.08.2016 um 15:38 schrieb Colomban Wendling:



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

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

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



I think we're on the same page here. I'm also suggesting that we build a 
framework which passes tags (or tag-like as you name it) from plugins to 
Geany, and Geany uses that to implement features X and Y. If the TMTag 
structure is currently insufficient then, well, just extend it as needed.


This is flexible and elegant, and allows to develop new feature (inside 
Geany or non-ft-plugins) without changing all the ft-plugins as well.


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

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

[Thomas Martitz]

Am 30.08.2016 um 03:56 schrieb Lex Trotman:

On 29 August 2016 at 22:38, Thomas Martitz <ku...@rockbox.org> 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.

Well, 3 out of 6 but whos counting :)



I count "Go To Declaration/Definition" as a tag issue. Where a symbol is 
stored,

and whether it's a definition or declaration, is contained in tags.

I did not count the build/run support, diagnostics and refactoring 
because there was no specific propsal given.



Certainly 1) showing symbols in the symbol list, 2) autocomplete and
3) calltips are currently available to a degree in Geany.  But
highlighting, build commands and build result handling are not.




But
to be able to do 2) and 3) accurately needs more knowledge of each
language semantics than is currently available in Geany or tagmanager.


That's right. But it doesn't mean the features should be *entirely* 
moved into plugin space. TM should be improved to be able to hold 
sufficient information, and plugins should help by providing that data. 
But *just* the data, don't offload very specific use cases onto them, 
this will make us less flexible in the long run. If Geany has the data, 
we can implement new features inside Geany or non-ft-plugins. Otherwise 
we would have to modify every single ft-plugin for new features and 
exclude non-ft-plugins.






I 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).

Encoding the knowledge of language semantics into Geany, for each
language supported, is going to make autocomplete and calltip code
look like c.c. Its not the way to go.


Nobody suggested to encode specific language semantics into Geany. I'm 
suggesting TM should become more generic, i.e. TMTag should transport as 
much information as required (even if some of it can't be provided by 
ctags but only some plugins).





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.

Well, again you are encoding language semantics into Geany, for
example for C++ that means autocompletion and calltips need to handle
1) local symbol scopes, 2) member functions being in the scope of the
class, even when they are not 3) argument dependent lookup 4) template
expansion lookup and 5) handling of template parameter based typing.
These are hard, just ask the GCC and clang guys.  And every user of
Geany will have to pay the cost of the code they don't use, unless
they use C++.

Then for a multidispatch language like Julia you need to handle
overloading in an even more subtle way than C++ overloading.

And why re-implement these language specific subtle and difficult
features in Geany when more and more languages are providing libclang
like libraries to do it for us, accurately and up to date with the
language.



Most of the issues don't apply to just C++ but so many other languages 
as well (e.g. Java). All of them can be improved more easily, not just 
C++, if Geany can offer a powerful framework for that. But the framework 
Matthew proposed is not powerful to me. It just evades the current 
problems simply by moving Geany's deficiencies to the plugin space.


Best regards
___
Devel mailing list
Devel@lists

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

[Thomas Martitz]

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


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 personally very happy that Matthew decided to go the way he 
proposed instead of doing what you propose. As I said in one of the 
posts here


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

it's not a matter of how "advanced" the tags are but that the tags are 
represented in a completely different way - tree vs list. There's info 
in the tree that cannot be stored in the list and similarly ctags list 
cannot be converted to AST. You can start doing some crazy things like 
serializing AST to a list and then deserializing it to a tree or 
having parallel AST-TM and list-TM but things are complicated enough 
in TM already and merging ASTs during source file updates would be 
really complicated. Also performance would suffer because operations 
on GPtrArrays are really fast as they don't require pointer 
dereferencing. In addition I think each library will have its own 
partially incompatible AST representation and different info will be 
needed e.g. for autocompletion and it will be really hard to find 
something generic enough.


1) trees can be stored in flat list simply by storing the tree path in 
each element (like GtkTreeModel). This is not crazy or complex. It's 
even readily available in the scope string.
2) I don't see why the AST needs to be recoverable from a TM tag list. 
You only need to map from X to TM, so losing information is OK as long 
as it's sufficient for the function of current features/use cases (for 
future features TM tag list may or may not needed to be enhanced).


Please show me how the proposed tag-related features require advanced 
tag management that isn't possible with TM if tags would be supplemented 
or completely provided by a plugin.




What might be good though is filling the "simple" TMTags with 
"advanced" libclang or any other tags into the existing TM. Some info 
will be lost on the way but this info will be sufficient for some 
things like the symbol tree or your plugin.



Right, this is basically what I'm looking at. I can't see how we need 
anything more at this point. And yes, I do care that Geany itself and 
plugins (including mine) have a unified interface to access all tags, 
regardless of who provides them. Matthews proposal prohibits this.


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.


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?


Best regards.


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

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

[Thomas Martitz]

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


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.


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

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

[Thomas Martitz]

Am 29.08.2016 um 05:14 schrieb Matthew Brush:

Hi All,

Related to my previous mail, and assuming it is somewhat reasonable, I 
would like to propose a list of initial features that will be useful 
to allow plugins to provide, in no particular order: 


I disagree with this approach. 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.


I thought we agreed that plugin should simply provide tags to Geany/TM 
and then Geany uses them for various purposes as it sees fit (possibly 
depending on user preferences), even if it means to extend TM in a few 
places.


Sorry, I will not support the approach you are suggesting, until it's 
clear to me that it's not doable otherwise. Instead, we should inspect 
each use case and locate exact requirements for "tag passing".


PS: highlighting and tags are generally separated topics. With custom 
filetypes we can have highlighting even if we don't have a parser. I'd 
rather not mix highlighting in this TM-related topics. Though I could 
imagine we could make it work with some magic tags that provide keywords 
to be highlighted, or just simply make use of dynamic lexers.


Best regards.
___
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

[Thomas Martitz]

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


Am 26.08.2016 um 09:13 schrieb Lex Trotman:

Not sure I agree that Github is bad for *development* discussions, for
users, sure, the ML is likely to find the audience better, but most
developers will also be githubians. Also github supports markup that
mail doesn't.  But anyway lets try mailing it in for this issue, and
see how it goes.

But everybody, please DO NOT EDIT THE SUBJECT LINE IF ON THREAD some
mail agents thread by subject, and DO NOT REPLY IF YOU WANT ANOTHER
THREAD some mail agents thread by previous ID.  We should not dictate
what sort of mail agent people must use to contribute, please respect
individual or enforced choices and follow this procedure (codebrainz
this should go on the issue guidelines).

I agree with the approach in general, but for some major items (about
the process):


rather than endless discussions we let the code do a lot of the talking

No, not yet, we need to agree what we are going to code.  This is a
major change to Geany's design, and it should be designed, not just
jump into coding it.  Geany suffers from too much "heres some code I
made earlier".

codebrainz, you clearly have some design in mind, please *describe*
(not code) it to get the ball rolling.



I'm not even sure what the thread is about. Is it replacing ctags 
through plugins or filetype specific plugins? The latter is much more 
than just tags.


For the former, I can only say that we must avoid trying to take 
shortcut by adding APIs like "allow a plugin to add its own tags to the 
sidebar" or "add words to the autocompletion dialog". This is use-case 
specific, and is going to be troublesome if multiple, competing plugins 
are at play (not necessarily targeting the same language).


tl;dr: We want interfaces where plugins can provide tags/symbols to 
Geany, so that Geany can use those to build the 
sidebar/autocompletion/etc. as it sees fit. Giving the option to 
override the sidebar will just result in every plugin doing it 
differently (and some of them incorrectly), and as a result yield a poor 
user interface.


Full story:
What we really want is methods that allow plugins to provide the *data* 
that Geany uses for sidebar/autocomplete/whatever. That means, plugins 
should be able to add to the tags storage (tagmanager or otherwise). 
Then Geany can use these tags, merge multiple tag sources (=plugins) 
together and show a consistent user interface.


This is somewhat similar to the proxy plugin. By adding an interface to 
make Geany learn about the proxied plugins, we avoid stuff like "allow a 
plugin to override the PM dialog" which would just result in plugins 
breaking the conistnetn user interface. Instead, we achieved a mechanism 
where Geany can show plugins that it can't load itself in the same UI as 
traditional plugins, making this thing just work seemlessly.


This should be the design goal when it comes to plugin wanting their own 
tag management. Geany must be in the loop so that it can multiplex 
between competing plugins and its own functionality, and still present 
the whole thing in a consistent manner to the user.



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

[Geany-Devel] [ANN] Peasy released

[Thomas Martitz]

Hello,

more than two years after my initial message "RFC: Proxy plugins" I've 
finally
reached the point that I envisioned back then. As a result, I can now 
release

Peasy, which is my first personal proxy plugin, which I'm taking seriously.

Please give me feedback or even contribute to this project.

Peasy[1] is a proxy plugin which uses libpeas[2] to enable running 
plugins in

other languages, most notably python [4]. Peasy also makes heavy use of
gobject-introspection to automatically create bindings to Geany's (and 
Peasy's

own) APIs.

Short recap, what are proxy plugins: proxy plugins are ones which act as a
proxy to "second tier" plugins. The proxy use a specific Geany API to 
register
themselves as a proxy and they provide methods to bridge Geany's core 
and the

other plugins. The other plugins then become first class plugins.

Of course the point is, that those other plugins are not written in 
C/C++ but
some other language. And the proxy plugin contains an interpreter or 
some other

runtime to execute those foreign language plugins.

Back to Peasy, it provides methods to run Python plugins within Geany. 
It also

ships a VAPI files for writing plugins in Vala.

I release version 0.2. I'm sure there hide plenty of bugs but it seems
relatively stable to me. The build process has some rough edge, though.

I support Peasy on my github, feel free to file bugs or send patches/PRs.


Q: What's the difference to GeanyPy
A: Peasy and GeanyPy have a lot in common, most prominently that they enable
   Python plugins. But key differences are:
   1) Peasy supports python3 only, GeanyPy only python2.
   3) Peasy works gtk and gtk3, GeanyPy only gtk2.
   3) Peasy automatically generates bindings for Python using 
object-introspection

  whereas GeanyPy contains hard-coded
   4) Peasy reads plugin metadata from a different file no code runs 
before the

  plugin is truly activated.
   5) Peasy isn't part for geany-plugins yet.

Peasy ships some plugins, some of which are not just for testing/playground:
- modeline-py: Parses vim modeline and applies them to Geany on a 
per-file basis.

- console-python.py: This plugins opens a console window in which you can
  explore the Geany APIs and run arbitrary python code. Heavily based on
  console.py for GeanyPy.
- quickswitch.py: Adds a dialog that allows to quckly switch tabs. Also 
supports

  going to tags / symbols directly.

[1] https://github.com/kugel-/peasy
[2] https://wiki.gnome.org/Projects/Libpeas
[3] lua functionality is completely untested so not really supported at 
this point


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

Re: [Geany-Devel] Integrate ESLint into Geany

[Thomas Martitz]

Am 11.08.2016 um 00:34 schrieb Colomban Wendling:

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


What about Vala?

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



Vala is fine. Peasy itself is written in Vala (at least partly). Peasy 
generates a .vapi for Geany's APIs and one for peasy's own APIs (there 
are very few of them at the moment). If you don't need peasy's APIs you 
can write the plugin such that it doesn't require peasy.


Other language options with peasy are whatever libpeas supports. This 
comprises python and lua at the moment. js was dropped by libpeas at 
some point. I haven't tested lua yet with peasy though.


I'd like to add ruby in the future but I don't know if I can manage.




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

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



Peasy is quite stable at this point and runs against Geany 1.28 without 
patches by now. I'm in the process of polishing the shipped plugins 
before I declare it stable.


Best regards.
___
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

[Thomas Martitz]

Am 24. März 2016 16:21:00 MEZ, schrieb "Jiří Techet" :
>>
>>
>>> That's it then. If you run Windows in VM on a "retina" Mac where
>each
>> original pixel consists of 4 smaller pixels then 100% is just
>unusable
>> because everything is too small. I can imagine 4k screen with 100% is
>> usable on a 27' monitor but it isn't on a 15' monitor.
>>
>
>Correction, MBP has a 5k screen (2880x1800) so it's even worse.
>
>Jiri
>
>
>
>
>___
>Devel mailing list
>Devel@lists.geany.org
>https://lists.geany.org/cgi-bin/mailman/listinfo/devel

4k is is 3840x2160 or higher. 5k is even more. 2880x1800 is something else ___
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

[Thomas Martitz]

Am 23.03.2016 um 15:21 schrieb Jiří Techet:


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


I think I had this happen when one of the post-install scripts (of glib 
iirc) wasn't run when creating the gtk bundle. Some gsetttings-related 
stuff is missing.


Best regards.
___
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)

[Thomas Martitz]

Am 07.01.2016 um 23:00 schrieb Jiří Techet:



On Wed, Jan 6, 2016 at 9:23 PM, Thomas Martitz <ku...@rockbox.org 
<mailto:ku...@rockbox.org>> 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.


I agree with Matthew here - I think the "damage" caused by parsing C 
headers with the C++ parser/lexer is much smaller than vice versa. 
Actually a few months back a user of my ProjectOrganizer plugin wrote 
me just because of that - he had a C++ project with "h" headers and 
was surprised that tag generation didn't work for him.


I created (a highly sophisticated) pull request here:

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

Power users can always add *.h back to C types but I think having it 
in C++ is a better default.




Yes you're only changing the default. I just stated my opionion and 
won't try to block the change. Go a head if you prefer.

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

Re: [Geany-Devel] Zombified pull requests

[Thomas Martitz]

Am 06.01.2016 um 12:39 schrieb 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.



Github itself is fine, it's just its code review solution is seriously 
lacking. I also didn't mean to question git, or the use of it. I'm 
saying there are lots of better alternatives in the code review space, 
however I'm not sure if any of them integrates well with github if you 
still use it for hosting, issue tracking and pull requests (assuming 
pull requests via github would still be accepted).


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

Re: [Geany-Devel] Zombified pull requests

[Thomas Martitz]

Am 06.01.2016 um 12:47 schrieb Lex Trotman:

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.


Please just add a comment, its actually clearer anyway since we don't
have a well defined semantics for the labels :)



The advantage of labels is that you see them on the PR overview. Whereas 
with comments you have to open every single PR and look for strings that 
may indicate a review result. While labels can be named arbitrarily, in 
the end there's going to be a handful common ones which can be looked 
out for (I disagree that free-form comments are clearer than labels for 
indicating actual results).


So comments don't scale, whereas labels could be a real help when 
looking through the list of open PRs for potentially ready PRs.






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.

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.


You don't use git head even now with supposedly-perfect merges, so you 
are not lost if it would become a bit less stable :-)


There are lots of other people which are brave enough, and that's more 
than the 2 people that test each PR (the reviewer and the author). So 
it's a still a win.


Of course there should be a minimum level of stability that should be kept.




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

If there is not enough effort to keep up with the commits, there is
even less effort available to make pull requests on top of other
peoples.



It's awkward to use because it's not visible on the original PR. It's often
hard enough to monitor one PR, let alone recursively monitoring PRs in other
repos. Also if there are more than 2 people involved at least some of them
don't see the PR-ontop-of-PR. Lastly, if you actually merge those PRs you
get a weird history with "Merged Pull Request #XX" from different repos (of
course XX changes widely).

I think gists linked to from the original PR would be more natural.

Don't know a good solution to this one, maybe if you want to actually
make changes, just mail the patches to the OP and let them put them up
on the PR.


5. This one applies to many of your PRs Jiří 

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

[Thomas Martitz]

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.


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

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

[Thomas Martitz]

Am 21.11.2015 um 14:42 schrieb Frank Lanitz:

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
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)
4) Moving all plugins into a subfolder like plugins/ to
clean up / of g-p a little
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).

Timeschedule: 1-4 until Xmas 2015, 5-6 until March.




Perhaps we should rethink what g-p is, or what we want it to be.

IIRC it was born simply as a collection of random plugins with two major 
purposes/requirements:

- unified build system including shared translation(s)
- combined release, thus shared release cycle

And nothing more than that. I don't think it was ever planed to 
establish some kind of minimum code quality or frequent maintainer 
actions. It was simply meant to provide a convinient service to plugin 
authors.


In the light of the above, I do think that current g-p is doing well and 
doesn't need to change (perhaps apart from cleaning multiple plugins 
doing the same thing). Plugins shouldn't be removed without good reason 
(i.e. if they're broken).


However, if we now start to add requirements to the above, then yeah, 
some actions like the ones Frank mention should be taken (perhaps 
removing dormant plugins). Keep in mind though, that that may mean 
*additional* burdens for maintainers, now and potential future ones, 
which I think is against the initial purpose of g-p.


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

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

[Thomas Martitz]

Am 04.11.2015 um 23:55 schrieb Colomban Wendling:

On 04/11/2015 22:21, Enrico Tröger wrote:

On 04/11/15 14:19, Colomban Wendling wrote:

Re the build failures: yeah, since a few days we can't seem to
fetch the GTK3 bundle… it's not a biggie in practice as if all of
Linux+GTK2, Linux+GTK3 and Windows+GTK2 work it should be fine and
not require testing Windows+GTK3, but it's annoying.  I'll see what
we can do here.

Maybe it's worth to host the GTK bundle archives ourselves. I think
the network traffic won't be a problem. But to do this we still need
the original ZIP archive to e available first to download it to the
server.

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

Maybe someone else of us has it?  Thomas maybe?



I started working on a script that creates the bundle including all 
dependencies from an MSYS2 installation (there, pacman has all the 
dependency infos).


Before that script I sent Enrico a few bundles (created manually). Here' 
the last one (gtk 3.16.4), but I can't remember if it has all 
dependencies or not.


https://oc.tmartitz.de/index.php/s/x27UAHQ0T5f4Qik/download

I didn't finish the script, but I guess I should finish it off. Do we 
need it before 1.26?


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

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

[Thomas Martitz]

Am 01.11.2015 um 18:50 schrieb Colomban Wendling:

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

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

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

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


Yea, I have no use for 2). And it would require many more changes inside 
Geany than the plain "two (or more) editor notebooks". Just think about 
what happens to document->editor->sci pointer when there are two scis 
(this pointer is also heavily used by plugins).


But my approach was to implement the plain splitwindow via multiple 
editor notebooks inside Geany, and then modify the splitwindow plugin to 
just offer the cloned view of one document, so there's no regression for 
that use case. I hope that pleases you.


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

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

[Thomas Martitz]

Am 31. Oktober 2015 11:39:21 MEZ, schrieb Abel :

I understand. I'm trying to solve the inconsistency of being editing a
document on split window but having the status bar showing something
else
(Should I open a issue to report this bug?). So, yes, you can take this
as
a request for the API :)

I haven't ever doxygened anything. But would it be enough for getting
added
it to the API just adding doxygen comments to it? I want to test that
the
function is suitable for the purpose I want it for, before sending a PR
for
getting it into the API.

Saludos,



Are you working on the existing splitwindow plugin or are you creating a 
new one?


I'm slowly working on a in-core solution, you can find it at
https://github.com/kugel-/geany/tree/splitwindow2?files=1

PS: Please do not top post.

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

[Thomas Martitz]

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.


You can disable that feature. What's your problem?



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.


The various preferences are exactly for that, to make up for such edge 
cases.


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. */



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.




The feature was targeted at 1.25 already. The feature itself hasn't 
changed (you didn't do anything to optimize it either). We simply 
created a UI to inform about it. It wasn't rushed either. The PR was 
open for more than two weeks and was ignored.


Best regards.
___
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?

[Thomas Martitz]

Am 24.10.2015 um 02:30 schrieb Matthew Brush:


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


doc->id is unique these days, via an ever-incrementing document counter. 
What you are refering to is stored in doc->index.


Best regards

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

Re: [Geany-Devel] Geany Portable

[Thomas Martitz]

Am 20.08.2015 um 01:25 schrieb Matthew Brush:

On 15-08-19 04:20 PM, Oliver Krystal wrote:

Yes, I'm subscribed.  Well, I use to be the developer but the facts
should still hold true.  PortableApps.com doesn't modify the source
code, but uses a wrapper around the program to achieve portable-ness.

If PortableApps needs a change to achieve portableness, it should be
submitted to the maintainers of the original program for inclusion in
the upstream(?) source.



We do have some special code about binary relocation for this I 
believe, it was added before my time, but I think it might've broken 
in the last release (1.25).


My current question though is, do you know it handles the case for the 
GUI/Glade file that it loads on startup? If I understand correctly, we 
hard-code the path to it at compile time, yet I'm able to freely move 
the GeanyPortable folder around and it still loads fine.


Any info/tips would be appreciated.



Windows builds used to be binary relocatable by default since you can 
chose the destination in the installer. With geany.glade that might be 
broken.


The binary relocation support reported by configure applies to unix 
builds only.


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

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

[Thomas Martitz]

Am 09.07.2015 um 18:00 schrieb Steven Blatnick:

Responses below:

On 07/08/2015 11:23 PM, Thomas Martitz wrote:
Remember that plugin_set_key_group() can be called repeatedly. 
Calling it again will simply clear all existing keybindings, then you 
can start over again with keybindings_set_item().


So it looks like this can be achieved with current Geany.


Thanks!  I'll take a look.
Not sure I completely understood this, but this sounds very much like 
not a keybinding issue.


The expected behavior is that ctrl+tab and ctrl+shift+tab switch the 
notebook page of whatever notebook their are in (the inner-most 
notebook in case of nested ones - this is sometimes inconvinient).


So if the sidebar is focussed, then ctrl+tab will switch pages in the 
sidebar.


But I don't fully understand what's the problem with this here. Where 
is this field you want to focus, is it not part of the youor sidebar 
panel?
The components are within the notebook, but I want to change the 
default component that is in focus when the tab is selected.  For 
example, in external-tools, I was setting the read-only textarea as 
focused, so you can highlight the output with the cursor via the 
keyboard without having to tab into that component first.


So how you propagate the focus is entirely up to you as you control the 
panel, I don't see why you need to mess with the keybindings.


Did you try gtk_container_set_focus_child() on notebook child?

Best regards


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

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

[Thomas Martitz]

Am 09.07.2015 um 04:28 schrieb Steve:

On Jul 8, 2015 7:18 PM, Matthew Brush mbr...@codebrainz.ca wrote:

On 2015-07-08 10:57 AM, Steven Blatnick wrote:

So I've finally got a chance to look at my non-API calls.  I was able to
code around most of them, but there are two that would be much easier if
we could make them APIs.  (I haven't pushed any of these changes to my
git repo yet.)  Could we consider making these API?

* keybindings_load_keyfile - I dynamically add/remove a variable
  number of plugin keybindings based on the plugin settings, so this
  allows me to refresh the results easily.  This allows my
  external-tools plugin to have any number of tools with each their
  own keybinding.  Otherwise, most plugins have a set number of bindings.

This sounds dubious.

I assume you're talking about `external-tools` plugin? Maybe I don't
understand the code enough, but it looks to me like it's just leaking
GeanyKeyGroups in `reload_tools()` and then calling
`keybindings_load_keyfile()` happens to reload the key group it newly
created?

I completely agree there needs to be a way to dynamically add/remove
keybindings, but I'm not sure we should promote this way if I understand
it correctly. IMO, it would be much better to fix Geany.

I agree.  Maybe a reload_plugin type function?  I saw a similar problem in 
gedit plugins, where you have to restart the editor for some things to take 
effect.  And you're right, if i remember correctly, I just want to be able to 
reload my own shortcuts, and the existing call does them all, which is overkill 
to say the least.



Remember that plugin_set_key_group() can be called repeatedly. Calling 
it again will simply clear all existing keybindings, then you can start 
over again with keybindings_set_item().


So it looks like this can be achieved with current Geany.



* keybindings_lookup_item - I know keybindings_get_item is available
  already, but I am attempting to look up a core group keybinding and
  not plugin's own keybindings.

This sounds reasonable, though I think it would be better if made public
to rename it to something like `keybindings_get_builtin_item()` or
something. Also I think we should change the signature to use the
correct types (those enums we already expose).

Alternatively, is there an event i can tie in to?  Basically the issue here is 
in focusing on the side panel or bottom panel, the focus lands in the wrong 
place to then capture ctrl+pg_up/down to switch notebook tabs.  For example, 
when focusing my panel in external-tools, I need the focus to update to the 
read-only text field instead of the notebook tab label.  I know I can use tab, 
but I'm trying to make the usage fluid.


Not sure I completely understood this, but this sounds very much like 
not a keybinding issue.


The expected behavior is that ctrl+tab and ctrl+shift+tab switch the 
notebook page of whatever notebook their are in (the inner-most notebook 
in case of nested ones - this is sometimes inconvinient).


So if the sidebar is focussed, then ctrl+tab will switch pages in the 
sidebar.


But I don't fully understand what's the problem with this here. Where is 
this field you want to focus, is it not part of the youor sidebar panel?






* keybindings_dialog_show_prefs_scroll - I remember someone saying the
  Configure Plugins window would have a button to this already in a
  later version, but I still don't see it.  I only need this API if
  the button isn't added.


Could probably make such a button/link use the same code as the
Keybindings button in the Plugin Manager dialog, since it does just
that. It might be a bit awkward UI-wise though.

I'm not sure why that would be awkward?  I'm away from the code right now, but 
I think this call is the same as that button, it just needs to be made an API.


I agree this button would make some sense in the configuration dialog.


Let me know if this is possible or how I should proceed.  I use geany
with my plugins daily, and can't upgrade my code base until my plugins
are working.


Best is to make a PR with the changes you want. Second best is to raise
an Issue and hope somebody else wants them enough to do it.

Ok, thanks!  I'll see what I can do based on the feedback.

Steve




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

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

[Thomas Martitz]

 Weitergeleitete Nachricht 
Betreff: Re: Github loses comments
Datum: Tue, 07 Jul 2015 00:29:38 -0700
Von: Ivan Žužak supp...@github.com
An: Thomas Martitz ku...@rockbox.org

Hi Thomas,

Thanks for sharing those details about your workflow.

If you create a comment on a commit which is a part of a pull request, 
and later on blow away that commit from the pull request with a rebase + 
force-push combo -- then that commit is no longer a part of the pull 
request so the comments are no longer shown inline on the pull request page.


However, if you create comments on the pull request's diff itself -- 
then those comments are tied to the pull request. After you update a 
pull request (even with a rebase), those comments will still be around 
on the pull request page, but will be shown as user commented on an 
outdated diff a day ago.


So, my suggestion would be to comment on the pull request's diff if 
you're using a rebase-based workflow. We understand that commenting on 
specific commits is helpful in some situations, and we're looking into 
ways to keep comments around on pull request pages even after you rebase 
away the commits they were created on. I can't make any promises about 
this, but it is on our radar.


Let me know if I misunderstood anything, if you have any questions or if 
you want to share more details so that I can pass the feedback to the team.


Cheers,
Ivan


Hello,

when a pull request is updated though a history rewrite (e.g. rebase, amend, 
commits reodered) to make the history accepatable for the main repository, then 
github sometimes loses comments associated with the pull request. This is 
annoying as it really makes reviewing *more* difficult. But only ever adding 
fixup commits is not acceptable either as it would add unwanted commits in the 
main repository (for example, if they break the build of a project it makes 
bisecting harder than necessary, therefore some commits are not acceptable for 
merging into the master branch).

Can this be fixed? I do notice that github some other times shows comments through 
X commented on an outdated diff. This seems a lot better than deleting 
valuable comments altogether.

Best regards



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

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

[Thomas Martitz]

Hello,

first of all, I think github should fix this problem, instead of 
enforcing a suboptimal workflow on us.

I reported this problem to github, let's see if they respond.

Am 07.07.2015 um 02:13 schrieb Matthew Brush:

Hi All,

As anyone trying to follow Pull Requests on Github has probably 
noticed, when you force push to your PR branch, Github deletes various 
comments related to the PR, depending on what got clobbered (it seems).


Not always. I haven't found a consistent pattern, but it seems worse 
when commits are removed.




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


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


Well, assuming an updated PR only changes stuff which has  been 
commented on before or are otherwise explicitely noted in a new comment, 
you do not have to review the entire diff again. And you have to review 
those parts of the diff you commented on again, other parts should be 
fine since they received no comment at the first review, right?


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



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


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




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



Thoughts, opinions?


I prefer rebasing and rewriting commits, because that makes my life 
easier too. I can handle my stuff better if it has a clean history, and 
it helps me in making design decisions because I try to logically 
separate stuff in the commits. And merging master into my PR when the PR 
should eventually be merged into master is not acceptable for, therefore 
I rebase.


Continuously rewriting history is common in the patch distribution via 
mailing lists so it's successfully performed elsewhere. It's really just 
github being bad at maintaining comments and that should be fixed on 
their side.


PS: Lost comments should still be in your mailbox as a last resort, 
since github sends notifications for each.


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

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

[Thomas Martitz]

Am 01.07.2015 um 21:33 schrieb Enrico Tröger:

On 27/06/15 20:53, Thomas Martitz wrote:

Am 27.06.2015 um 01:09 schrieb Enrico Tröger:

Hi,

I've built new Windows installers from current GIT master.


Downloads can be found here:
http://download.geany.org/snapshots/


Please note that these are test builds from the current development
version, don't expect release quality.
You have been warned :).

After you installed the snapshots, you can also use the nightly
builds again on Windows (i.e. copy the archive contents over the
installation).


Any feedback is welcome.



Nice! I'll try to spin GTK3-based installers soon. Though it needs tiny
patches to Geany (PR will follow).

Thomas, could you do me a favor and check against which libraries your
geany.dll is linked?
Basically performing a 'ldd' on Windows.




I use EXE Explorer[1] to inspect imports. Actually, I vaguely remember 
problems with libwinpthread-1.dll during the linkage cleanup effort (I 
did stumble upon it). But I don't remember the outcome. I do know I 
didn't use msys2 back then but mingw32. Nevertheless neither geany.exe 
nor libgeany-0.dll built by msys2 import this library (it exists in the 
msys2 file system though) so this binaries don't suffer.


Perhaps a bug in the toolchain.

The gcc version is 4.9.2, binutils is 2.25.

Best regards

[1] http://www.mitec.cz/exe.html
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

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

[Thomas Martitz]

Am 29.06.2015 um 00:32 schrieb Lex Trotman:

On 29 June 2015 at 07:41, Colomban Wendling lists@herbesfolles.org wrote:

Le 26/06/2015 07:22, Thomas Martitz a écrit :

[…]

However, as we entered string freeze, I don't suppose a new dialog like
this is acceptable at this point?

It would be really better not to indeed?


What else can we do for *this* release?

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

- Default to not keep history (hence prompt);

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

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

Or just put a BIG notice in the release notes Reload is now undoable
so it doesn't prompt any more




That helps only existing users, and only that fraction that actually 
reads release notes (I would think the bulk of them doesn't).


Perhaps it would be indeed best to not toggle the default for this 
release already?


PS: I do love this feature now that I'm aware of the undo'ability, it's 
not like I want to act against it. I just fear it creates user confusion 
for both new and existing users alike.


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

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

[Thomas Martitz]

Am 28.06.2015 um 12:36 schrieb Enrico Tröger:

On 27/06/15 20:53, Thomas Martitz wrote:

Am 27.06.2015 um 01:09 schrieb Enrico Tröger:

Hi,

I've built new Windows installers from current GIT master.


Downloads can be found here:
http://download.geany.org/snapshots/


Please note that these are test builds from the current development
version, don't expect release quality.
You have been warned :).

After you installed the snapshots, you can also use the nightly
builds again on Windows (i.e. copy the archive contents over the
installation).


Any feedback is welcome.



Nice! I'll try to spin GTK3-based installers soon. Though it needs tiny
patches to Geany (PR will follow).

Nice too!



Not sure I'll bother anymore. To me it doesn't look like there is any 
interest in a GTK3-based windows version seeing how immediately my bug 
fixes got post-poned. I also feel uneasy with myself releasing a 
GTK3-1.25 which is actually a 1.25+ because it has patches applied 
(because my bug fixes aren't accepted in time, and plain git master 
isn't up to it)


Best regards.


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

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

[Thomas Martitz]

Am 26.06.2015 um 07:22 schrieb Thomas Martitz:

Hello,

I hacked up a document message to inform the user about this new 
behavior, see attached screenshot.


However, as we entered string freeze, I don't suppose a new dialog 
like this is acceptable at this point? What else can we do for *this* 
release?


Bump. IMO this should be resolved for 1.25. Should I do a PR regardless 
of the string freeze?


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

Re: [Geany-Devel] Spawn module API

[Thomas Martitz]

Am 28.06.2015 um 05:14 schrieb Matthew Brush:

On 2015-06-27 07:54 PM, Lex Trotman wrote:

On 28 June 2015 at 12:40, Matthew Brush mbr...@codebrainz.ca wrote:

On 2015-06-27 12:46 PM, Dimitar Zhekov wrote:


[...]

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

meWIF*
lexspawn_get_program_name
lexspawn_check_command
me/lexspawn_kill_process
  spawn_async_with_pipes
lexspawn_async
me/lexspawn_with_callbacks
mespawn_write_data
lex?spawn_get_exit_status_cb
lexspawn_sync



We should only export what you have concrete plans to use during the 
next
cycle. If Lex wants update plugins during the next cycle to use 
other parts
of the API, we can expose them at the time that the PR is made. No 
point to

speculatively expose API that nobody has immediate plans to use.


If no API is available then nobody will have any plans so no API is
needed so nobody will have any plans for the egg so no chicken is
needed so 



It can easily be made available on-demand, as normal.

We should only be concerned about what Scope is requesting as it has 
concrete plans to use them during the next development cycle and 
doesn't want the plugin to depend on the next development version of 
Geany during that time[0]. There's no reason to speculatively rush 
other APIs in if no plugins have immediate plans to use them nor have 
the concern about depending on the development version of Geany.




Depending on a development version of Geany can be a concern.

I don't want to judge on the specific spawn_* APIs. But why not just 
release with the APIs being available (linkable by plugins) without 
already setting them officially in stone. In other words, find a method 
to mark these APIs experimental so that we can more easily change or 
remove them. This experimental flag should be set for at least one 
release cycle (but perhaps more depending on the situation). Then only 
plugin developers that are prepared to adapt their plugins quickly can 
use them (likely the same plugin developers who pushed the API into 
Geany for their plugins in the first place). Arguably, this should be 
the default process for any new API (IMO).


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

Re: [Geany-Devel] [Geany-devel] Geany-Plugins: Windows test build for 1.22 available

[Thomas Martitz]

Am 28.06.2015 um 21:30 schrieb Thomas Martitz:

Am 28.06.2015 um 20:39 schrieb Colomban Wendling:

Le 03/07/2012 20:15, Enrico Tröger a écrit :

[…]

If someone have more information about available builds (and a related
-dev package) I might have a look though I doubt we'll manage that for
the 1.22 release which is, AFAIK, due on upcoming Sunday.

As I heard msys2 has builds for everything, maybe it has WebKitGtk too?
  Just a passing thought :)



It has:

mingw/*mingw-w64-webkitgtk2* 2.4.8-2
GTK+ Web content engine library (mingw-w64) for GTK2

mingw/*mingw-w64-webkitgtk3* 2.4.8-2
GTK+ Web content engine library (mingw-w64)

(all mingw-w64-* prefixed packages are built for i686 (32bit) and 
x86_64 (64bit))


I think that's a yes?


Oh, and the script I add in [1] can be used to gather all other 
dependency packages for  destribution.However webkitgtk in this case 
would ship with geany-plugins and not geany core.


[1] 
https://github.com/kugel-/geany/commit/d66f63660e1bf40f7f34e963a2182b0d41f4ca14


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

Re: [Geany-Devel] [Geany-devel] Geany-Plugins: Windows test build for 1.22 available

[Thomas Martitz]

Am 28.06.2015 um 20:39 schrieb Colomban Wendling:

Le 03/07/2012 20:15, Enrico Tröger a écrit :

[…]

If someone have more information about available builds (and a related
-dev package) I might have a look though I doubt we'll manage that for
the 1.22 release which is, AFAIK, due on upcoming Sunday.

As I heard msys2 has builds for everything, maybe it has WebKitGtk too?
  Just a passing thought :)



It has:

mingw/*mingw-w64-webkitgtk2* 2.4.8-2
GTK+ Web content engine library (mingw-w64) for GTK2

mingw/*mingw-w64-webkitgtk3* 2.4.8-2
GTK+ Web content engine library (mingw-w64)

(all mingw-w64-* prefixed packages are built for i686 (32bit) and x86_64 
(64bit))


I think that's a yes?

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

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

[Thomas Martitz]

Am 27.06.2015 um 01:09 schrieb Enrico Tröger:

Hi,

I've built new Windows installers from current GIT master.


Downloads can be found here:
http://download.geany.org/snapshots/


Please note that these are test builds from the current development
version, don't expect release quality.
You have been warned :).

After you installed the snapshots, you can also use the nightly
builds again on Windows (i.e. copy the archive contents over the
installation).


Any feedback is welcome.




Nice! I'll try to spin GTK3-based installers soon. Though it needs tiny 
patches to Geany (PR will follow).


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

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

[Thomas Martitz]

Hello,

I hacked up a document message to inform the user about this new 
behavior, see attached screenshot.


However, as we entered string freeze, I don't suppose a new dialog like 
this is acceptable at this point? What else can we do for *this* release?


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

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

[Thomas Martitz]

Am 24.06.2015 um 22:26 schrieb Lex Trotman:
I'm struggling to understand why there is any confusion, reload is an 
editing action just like any other and can be undone like any other. 
Seems much safer to me and exactly what to expect. It used to have a 
side effect that was unexpected and nasty which was why it had a 
dialog warning of that, now it doesn't, so its just like any other 
command. 


To me, reloading the file from disk is clearly not like any other 
editing command. It's got more to do with file management than editing, 
and given the previous behavior it's easy to be confused as an existing 
user. I also don't think any other editor out there works like this so I 
can see it being unexpected for new users as well.



I haven't looked at the code. Is the diff of the buffer and the file applied
and recorded as an ordinary undo action?

Thats up to Scintilla how it records the reload.


I was wondering if we do anything special to support this. I guess not.

Indeed long time users who are used to the old wrong behaviour need to 
unlearn the wrong one. But that doesn't mean we should prompt every 
time we do it right.



Some kind of help/guidance for users who do not expect the new behavior 
(either because are existing users or coming from other editors[1]) 
would be nice, if possible. And since it seems really unique across 
editors (and consequently potentially unexpected) some kind of 
introduction to the feature would be really helpful. I, for one, got 
really trapped. I'd say the dialog I proposed can accomplish that, while 
maintaining the ability to never have the prompt again.


[1]: gedit does it similarly to what we previously did.

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

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

[Thomas Martitz]

Hello

I have just noticed that current git, by default, doesn't prompt anymore 
when reloading documents, even when they are changed.


I traced it back to the $SUBJECT commit. IMO it's fine to keep the undo 
history on reload and not prompt, but it's not fine if the file is 
currently modified (unsaved) and reloading throws all unsaved changes 
away, without warning.


This is especially problematic because the new pref is on by default so 
users will probably be surprised by the new, changed behavior and lose 
some hours of work (happend to me...).


I'm asking for restoring the prompt (by default), at the very least if 
the file is unsaved.


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

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

[Thomas Martitz]

Am 24.06.2015 um 18:30 schrieb Colomban Wendling:

Le 24/06/2015 17:04, Thomas Martitz a écrit :

Hello

I have just noticed that current git, by default, doesn't prompt anymore
when reloading documents, even when they are changed.

I traced it back to the $SUBJECT commit. IMO it's fine to keep the undo
history on reload and not prompt, but it's not fine if the file is
currently modified (unsaved) and reloading throws all unsaved changes
away, without warning.

This is especially problematic because the new pref is on by default so
users will probably be surprised by the new, changed behavior and lose
some hours of work (happend to me...).

How does it loose work?  you can undo the reload and you get your stuff
back, don't you?


Ah yes, that seems to work. I didn't even think of that (not sure why, 
but redo would seem more natural to me here). Anyway the new default 
behavior seems awkward to, surprising and unexpected in some way.


I haven't looked at the code. Is the diff of the buffer and the file 
applied and recorded as an ordinary undo action?



I'm asking for restoring the prompt (by default), at the very least if
the file is unsaved.

Would be fine with me, as I don't think reload is something done so
often that a confirmation would be much pain.  We could restore the
previous confirmation behavior.

offending commit is
https://github.com/geany/geany/commit/660c441b4af272fe4e40eb6a6cda2badb8f17eac
I guess.



Okay, with the undo the reload it's not as bad as I thought. However I 
still find the new default behavior confusing, especially for regular 
long time users like me.


However, just restoring the prompt is also not ideal. Since the undo 
history is now remembered the prompt would be wrong (either way, for 
unsaved buffer it says Any unsaved changes will be lost. and for saved 
buffer Undo history will be lost.).


I think one could improve the prompt depending on the pref. I think it 
would best to even incooperate a check box for the pref (like [ ] 
Remember undo history and [ ] don't ask again [the latter being 
insensitive if the first is unchecked]). How does that sound?


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

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

[Thomas Martitz]

Am 14.06.2015 um 13:59 schrieb Enrico Tröger:

On 07/06/15 22:31, Thomas Martitz wrote:

Am 7. Juni 2015 17:53:36 MESZ, schrieb Yury Siamashka yura...@gmail.com:

05/29/15 12:00, Thomas Martitz пишет:

Hello,

I've successfully managed to build Geany on MSYS2, against both gtk2
and gtk3. I've started to describe the steps on the wiki:
https://wiki.geany.org/howtos/win32/msys2, however the page is not
complete yet (but complete enough to produce a running geany).

Actually I noticed that they even have Geany PKGBUILD in their
MSYS2-packages repository (https://github.com/Alexpux/MSYS2-packages).
I
was able to build and install it in without problems. This makes
setting
environment for working on plugins  in windows very easy.

Best regards,
Yury Siamashka
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Hey, this is cool. Now we only need to figure out how to create an installer.

Basically it is quite easy with the existing geany.nsi and the NSIS
package (Nullsoft Installer).

It only requires a Geany installation and a stripped down GTK tunetime
environment to be packed into the installer.
What this is, is documented at
http://wiki.geany.org/howtos/win32/build#create_a_stripped_down_gtk_runtime_environment.
Maybe we can adopt this to the self-compiled GTK environment.

I could work on this but would delay this a bit until past the 1.25
release. Simply to not break things before a release.

Regards,
Enrico


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


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


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

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

[Thomas Martitz]

Am 14.06.2015 um 14:48 schrieb Enrico Tröger:

On 14/06/15 14:21, Thomas Martitz wrote:

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

Oops, scratch the self-compiled. But we still need to create a
distributable GTK runtime environment. This is probably doable from the
installed GTK package, I guess.


Regards,
Enrico


I'm experimenting at this moment. The gtk/glib/etc package files can be 
found under /var/cache/pacman/pkg/$pkg-$ver.tar.xz. They can be 
extracted with tar to a working directory. But what to do afterwards? 
The wiki says to move the files under $geanydir/gtk, but how is the 
installer file created? The nsis gui is giving me an error:


Error in macro MUI_PAGEDECLARATION_LICENSE on macroline 17
Error in macro MUI_PAGE_LICENSE on macroline 6
Error in script C:\msys64\home\kugel\geany.git\geany.nsi on line 87

(geany.nsi:87 reads !insertmacro MUI_PAGE_LICENSE 
${RESOURCEDIR}\Copying.txt)


The wiki mentions release.py which I cannot find in geany git.

Best regards

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

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

[Thomas Martitz]

Am 14.06.2015 um 16:48 schrieb Enrico Tröger:

At some point we had some discussion whether to use the same directory
on Windows as on Unix but I don't know the result.


We do this already don't we (except for the renamed text files)?




need to install to a special directory?

The current process (waf install + release.py + makensis) expects the
installation directory as a subdirectory of the source tree, e.g.
c:\git\geany\geany-1.25
where c:\git\geany is the source tree.

But with a bit of adjusting path, any other directory should be possible
as well. Right now, release.py and geany.nsi just use relative paths. If
those are made absolute, it should work as well, I guess.



Good to know :) The wiki doesn't mention this. The waf configure line on 
the wiki has no prefix at all


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

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

[Thomas Martitz]

Am 14.06.2015 um 18:26 schrieb Enrico Tröger:


This is why :).
I thought a couple of times of making geany.nsi.in and
geany_private.rc.in and fill in the version number automatically. But I
never was annoyed enough to fiddle with the 4-part version numbers used
there. Maybe you are :).


The last digit is always isn't it?




- the installer geany lacks some icons

Which? Why?

Most icons are missing actually, such as open, save on the toolbar.

This is probably because Geany is compiled by autotools with the Unix
like path layout but the installer creates our custom Windows layout and
so Geany simply looks at the wrong location.


Actually the issue goes away if I remove the installer-included GTK 
runtime, so that the one in PATH is used. I guess I didn't add enough 
files (icons?) to the installer





With Waf it is actually geany-0.dll.
But except for the installer, it should not make any difference, right?
I don't mind which one we will use. In the end, I hope we will only have
one build system, i.e. no more Waf, and so the name doesn't matter, I guess.
Oh, while writing, I think of the linker. Does the msys2 linker handle
libgeany.dll properly when using '-lgeany' as specific in the pkgconfig
file? It works at least with the Mingw linker and Waf.





libgeany-0.dll works just fine.

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

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

[Thomas Martitz]

Am 14.06.2015 um 16:35 schrieb Enrico Tröger:

On 14/06/15 15:50, Thomas Martitz wrote:

Am 14.06.2015 um 14:48 schrieb Enrico Tröger:

On 14/06/15 14:21, Thomas Martitz wrote:

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

Oops, scratch the self-compiled. But we still need to create a
distributable GTK runtime environment. This is probably doable from the
installed GTK package, I guess.


Regards,
Enrico

I'm experimenting at this moment. The gtk/glib/etc package files can be
found under /var/cache/pacman/pkg/$pkg-$ver.tar.xz. They can be
extracted with tar to a working directory. But what to do afterwards?
The wiki says to move the files under $geanydir/gtk, but how is the
installer file created? The nsis gui is giving me an error:

Now that you have the release.py (see below), you can easily see it is just:

makensis /V2 /DINCLUDE_GTK geany.nsi


Thanks




Error in macro MUI_PAGEDECLARATION_LICENSE on macroline 17
Error in macro MUI_PAGE_LICENSE on macroline 6
Error in script C:\msys64\home\kugel\geany.git\geany.nsi on line 87

(geany.nsi:87 reads !insertmacro MUI_PAGE_LICENSE
${RESOURCEDIR}\Copying.txt)

the Copying.txt is expected to be copied when installing Geany.
'waf install' does this.
We cannot use a plain 'make install' on Windows as it is done on Linux,
the Geany wscript has some logic, yes and magic, to do things different
on Windows (like renaming AUTHORS, COPYING, README and so on to *.txt).


Using msys2 we can use the autotools build system on windows. Therefore 
make install works just fine, installs to the dir given by ./configure 
--prefix=XXX.


I guess since I use autotools Copying.txt isn't created (?). Also, do I 
need to install to a special directory?


Best regards.

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

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

[Thomas Martitz]

Am 14.06.2015 um 18:32 schrieb Thomas Martitz:


Actually the issue goes away if I remove the installer-included GTK 
runtime, so that the one in PATH is used. I guess I didn't add enough 
files (icons?) to the installer






Indeed, I could fix the lacking icons and the warning spam by including 
the adwaita icon theme into th installer.


A terminal window still opens when I launch geany and GTK prints some 
warnings, but only at startup.


Best regards


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

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

[Thomas Martitz]

Am 14.06.2015 um 23:20 schrieb Enrico Tröger:

On 14/06/15 19:08, Thomas Martitz wrote:

Am 14.06.2015 um 18:32 schrieb Thomas Martitz:

Actually the issue goes away if I remove the installer-included GTK
runtime, so that the one in PATH is used. I guess I didn't add enough
files (icons?) to the installer




Indeed, I could fix the lacking icons and the warning spam by including
the adwaita icon theme into th installer.

Ok, this must be a new GTK3 requirement then I guess.
GTK2 worked without any additional icon themes.


Were icons compiled into the library? The icons must be somewhere.

Remember that I didn't take the bundle form gtk.org, i simply extracted 
the pacman package files downloaded by msys2, and I just forgot to 
extract the adwaita icons (IIRRC adwaita is the default gtk theme 
everywhere now)





A terminal window still opens when I launch geany and GTK prints some
warnings, but only at startup.

Still no idea :(.
It is a usual black command line window from Windows?




Yes, as if you started geany with -v.

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

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

[Thomas Martitz]

Am 14.06.2015 um 17:44 schrieb Enrico Tröger:

On 14/06/15 17:16, Thomas Martitz wrote:

Am 14.06.2015 um 16:55 schrieb Thomas Martitz:

Am 14.06.2015 um 16:48 schrieb Enrico Tröger:

At some point we had some discussion whether to use the same directory
on Windows as on Unix but I don't know the result.

We do this already don't we (except for the renamed text files)?


need to install to a special directory?

The current process (waf install + release.py + makensis) expects the
installation directory as a subdirectory of the source tree, e.g.
c:\git\geany\geany-1.25
where c:\git\geany is the source tree.

But with a bit of adjusting path, any other directory should be possible
as well. Right now, release.py and geany.nsi just use relative paths. If
those are made absolute, it should work as well, I guess.


Good to know :) The wiki doesn't mention this. The waf configure line
on the wiki has no prefix at all


Okay, I managed to create an installer for a Geany GTK3 build. \o/

Woohoo!
Great.



Some additional observerations:

[...]


- the installer wrongly reports that it ships GTK 2.24

Did you update geany.nsi?


Nope




- the installer geany lacks some icons

Which? Why?


Most icons are missing actually, such as open, save on the toolbar.





- the installer geany runs slow because gtk/glib spam a console window

During installation or when running Geany after installation?
Did you start Geany with -v from the CLI?



When running, I launched it via the Windows explorer (double click 
geany.exe). This and the lacking icons don't happen when running the 
make install'd geany.


BTW: Another observation I missed to mention: On autotools our .dll is 
libgeany.dll not geany.dll


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

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

[Thomas Martitz]

Am 7. Juni 2015 17:53:36 MESZ, schrieb Yury Siamashka yura...@gmail.com:
05/29/15 12:00, Thomas Martitz пишет:
 Hello,

 I've successfully managed to build Geany on MSYS2, against both gtk2 
 and gtk3. I've started to describe the steps on the wiki: 
 https://wiki.geany.org/howtos/win32/msys2, however the page is not 
 complete yet (but complete enough to produce a running geany).

Actually I noticed that they even have Geany PKGBUILD in their 
MSYS2-packages repository (https://github.com/Alexpux/MSYS2-packages).
I 
was able to build and install it in without problems. This makes
setting 
environment for working on plugins  in windows very easy.

Best regards,
Yury Siamashka
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Hey, this is cool. Now we only need to figure out how to create an installer.

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

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

[Thomas Martitz]

Am 30.05.2015 um 03:19 schrieb Matthew Brush:


Just because it's such a trivial search algorithm, using strstr() is 
much more simple and probably more efficient than using Scintilla's 
API to find text, but if manual and automatic mode is supported, it 
would make sense to share the existing code, and that beats out 
advantage having a redundant (yet simpler/faster) routine to do same, 
IMO. +1 (if it's not too much hassle to refactor Mark All).




What makes you think naive strstr() based search is faster/more 
efficient than whatever Scintilla does?


I haven't looked actually, but I'd think it does the same (probably 
using C++ strings), or something smarter like KMP mentioned in this 
thread or whatever the C++ template library provides. But I don't think 
it does anything slower than the most trivial strstr() method.


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

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

[Thomas Martitz]

Am 27.05.2015 um 14:25 schrieb marius buzea:

Hello,

I would like to add GeanyHighlightSelectedWords, to Geany Plugins.
Would it be okay that I do a git pull-request for doing this?   I
am the mgnt user on sourceforge, and last week there was a ticket
added to GeanyHighlightSelectedWords, ticket #2, and in this
ticket was a question:  why not make a pull-request to Geany Plugins.

I know there would be some things I would need to do before, like
replace the Makefile with Makefile.am, the autotools, automake way,
and write a README file using restructured text content so that that
README file can be converted to html.  Maybe there is more that
should be done.

I hope my question is okay.

Have a great day,
Marius Ioan Buzea



What does this plugin do exactly? Addons can already mark all instances 
of the selected word (same as ctrl+shift+m if a word already selected).

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

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

[Thomas Martitz]

Am 25. April 2015 05:22:38 MESZ, schrieb Colomban Wendling 
lists@herbesfolles.org:
So yeah, if anyone wishing to keep on using this plugin should consider
helping maintaining it, it really needs some love from time to time.


Libpeas includes lua support as of v1.14. So if my whole proxy plug-in work 
would be accepted (in some way or another) I can maintain lua support through 
my Libpeas based peasy plug-in. That would even have access to Geany APIs 
unlike current geanylua. 

Best regards 


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

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

[Thomas Martitz]

Am 19.04.2015 um 15:57 schrieb Enrico Tröger:

This said, the reason we need the hack is because of
https://bugzilla.gnome.org/show_bug.cgi?id=712220, so if this was fixed
we could one day drop the hack.  But this would mean depend on a fixed
version, which probably won't be acceptable before a decade or so :)

So we'll have to fix the Windows build issue in some way…
I gave it another look, however I sort of give up :(.

What I know is, with gcc 3.4 the popups work cleanly and as expected,
even when compiled natively on Windows. This is why the nightly builds
work, they are built with an old gcc 3.4.



What gives sizeof(GtkScrolledWindow) with the old gcc vs new gcc? Did 
you try -mms-bitfields or -mno-ms-bitfields with the old one, does that 
make a difference?


Thanks for your effort!


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

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

[Thomas Martitz]

Am 16.04.2015 um 23:20 schrieb Colomban Wendling:

Is a pref necessary?

Yes.


In that case it's not the best solution and we should find an indication that 
people don't want to outright disable.

The underline gets the job done but I'm not married to it. Can you suggest a 
better alternative?



And at least
with my splitwindow2 patch set something like this is needed to
determine the focused document (each notebook can have an active doc,
but only one of them can be focused at any time).

Only if the splitwindow is actually used.  And even, underlying the tab
might not be the best visual indicator ever, though I can't suggest
something easy that would actually work (I'd think a better one would be
some kind of slightly deactivated editor, but while doable it's a bit
annoying with Scintilla).


And it might be barely visible depending on the color scheme. Because of 
that I think no indication that involves the scintilla widget alone will 
work for everybody.


Anyway we can discuss this specifically for splitwindow2. Let's not 
further hijack this thread, I just wanted to throw in that a visual 
indication other than what GTK does by itself might become necessary anyway.


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

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

[Thomas Martitz]

Am 16.04.2015 um 21:47 schrieb Enrico Tröger:

On 16/04/15 18:47, Dimitar Zhekov wrote:

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

Am 15.04.2015 um 19:15 schrieb Dimitar Zhekov:

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

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

Would that be a worthy fix to your problem?

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

I sort of like the idea. And would agree that it might be not just
useful on Windows.
Thomas, can this be done in code so it could be enabled/disabled by a
setting?


Sure, but why would you disable it? Is a pref necessary? And at least 
with my splitwindow2 patch set something like this is needed to 
determine the focused document (each notebook can have an active doc, 
but only one of them can be focused at any time).


PS: In case it's not clear, splitwindow2 refers to my patch set that 
enables splitting the editor into two widgets so that 2 docs are visible 
at the same time. In contrast to the plugin it does this so that both 
widget work the same way, so support styling, keybindings and other 
things properly.


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

Re: [Geany-Devel] New plugin loader mechanisms

[Thomas Martitz]

Am 29.03.2015 um 18:19 schrieb Colomban Wendling:
So anyway, I think I'd be in favor of a failable init(), maybe like 
gboolean (*init) (..., GError **error); if we want to be able to 
report messages and the like. Or just let each plugin do the same 
msgwing_add() or whatever, but a common integrated thing might be 
worth it.


Okay, I can add the return value now. But can we agree on ignoring the 
return value for now and work out what Geany should do best in a 
separate thread/changeset. I just don't like to mix this UI/UX change 
(which is an effort on its own because Geany obviously does not handle 
failing init() at all) with the new loader.


But with GError sounds a bit overkill to me, isn't gboolean or gint 
return code sufficient?


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

Re: [Geany-Devel] New plugin loader mechanisms

[Thomas Martitz]

Am 30.03.2015 um 23:07 schrieb Thomas Martitz:

Am 30.03.2015 um 14:57 schrieb Colomban Wendling:


If `pdata` is provided in geany_plugin_register(), how does it get
released?  If it has to be a pointer to static data it's a bit limiting,
and forces use of (static) globals, which is one thing that this new API
tries to avoid, doesn't it?  We could also ask for a GDestroyNotify, but
that's an additional arg we might not need.

And also, providing the pdata in geany_load_module() might mean memory
allocation, allocation that might never be used if the plugin isn't
activated.

OTOH, if `pdata` is a member of GeanyPlugin, it can be allocated in
init() and freed in cleanup() without having to tell Geany how it has to
free it.



I see what you mean. Indeed, this could be a problem.

I wanted the pdata parameter such that it is friendly to language 
bindings. This doesn't work if the user_data is hidden down in some 
other structs passed as parameter. For example, I wanted to make it 
possible to use vala member functions classes directly as plugin 
hooks. And this works, however there is indeed a leak. I have a 
prototype, see below.


Considering this use case I would rather take the GDestroyNotify than 
hiding down pdata in another param. Passing it to 
geany_plugin_register() also allows for using a member function for 
the init() hook already.


What do you think?




Replying to self after having thought about it a bit more.

Since I do want to maintain the ability to set the data in 
geany_load_module(), or rather just before the plugin's init() (to 
enable the use case cited below), but also at the same time still allow 
it to be also set in the plugin's init() (some plugins don't want 
expensive allocs before init()) AND definitely pass the pointer as a 
separate parameter, the only think I came up with is a separate API 
function to set the data, including the destroy notify. So I have now:


geany_plugin_register(GeanyPlugin *, gint api, gint min_api, gint abi, 
GeanyPluginHooks *); /* pdata param is removed */
geany_plugin_set_data(GeanyPlugin *, gpointer pdata, GDestroyNotify 
free_func);


geany_plugin_set_data() can be called before the plugin's init, or 
within, or any later. It'll set the data that is passed to all the hooks 
(NULL is passed if geany_plugin_set_data() was never called). The 
GDestroyNotify is called before the plugin is unloaded. Most importantly 
it is also called if geany_plugin_set_data() was called before init() 
and the plugin did not became activated at all.


I have successfully prototyped that the below Vala example can work 
without leaks using the separate API function:


-p.register(Geany.API_VERSION, 224, Geany.ABI_VERSION,
-ref hooks, new Tester() /* LEAK */);
+p.register(Geany.API_VERSION, 224, Geany.ABI_VERSION, ref hooks);
+p.set_data(new Tester() /* no leak, g_object_unref is automatically 
passed as destroy notify */);


Is that sound?

Best regards



Appendix: The prototype is like this:

using Geany;

class Tester
{
public void init(Plugin p) { }

public void help(Plugin p) { /* shows a dialog */ }

public void cleanup(Plugin p) { }
}

private PluginHooks hooks;
public bool geany_load_module(Plugin p, GLib.Module mod, int 
geany_api_ver)

{
hooks.init = Tester.init;
hooks.help = Tester.help;
hooks.cleanup = Tester.cleanup;
p.register(Geany.API_VERSION, 224, Geany.ABI_VERSION,
ref hooks, new Tester() /* LEAK */);

mod.make_resident();

/* ... */
return true;
}

___
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] New plugin loader mechanisms

[Thomas Martitz]

 the pointer to the plugin code through function arguments.


You could only pass it to init and expect plugins to store their own 
pointer, but I find that bad practice, because it needs to be done in 
all plugins, because it otherwise won't be useful (because it can't call 
many API functions). If we can make things more convenient for plugin 
developers I'm for it.




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

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


I don't understand this part. What's the implications of translated 
plugin info? I think it only needs GeanyData to be available?






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

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



But what's the problem with PluginCallback? It's a convenient and useful 
feature to allow signal connections to be statically defined. The cost 
to support is really tiny, and it's not like we deprecated this API 
aspect so I don't see removing it is justified. Removing things from the 
API still requires some considerations.







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

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


Again, it's needed for some API functions and the global pointer is 
gone. To my understanding it's the primary handle that Geany has to the 
plugin and the plugin sees as well.




Again, here I'd have expected something like my_plugin_init(self, ...),
as 1) it follows the common pass the self/this as first parameter
scheme, and it's actually the only thing that seem to matter.
Extra args are of course useful when they are needed, like GtkDialog*
for configure.


Le 28/03/2015 23:56, Thomas Martitz a écrit :

[…]
geany_load_module(), which is called by Geany via pointer obtained from
g_module_symbol(). In this function the plugin should perform the
following steps:

- Test against the passed geany_api_version if it can function under the
current Geany.
- Test for any additional runtime dependencies
- Call geany_plugin_register() appropate and test the return value

If any of the above steps fail FALSE should be returned, else TRUE.

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

I don't get why geany_load_module() should fail, IIUC it should just not
call geany_plugin_register() if it can't work, shouldn't it?


It could be done this way too, indeed. Actually I don't use the return 
value currently, because I check the loaded_ok flag set by 
geany_plugin_register() [after successfull API/ABI/PluginInfo checks]. I 
mainly added the return value as a future provision, but I can remove it 
if you like.






This proposal does not implement pluxies by itself, however I have done
the work to implement pluxies on top of the new loader. I will post
another mail about this when we finalized the new loader.

That might be where I don't get it.  As I see it, the only missing bit
from my slightly altered proposal is a geany_plugin_unregister() so a
proxy plugin can remove its sub-plugins when it gets deactivated.  Maybe
I miss something, but that seem to be the only bit that would be
required for a proxy plugin a normal plugin wouldn't need.


I hope the other reply shed some light. But let me say here that 
geany_plugin_unregister() is not necessary under the current or new 
loader, neither for standard nor proxied plugins. Deregistering is 
simply not a thing in our scheme. Once registered, the plugin will be 
considered for the PM dialog (after some checks). That doesn't mean it's 
enabled or activated, it just means the PM dialog potentially shows it. 
Deregistering doesn't need to happen, it would only mean that the PM 
dialog wouldn't show it anymore. Which is the same thing as if there is 
no pluxy available for it, i.e. the corresponding pluxy is disabled.


In my current proxy plugin work it's not possible to disable pluxies if 
there are active sub-plugins depending on it, but this is purely a 
policy decision. We can easily change to automatically disable 
sub-plugins as well (perhaps with a dialog warning the user). The point 
is, even here there is no deregister. Geany will deregister on it's own, 
and only notify the plugin via its cleanup() function.


This is not to be confused with unloading, which

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

[Thomas Martitz]

Am 30.03.2015 um 14:33 schrieb Lex Trotman:



What is is_plugin()? If its a function in Geany how does it get to
know about new types of plugins without being hard coded?

It knows because the extensions are registered by the function below
called by another plugin right?  How do you make sure that the
register function has been called before you come across a file with
that extension?



For now, I kept it simple: Geany simply restarts the scan for plugins 
loop when new extensions are added during the the scan (remember that 
during the scan, each file is loaded and its init() is called, before 
the next file is even attempted). The PM dialog is refreshed in the same 
way when a pluxy is activated by the user.


It can be made smarter, but it's good enough at the moment.

https://github.com/kugel-/geany/blob/pluxy/src/plugins.c#L878 and 
https://github.com/kugel-/geany/blob/pluxy/src/plugins.c#L1272






It's new, small helper function I added. It loops through all known file
extensions, and returns the first pluxy (a PluginProxy *) for which a) the
supported file extension matches and b) the probe hook returned true (or is
NULL, for standard plugins).
$file is not a plugin if is_plugin returns NULL, i.e. no pluxy was found.

https://github.com/kugel-/geany/blob/pluxy/src/plugins.c#L844


File extensions and the proxy hooks (probe, load, unload) are registered by
a plugin during its init() through the new plugin_register_proxy() function.

Ok, so this registers a new type of plugin by its extension(s) and
that type is associated with a plugin that provides:

- the loader functionality?
- interface wrappers/bindings (like geanypy does)?
- starts/loads any other things, like the Python interpretor or a JVM
or Haskell runtime?



Yes, but the 2nd and 3rd points are entirely up to the pluxy. My 
demopluxy.so doesn't do anything fancy. it creates a dummy plugin out of 
a GKeyFile.


But the loader/unloader function is mandatory, it also acts as the entry 
point for pluxies to start their bindings/vm machinery if necessary.






Here the pluxy added to the list of registered pluxies. This list is
initialized with the simulated pluxy that provides standard plugins (this is
not a plugin, it's contained in plugins.c, it's just to keep the code paths
equal).

https://github.com/kugel-/geany/blob/pluxy/src/plugins.c#L1601


which matches
additional file extensions (as provided by pluxies), it also calls the
probe() hook to resolve ambiguous files (e.g. .so files, they can be core
or
libpeas plugins)

I'm guessing probe() is a function that looks for something in the .so
that distinguishes if its new or old loader, but what about others?



It depends on the pluxy what the prope() function does! For my peasy pluxy
(that provides generic support for libpeas-based plugins), it looks if there
is a matching *.plugin for a given *.so, and if yes return a code so that
Geany does not attempt to process the .so itself.

https://github.com/kugel-/peasy/blob/master/src/peasy.c#L73

There is no probe() for standard plugins, it accepts all .so.

If it doesn't call probe how does it know if its a traditional plugin,
or a peas one or maybe some other version that makes a .so file?
(Haskell anybody :)


Geany doesn't and cannot know it's a peas plugin, though it could be 
smarter at determining it's a standard plugin. But I currently 
implemented a scheme where the first pluxy that matches wins, but if it 
doesn't match all other pluxes are tried. Geany itself is tried last.


This should work for all real-world cases, even when there are multiple 
(more than 2) providers for .so files. If the pluxies are accurate 
enough at determining their own filetypes then no conflicts arise.


Geany is always tried last, so if it gets to process a .so file, then it 
assumes it's a standard plugin like it's done in git master (no change 
here)




In the load hook of the pluxy. Either the pluxy calls it directly or it
decides to provide a suitable binding so that the non-C script can call it
itself, but it has to be during the execution of the load hook.

Ok, so if there are all these hooks, probably later the traditional
plugins can be just another pre-registered set of hooks built into
Geany, but I agree with your approach of not trying to do that all in
the first step, leave the existing code as little changed as possible
until the new system settles down and then change the existing code to
use it.



It's done this way already, the hooks are compiled into Geany. As I said 
the list of pluxies is initialized with a simulated one that provides 
the standard plugins { .extension = { so, NULL }, .probe = NULL, .load 
= plugin_load_so, .unload = plugin_unload_so };



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

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

[Thomas Martitz]

Hello,

some if your question are easier to answer by looking at the code, I'll 
link the appropriate sections.



Am 30.03.2015 um 13:16 schrieb Lex Trotman:

[...]

Ok, this explains some of what I was asking on the other thread, so
now I can ask the more specific questions below that are the key
points in the confusion.


with my new loader (no pluxies) it goes like this, and this is *very*
similar to git master.


user opens PM dialog

1 Geany calls load_all_plugins(), which calls load_plugins_from_path($path)
2 for each $file in $path, Geany checks if the extension is G_MODULE_SUFFIX,
and calls plugin_new($file, ...)
3 plugin_new() calls the plugins's  geany_load_module() (if new-style
plugin, calls version_check, set_info() for old-style ones)
4 geany_load_module() is implemented by the plugin, and registers itself
with geany_plugin_register()
 geany_plugin_register() adds the plugin to the plugin list, so that the PM
can sort and show it

Now, with pluxies, it is completely the same except for:
2* for each $file in $path, Geany calls is_plugin($file)

What is is_plugin()? If its a function in Geany how does it get to
know about new types of plugins without being hard coded?



It's new, small helper function I added. It loops through all known file 
extensions, and returns the first pluxy (a PluginProxy *) for which a) 
the supported file extension matches and b) the probe hook returned true 
(or is NULL, for standard plugins).

$file is not a plugin if is_plugin returns NULL, i.e. no pluxy was found.

https://github.com/kugel-/geany/blob/pluxy/src/plugins.c#L844


File extensions and the proxy hooks (probe, load, unload) are registered 
by a plugin during its init() through the new plugin_register_proxy() 
function. Here the pluxy added to the list of registered pluxies. This 
list is initialized with the simulated pluxy that provides standard 
plugins (this is not a plugin, it's contained in plugins.c, it's just to 
keep the code paths equal).


https://github.com/kugel-/geany/blob/pluxy/src/plugins.c#L1601




which matches
additional file extensions (as provided by pluxies), it also calls the
probe() hook to resolve ambiguous files (e.g. .so files, they can be core or
libpeas plugins)

I'm guessing probe() is a function that looks for something in the .so
that distinguishes if its new or old loader, but what about others?



It depends on the pluxy what the prope() function does! For my peasy 
pluxy (that provides generic support for libpeas-based plugins), it 
looks if there is a matching *.plugin for a given *.so, and if yes 
return a code so that Geany does not attempt to process the .so itself.


https://github.com/kugel-/peasy/blob/master/src/peasy.c#L73

There is no probe() for standard plugins, it accepts all .so. Whether 
it's a new or old style plugin is determined later. It *could* be in a 
probe() hook for standard plugins as well, I just didn't happen to 
implement it that way (yet), because plugin_load_so needs to distinguish 
between the two anyway.


https://github.com/kugel-/geany/blob/pluxy/src/plugins.c#L472




3* plugin_new() calls the load() hook registered by pluxies for the given
extension. for standard plugins (without proxy) there is a predefined
plugin_load_so() funtion that gets called instead.

How does the load hook get defined for new types of plugins?


Via the new API function plugin_register_proxy().
https://github.com/kugel-/geany/blob/pluxy/src/plugins.c#L1601




4* The load-hook calls geany_plugin_register(), here Geany core and proxies
work the same way

Where is the geany_plugin_register() defined for a plugin written in a
language that isn't C/C++/Vala that can produce a .so file?


In the load hook of the pluxy. Either the pluxy calls it directly or it 
decides to provide a suitable binding so that the non-C script can call 
it itself, but it has to be during the execution of the load hook.


The demopluxy does it in the load() hook, right after parsing the 
metadata of the example plugin (I completely made up a fake plugin 
format for demonstration purposes):


https://github.com/kugel-/geany/blob/pluxy/plugins/demopluxy.c#L169

I have done it the same way for peasy too, because libpeas plugins can 
be python or js, and I didn't create bindings yet. But it shows working 
this way.


https://github.com/kugel-/peasy/blob/master/src/peasy.c#L130





I designed it such, that the difference between standard plugins and proxied
plugins is all contained in the load hook. The rest of Geany does not know
about the difference. This ensures proxied plugins are first class citizens.


Thats the correct target I agree, I just don't understand the design
details yet.



Thanks for the heads up!

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

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

[Thomas Martitz]

Am 30.03.2015 um 19:18 schrieb Colomban Wendling:

Hi,

What do you think?




Is this a real problem (reported by someone) or just theoretical?

Unless there is actually a real problem caused by this for someone I'd 
vote for not doing anything. After all, somone naming his files `foo 
bar.c` should expect to shoot himself in the foot.


Seriously, sounds like a possibility for over-engineering a non-existent 
problem.


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

Re: [Geany-Devel] New plugin loader mechanisms

[Thomas Martitz]

Am 30.03.2015 um 14:57 schrieb Colomban Wendling:


If `pdata` is provided in geany_plugin_register(), how does it get
released?  If it has to be a pointer to static data it's a bit limiting,
and forces use of (static) globals, which is one thing that this new API
tries to avoid, doesn't it?  We could also ask for a GDestroyNotify, but
that's an additional arg we might not need.

And also, providing the pdata in geany_load_module() might mean memory
allocation, allocation that might never be used if the plugin isn't
activated.

OTOH, if `pdata` is a member of GeanyPlugin, it can be allocated in
init() and freed in cleanup() without having to tell Geany how it has to
free it.



I see what you mean. Indeed, this could be a problem.

I wanted the pdata parameter such that it is friendly to language 
bindings. This doesn't work if the user_data is hidden down in some 
other structs passed as parameter. For example, I wanted to make it 
possible to use vala member functions classes directly as plugin hooks. 
And this works, however there is indeed a leak. I have a prototype, see 
below.


Considering this use case I would rather take the GDestroyNotify than 
hiding down pdata in another param. Passing it to 
geany_plugin_register() also allows for using a member function for the 
init() hook already.


What do you think?


Best regards

Appendix: The prototype is like this:

using Geany;

class Tester
{
public void init(Plugin p) { }

public void help(Plugin p) { /* shows a dialog */ }

public void cleanup(Plugin p) { }
}

private PluginHooks hooks;
public bool geany_load_module(Plugin p, GLib.Module mod, int geany_api_ver)
{
hooks.init = Tester.init;
hooks.help = Tester.help;
hooks.cleanup = Tester.cleanup;
p.register(Geany.API_VERSION, 224, Geany.ABI_VERSION,
ref hooks, new Tester() /* LEAK */);

mod.make_resident();

/* ... */
return true;
}

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

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

[Thomas Martitz]

Am 29.03.2015 um 05:20 schrieb Lex Trotman:

Thomas,

Thanks for that, it now makes it clearer where you are going, and
allows the individual steps to make more sense.

I agree with your four problems (shortened):

- linkage
- keybindings
- plugin context
- allow for proxies

My concern is that the solutions seem complex, though, having followed
your attempts over time to address these issues, I do understand that
some of the simple options don't actually cut it.

Will need to think on it further.



Which of these steps seem complex to you in particular? Perhaps I can 
explain more detail on those to make things clearer for you. For me, 
none of these is really that complex, both in terms of conceptual 
complexity and lines of code changed. The most complex is probably the 
pluxy part, but still not really complex IMO (it's just a bit of 
refactoring of the internal load/unload functions functions and an API 
that allows plugins to add such functions for some filetypes). If 
anything, complexity is added by maintaining backward compatibility.


My current roadmap is such that it requires the least amount of changes 
to Geany core while still enabling libpeas-based and other non-C plugins 
to co-exist with standard plugins and not be second class citizens.


Other simple options (that provide a solution for the above, i.e. not 
current geanypy) don't exist. In fact, the other solution I have tried 
brought significant changes to Geany core to support libpeas-plugins 
directly in the core. Simple isn't always best too, we should strive to 
make all of this effort future proof but at the same time maintain 
backward compatibility.



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

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

[Thomas Martitz]

Am 29.03.2015 um 19:17 schrieb Colomban Wendling:

Le 29/03/2015 00:23, Thomas Martitz a écrit :


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

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




I'll answer this question here in the hope the other thread can 
concentrate on the new loader itself. But it also kind of depends on how 
I designed the loader so I guess there will be some cross talk.


As with git master, Geany's core loader scans the plugin folder on 
startup and on opening the PM dialog. For each recognized plugin file it 
allocates a GeanyPluginPrivate and calls geany_load_module().


So this is where we come from:
- Geany initiates the scan (on behalf of the user)
- Geany has certain files it recognizes as plugins. It won't attempt 
other files.
- Geany allocates and frees the structure that holds everything it needs 
to know, this structure is opaque for actual plugins (and we need this 
to be able to extend it)


So, to support pluxies as first class citizens, I designed it such that 
Geany becomes able to scan additional files and hand the initialization 
of plugins to the proxy (instead of calling geany_load_module()). The 
idea is that Geany still performs the actual scan and builds up the 
plugin list in the PM dialog, so it's completely synchronous. Geany 
should still allocate the GeanyPluginPrivate structure for each plugin, 
for the proxied ones too. Note that proxy plugins too call the same 
geany_plugin_register() on behalf of the proxied plugins, like standard 
plugins have to too. Geany fully supervises which plugins are loaded, 
and when, so that it can provide a unified experience for the user, 
regardless of the plugin type that's behind the scenes.


Therefore my mechanism is based on plugins letting Geany know which 
files they can support, so that Geany's loader can scan for plugin files 
like ever, except it can match more types, and calls into the proxy to 
complete loading. For unloading the proxy is also called, to complete 
plugin finalization. For this, plugins need a way to provide Geany with 
the information it needs to load the additional plugins: file 
extension(s), and load/unload callbacks (and a probe, to resolve 
ambiguous file extensions).


To give a practical example:

with my new loader (no pluxies) it goes like this, and this is *very* 
similar to git master.


 user opens PM dialog
1 Geany calls load_all_plugins(), which calls load_plugins_from_path($path)
2 for each $file in $path, Geany checks if the extension is 
G_MODULE_SUFFIX, and calls plugin_new($file, ...)
3 plugin_new() calls the plugins's  geany_load_module() (if new-style 
plugin, calls version_check, set_info() for old-style ones)
4 geany_load_module() is implemented by the plugin, and registers itself 
with geany_plugin_register()
 geany_plugin_register() adds the plugin to the plugin list, so that 
the PM can sort and show it


Now, with pluxies, it is completely the same except for:
2* for each $file in $path, Geany calls is_plugin($file) which matches 
additional file extensions (as provided by pluxies), it also calls the 
probe() hook to resolve ambiguous files (e.g. .so files, they can be 
core or libpeas plugins)
3* plugin_new() calls the load() hook registered by pluxies for the 
given extension. for standard plugins (without proxy) there is a 
predefined plugin_load_so() funtion that gets called instead.
4* The load-hook calls geany_plugin_register(), here Geany core and 
proxies work the same way


I designed it such, that the difference between standard plugins and 
proxied plugins is all contained in the load hook. The rest of Geany 
does not know about the difference. This ensures proxied plugins are 
first class citizens.



I hope you better understand my concept now. Let me emphasize again that 
it's focused having relatively little impact on Geany's core or existing 
plugins so that we can smoothly transition to a new non-C plugin world 
full of joy!


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

Re: [Geany-Devel] New plugin loader mechanisms

[Thomas Martitz]

Hello,

based on the discussion I refined my proposal (see below). Additionally 
I have implemented all of this, including updating demoplugin.c, see 
[1]. And last but not least, I have a fully working implementation of 
proxy plugins aka pluxies (in fact, I simply updated my year-old branch 
to use the new hooks) plus a real-world pluxy for libpeas-based plugins, 
see [2], [3].


I also formally suggest this work for merging. I havent done a pull 
request yet, though, because it depends on the linkage-cleanup work, 
which should be merged first. I do target the 1.25 release still, and 
I'd absolutely love to if we can make this happen.



The changes since my initial proposal summed up:
- geany_plugin_register() now additionally takes the API version the 
plugin is compiled against (in addition to the minimum API it needs and 
the ABI version). This gives Geany full insight of what the plugin can 
be expected to work with.
- set_info() is removed from the hooks. version_check() is obviously 
obsolete (the checks are performed within geany_plugin_register()). The 
plugin is expected to full plugin-info before calling 
geany_plugin_register() which makes set_info() superfluous
- The conceptual role of geany_load_module() is extended: It should also 
check for plugin-specific runtime dependencies, and return FALSE if such 
checks fail (as a result the plugin will be hidden from the PM dialog). 
Otherwise call geany_plugin_register() appropriately.
- geany_load_module() passes Geany's API version, sos that plugins can 
perform their own specific checks based on the API of the currently 
running Geany instance (this can very well be != the plugins 
GEANY_API_VERSION)
- The GeanyData pointer is now part of GeanyPlugin structure for plugins 
to access (not passed to init anymore). Actually it was this way in my 
first version too, but I didn't explicitly mention it.

- PluginHooks is renamed to GeanyPluginHooks

Now to the (updated) proposal:

Please see my initial mail [4] about the motivation and advantages of 
this work.


gboolean geany_load_module(GeanyPlugin *plugin, GModule *module, gint 
geany_api_version);
gboolean geany_plugin_register(GeanyPlugin *plugin, gint api_version, 
gint min_api_version,
   gint abi_version, GeanyPluginHooks 
*hooks, gpointer pdata);


typedef struct _GeanyPluginHooks
{
/** Array of plugin-provided signal handlers (@see PluginCallback) */
PluginCallback *callbacks;
/** Called when the plugin is enabled by the user */
void(*init)  (GeanyPlugin *plugin, gpointer pdata);
/** plugins configure dialog, optional (can be @c NULL) */
GtkWidget*  (*configure) (GeanyPlugin *plugin, GtkDialog *dialog, 
gpointer pdata);
/** Called when the plugin should show some help, optional (can be 
@c NULL) */

void(*help)  (GeanyPlugin *plugin, gpointer pdata);
/** Called when the plugin is disabled or when Geany exits */
void(*cleanup)   (GeanyPlugin *plugin, gpointer pdata);
}
GeanyPluginHooks;


Plugins from now on define a single global function, 
geany_load_module(), which is called by Geany via pointer obtained from 
g_module_symbol(). In this function the plugin should perform the 
following steps:


- Test against the passed geany_api_version if it can function under the 
current Geany.

- Test for any additional runtime dependencies
- Call geany_plugin_register() appropate and test the return value

If any of the above steps fail FALSE should be returned, else TRUE.

The plugin shall pass a statically allocated instance of 
GeanyPluginHooks as part of the geany_plugin_register() call. The 
function pointers should point to function that are semantically the 
same as the current plugin_{init,configure,help,cleanup}. Except these 
function get other parameters and can make use of them.


This proposal does not implement pluxies by itself, however I have done 
the work to implement pluxies on top of the new loader. I will post 
another mail about this when we finalized the new loader.


[1] https://github.com/kugel-/geany/tree/new_hooks
[2] https://github.com/kugel-/geany/tree/pluxy
[3] https://github.com/kugel-/peasy
[4] http://lists.geany.org/pipermail/devel/2015-March/009299.html

Please reply with your options or other ideas.

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

Re: [Geany-Devel] New plugin loader mechanisms

[Thomas Martitz]

Am 26.03.2015 um 18:47 schrieb Dimitar Zhekov:

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


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



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


From your initial proposal:

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


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


Right, I changed my mind. As I already wrote in an earlier mail in 
response to you:
I said in my proposal it should do nothing but call 
geany_register_plugin(), but I guess we can relax that by allowing also 
for testing if the plugin itself is operational. 





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


What do you do currently?


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



If the checks are in geany_load_module() the plugin couldn't even be 
activated. Which is IMO desirable.






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

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

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


I don't intend to change this.


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

Re: [Geany-Devel] New plugin loader mechanisms

[Thomas Martitz]

Am 20.03.2015 um 19:45 schrieb Dimitar Zhekov:




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


There seem like two different things to me.

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


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


They [incompatible plugins and plugins that are unable to function due 
to missing runtime deps] are different things, but the resulting action 
should be the same (hide it from the PM dialog, possibly give the user a 
hint). Hiding from the PM dialog should IMO be done before it even 
showed up, to avoid creating expectations that cannot be met and 
negative user surprise.


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



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


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


My opinion is that if the XML isn't compatible to the current GtkBuilder 
version then scope shouldn't even show up in the PM dialog, because 
there is no way it can be functional. This is not fundamentally 
different to a plugin being incompatible to Geany's ABI version. So yes, 
that implies validating the XML in geany_plugin_register() (although 
loading seems excessive to me, because the XML should be considered 
distributed with the plugin and not to be edited by the user; at some 
point you have to make some assumption to keep problems managable).


If this seems so inefficient you could try to rescue the state from 
geany_plugin_register() to init. However keep in mind that init can be 
called without prior call to geany_load_module(), if the user toggles 
plugins in the PM dialog. And that init might not be called at all, so 
plugins shouldn't be wasteful with resources in geany_load_module() if 
might never be needed.




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




What do you do currently?

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


Geany does not handle failing init() currently, and I don't want to 
change that now because I think that's out of scope for my proposal. I 
merely want to transform the current hooks into a new mechanism without 
introducing large discrepancy between the two mechaisms (because the 
current one will be still supported). I also tend to think that a 
failing init is misdesigned.


What do others think about this point?

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

Re: [Geany-Devel] New plugin loader mechanisms

[Thomas Martitz]

Am 18.03.2015 um 22:55 schrieb Matthew Brush:

On 15-03-18 09:42 AM, Thomas Martitz wrote:


tl;dr -
Key functions

gboolean geany_load_module(GeanyPlugin *, GModule *)


What is the GModule* for? Is it a .dll that Geany opened on behalf of 
the plugin based on selection in Plugin Manager?


That's the function exported by native (C/C++) plugins that want to 
register as plugins with Geany. With my proposal that's the only 
function of a plugin that Geany gets through g_module_open(). Since this 
only applies to native shared libraries, the corresponding GModule is 
passed.


This function is similar to libpeas' peas_register_types().




gboolean geany_plugin_register(GeanyPlugin *, gint api, gint abi,
PluginHooks *(see below), gpointer)

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

1) Provide the plugin handle to the plugin very early
2) Perform abi and abi checks, so this is finally done inside geany.
Added bonus is that geany knows the requested api and can possibly apply
backcompat workarounds on a per plugin basis (instead of globally), warn
about very old plugins or even deny loading them.
3) Register the remaining hooks and callbacks (see below)
4) Associate a userdata pointer to the plugin, geany will pass this
pointer back to future calls into the plugin (good for proxies)

In the future geany_plugin_register should be able to be used to
register plugins recursivly, by passing the appropriate GeanyPlugin
pointer, i.e. plugin A should be able to call
geany_plugin_register(plugin_B, ...) to realize pluxies.

Now to the plugin hooks:
typedef struct _PluginHooks
{
 PluginCallback *callbacks;
 void(*set_info)  (GeanyPlugin *plugin, gpointer pdata);
 void(*init)  (GeanyPlugin *plugin, gpointer pdata);
 GtkWidget*  (*configure) (GeanyPlugin *plugin, GtkDialog *dialog,
gpointer pdata);
 void(*help)  (GeanyPlugin *plugin, gpointer pdata);
 void(*cleanup)   (GeanyPlugin *plugin, gpointer pdata);
}
PluginHooks;



What if instead of PluginHooks it was called `Plugin` (GeanyPlugin is 
taken, so for this discussion I'll use `Plugin` :) and instead of just 
the callback function pointers it contained the (possibly 
sub-)plugin's info, like this:


Plugin is also taken inside Geany :)




```
typedef struct
{
  const char *name;
  const char *version;
  const char *author;
  const char *description;
  unsignedapi_min;
  unsignedabi_ver;
  void   *plugin_data; // pdata/plugin context

  bool  (*init) (Plugin*);
  GtkWidget (*configure) (Plugin,GtkDialog*);
  gchar*(*help) (Plugin*); // if not NULL ret, show URL in browser
  bool  (*deinit) (Plugin*); // could signal unloading problem
}
Plugin;
```

Then the register function could be like:

```
bool plugin_register (GeanyPlugin *module, // geany's plugin context
  Plugin  *plugin); // real/sub-plugin ctx
```

Inside a normal plugin it could do:

```
static Plugin my_plugin = {
  .name= Foo,
  .version = 0.1,
  .author  = Me,
  .description = Foo plugin,
  .api_min = 200,
  .abi_ver = GEANY_ABI_VERSION,
  .init= my_plugin_init,
  .configure   = my_plugin_configure,
  .help= my_plugin_help,
  .deinit  = my_plugin_cleanup,
};

G_MODULE_EXPORT
bool plugin_load_module (GeanyPlugin *module_plugin)
{
  return plugin_register (module_plugin, my_plugin);
}
```

Or for a proxying-type plugin (ex. GeanyPy/GeanyLua):

```
G_MODULE_EXPORT
bool plugin_load_module (GeanyPlugin *module_plugin)
{
  Plugin *plug = g_new0 (Plugin, 1);
  *plug = my_plugin;
  plug-name = Joe's plugin;
  plug-version = etc...
  plug-plugin_data = PyObject_New(...); // or lua_new() or whatever
  return plugin_register (module_plugin, plug);
}
```

Just some ideas based on yours and mine previous work around this. 
There's many ways to skin this cat :)


That's only a slightly different version of my proposal, it's 
fundamentally the same. Glad you like it :D


Thanks for your suggestion to make the plugin_set_info() obsolete and 
move filing the info fields before geany_plugin_register(). I will 
incoperate that into my v2 of my proposal.


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

Re: [Geany-Devel] New plugin loader mechanisms

[Thomas Martitz]

Am 19.03.2015 um 23:34 schrieb Lex Trotman:

On 19 March 2015 at 09:16, Thomas Martitz ku...@rockbox.org wrote:
There is no other way of loading C shared libraries and registering them as
plugins.

Doesn't Geany already load dlls local and extract the symbols it wants
via dlsym()?

dlsym() takes an argument of the loaded dll handle, so it can't access
the wrong library.



Yes, there is no problem in this if accesses go through dlsym with the 
appropriate library handle. Global namespace collisions can occur of 
symbols exported by multiple shared libraries are accessed the normal 
way, either by geany or plugins. This happens in the current loader, as 
plugins access their geany_plugin pointer (but does not happen under my 
new loader). As we use RTLD_LOCAL so we have no problems here either, 
however it is still nice to have to minimize the amount of globals 
exported by the plugin.





API/ABI just a typo :)  Note that allowing the plugin to make this
decision means it has to have a way of overriding the default = test
you have moved into geany.



I can't follow this.



But indeed, the API version could be passed to geany_load_module() to allow
for the above. Passing the abi version is pretty useless as the plugin will
only load with one specific abi anyway so it can't adapt.



Also it would be good to consider the semantics of API and ABI since
there are some conditions where we cannot express a change in the
interface except for the hammer of an ABI break.


We should be able with the new loader mechanism, since we learn about the
plugin's minimum API version. Now we can not only deny based on the ABI
version but also based on the minimum API (we could possibly deny loading
plugins which are written against too old API version).

The decision of too old needs to be made by the plugin, Geany
doesn't know what the plugin uses, that a plugin declares I can run
with any API newer than 123 doesn't mean it actually uses 123.  It is
just being friendly and saying I can run with older Geany's as well.




The plugin may know it better, that's why I follow your suggestion and 
pass Geany's API version to geany_load_module.


I was saying that we could deny loading plugins that report 123 as their 
minimum if we made an incompatible API break in 130 like removing a 
function all together. While it's true that 123 doesn't mean it uses 
that very function, Geany could be conservative and deny loading. (I 
know this was a bad example because we bump the ABI for removed 
functions, and plugins that use the removed function would not recompile 
successfully, but you get the idea).


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

Re: [Geany-Devel] New plugin loader mechanisms

[Thomas Martitz]

Am 19.03.2015 um 01:19 schrieb Matthew Brush:

On 15-03-18 03:55 PM, Thomas Martitz wrote:

Am 18.03.2015 um 23:21 schrieb Matthew Brush:

On 15-03-18 03:05 PM, Thomas Martitz wrote:

Am 18.03.2015 um 22:15 schrieb Matthew Brush:



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


Please make this gboolean. A plugin may have the correct API and 
ABI,

but be unable to startup / initialize for some reason. For example,
Scope requires scope.glade in the plugin data directory).


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

incompatible plugins. This has the benefit that they will be attempted
to be loaded on the next startup if the user had previously 
selected it.


For resource files like say a GtkBuilder UI file, I'd agree, but there
may be some other cases, for example if a plugin dynamically loaded
some particular library (or variant of a library) based on user
configuration, it'd be useful to report to the user that the library
is wrong, or no longer available, or whatever.



Based on user configuration implies that it's a decision that is made
after the plugin's init(). If it allows the user to configure it without
this dependency then the plugin is considered operational, and init()
should not fail. Remember that a init() == FALSE would imply that the
plugin cannot be activated, and therefore not configured (i.e. you
cannot configure back so that it doesn't need the missing dependency).

Such custom requirements  errors are better placed in the plugin code
itself.




I'm thinking if the plugin loaded successfully, then it should be
operational too. Meaning that init() should not fail, but simply
activate the plugin. As outlined above, my proposal already covers the
case compatible but not operational due to missing runtime
dependencies you described.



For cases like GeanyPy which loads arbitrary Python scripts (which are
even fully executed on import), and in a language where Exceptions are
common (especially during development), it would probably be useful to
signal that the plugin script couldn't be loaded and maybe even be
able to provide a formatted traceback of the Python exception or such.


In my roadmap geanypy does not load scripts in its init(), but through a
separate API (so that the scripts integrate into the main plugin
manager). Anyway, geanypy init() isn't the right place because geanypy
can load multiple scripts, and which scripts can change afterwards after
init has run. And finally, all those scripts do not change the fact that
geanypy itself is operational, and this is what we're talking about.




I think I misunderstood the purpose of your `init()` function. I 
thought it was a hook to allow the plugin manager/geany to be able to 
initialize multiple plugins from the same .dll/module (ex. 
sub-plugins, etc). If that's not the case, isn't the `init()` pointer 
in the struct basically redundant as plugins could do their 
initialization in the roughly equivalent `geany_load_module()` that is 
also called once per .dll?



I haven't changed the semantics of init function (it is the same 
plugin_init() that already exists), and there is no support for pluxies 
or sub-plugins yet. My new loader doesn't do that, it only changes how 
the plugin is registered and the parameters plugins receive in the hooks.


The difference between the geany_load_module() and init() is that the 
former is always called, even if the plugin is not enabled by the user. 
And it can fail (e.g. if the ABI check fails) which prints warnings and 
hides it from the PM GUI.


geany_load_module() doesn't have an equivalent, therefore plugins with 
runtime hard-dependencies could previously only fail in init somehow (as 
a hack). Now geany_load_module() can do that. I think init() is 
generally not the right place for that. When it is called then the 
plugin was enabled by the user, i.e. it is expected to function somehow 
from here on. Proper plugins will allocate resources and hook into the 
GUI in this function that are not needed when the plugin is disabled. At 
last, I do not want to change the semantics of the existing hooks if 
possible because that makes merging my patch harder.




For that matter, why not just leave the hooks all as loose functions 
(as opposed to set into a structure), and just fix the prototypes to 
pass around GeanyPlugin* and/or user_data, or whatever improvements? 
AFAIK there's no issue with symbols/collisions if Geany just uses 
RTLD_LOCAL when dlopen-ing the plugin module.


Well it was determined that we want new functions instead of adding or 
changing the parameters of the existing hooks. And I think it is 
desirable to minimize the amount of globals in the plugin while at it. 
Besides, the new geany_load_module() provides some true benefits, such 
as ABI/API verification in the core instead of in the plugin.


Best regards

[Geany-Devel] New plugin loader mechanisms

[Thomas Martitz]

Hello,

tl;dr - scroll down

I am working on a new plugin architecture that deals with some of the 
shortcomings of the current state. My primary motivation is to be able 
to use libpeas to load plugins, both C and non-C (Python!), as you might 
have learned from other threads I started. However the situation can be 
improved regardless of that goal.


List of current shortcomings:
 - (A separate change but nevertheless: ) Currently geany exports a 
pointer to a struct, that contains more structs, which contain function 
points to the API functions. Fortunately this is nicely hidden to 
developers via macros. But due to gtkbuilder all functions and nothing 
prevents plugins from accessing these. And the macros are awkward and 
strange anyway. There is currently the linkage-cleanup PR in the works 
which improves this by actually exporting the API functions, and _only_ 
the API functions to plugins.
 - Global symbols. Plugins binaries have to export a number of global 
symbols (geany_{functions,data,plugin}, plugin_{init,...,cleanup}). This 
kind of sucks, because they pollute the global namespace (in theory). 
Luckily on unix or win32 systems this is not a problem because they can 
restrict the symbol visibility of shared libraries. It's still bad 
practice. Ideally plugins should have zero global symbols, everything 
being static or hidden to the plugin binary.
 - The plugin entry points / callbacks are inconsistent w.r.t to the 
parameters they receive, and none receive some kind of a plugin handle 
referencing to the plugin itself (there is only the geany_plugin global).
 - The plugin entry points / callbacks do not allow for the plugin 
associate private/user data with the plugin handle, except hand-maintain 
hash tables. This is not a problem for the most part because it can be 
stored in some plugin-wide static variable, however it does become 
problematic when you attempt to have one plugin act as a proxy for other 
plugins (see geanypy or my pluxy effort)
 - The plugin does the ABI/API verification. We currently trust the 
plugins to use PLUGIN_VERSION_CHECK() or otherwise implement 
plugin_version_check() correctly. Plugins decide whether they are 
api/abi compatible with geany. Pure crazyness!
 - Plugins cannot register plugins recursively. It would be awesome if 
a plugin could register a plugin on behalf of others, in such a manner 
that they appear in the PM dialog and can be handled by the user like 
normal plugins (*proper* proxy plugins are not possible).



To improve the situation I propose the following mechaism and new plugin 
hooks:


tl;dr -
Key functions

gboolean geany_load_module(GeanyPlugin *, GModule *)
gboolean geany_plugin_register(GeanyPlugin *, gint api, gint abi, 
PluginHooks *(see below), gpointer)


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

1) Provide the plugin handle to the plugin very early
2) Perform abi and abi checks, so this is finally done inside geany. 
Added bonus is that geany knows the requested api and can possibly apply 
backcompat workarounds on a per plugin basis (instead of globally), warn 
about very old plugins or even deny loading them.

3) Register the remaining hooks and callbacks (see below)
4) Associate a userdata pointer to the plugin, geany will pass this 
pointer back to future calls into the plugin (good for proxies)


In the future geany_plugin_register should be able to be used to 
register plugins recursivly, by passing the appropriate GeanyPlugin 
pointer, i.e. plugin A should be able to call 
geany_plugin_register(plugin_B, ...) to realize pluxies.


Now to the plugin hooks:
typedef struct _PluginHooks
{
PluginCallback *callbacks;
void(*set_info)  (GeanyPlugin *plugin, gpointer pdata);
void(*init)  (GeanyPlugin *plugin, gpointer pdata);
GtkWidget*  (*configure) (GeanyPlugin *plugin, GtkDialog *dialog, 
gpointer pdata);

void(*help)  (GeanyPlugin *plugin, gpointer pdata);
void(*cleanup)   (GeanyPlugin *plugin, gpointer pdata);
}
PluginHooks;

These are analogous and semantically equivalent to the current 
functions. The only difference is the parameters that are passed to 
them, and of course how they are registed. Additionally the existing 
PluginCallbacks pointer registered here for all plugins that want 
statically defined signal handlers.


There is no version_check() hook because that's now done inside geany, 
and the long deprecated configure_single is phased out. Please also note 
that each hook receives the GeanyPlugin pointer and the userdata 
pointer, these are the same passed to geany_plugin_register.


With this new mechanism, proxy plugins are more than doable. geanypy 
should benifit as well.


I have implemented this so far and adapted the 

Re: [Geany-Devel] New plugin loader mechanisms

[Thomas Martitz]

Am 18.03.2015 um 21:23 schrieb Dimitar Zhekov:

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


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


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


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




That's okay. I didn't mean to forbid global symbols. I put it poorly, 
what I meant was that the current loader requires plugins to export lots 
of global symbols. If plugins do it on their own it's their business.



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


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





Hmm, noted. However I didn't want to digress too far from the existing 
functions (semantically). And Geany obviously cannot handle failing init 
yet. But in this should be trivial to add.


Do you generally like or support my proposal?

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

Re: [Geany-Devel] New plugin loader mechanisms

[Thomas Martitz]

Am 18.03.2015 um 18:11 schrieb Steven Blatnick:
I personally hope whatever the group decides to do with the plugins 
doesn't involve requiring a rewrite of all of them, because we'll 
surely lose plugins and supporters that way.




Geany developers are committed to maintain compatibility for existing 
plugins to new Geany versions, and we go through great length to make 
that possible. Most of the time at worst plugins need to be recompiled. 
That said, there may be times were a severe break is necessary but we 
really do our best to avoid that.


Following that, my plans are on-top of the current loader. While it 
would kind of deprecated the current loader, plugins written against it 
(all current plugins) will keep working without changes or recompiling. 
This is purely for new plugins or those that voluntarily adapt the new 
loader.



Concerning some of your perceived shortcomings:

On 03/18/2015 10:42 AM, Thomas Martitz wrote:
Currently geany exports a pointer to a struct, that contains more 
structs, which contain function points to the API functions. 
Fortunately this is nicely hidden to developers via macros. But due 
to gtkbuilder all functions and nothing prevents plugins from 
accessing these. And the macros are awkward and strange anyway. There 
is currently the linkage-cleanup PR in the works which improves this 
by actually exporting the API functions, and _only_ the API functions 
to plugins. 
Maybe I'm completely wrong on this from an architecture perspective, 
but part of what I like about writing plugins for geany is 
accessibility.  If we only get access to a subset of functions, then 
it seems less flexible what our plugins can actually do.  Yes, this 
allows us to write bad plugins that can do some sloppy things, but I 
say so what.  They are plugins. Someone would have to go out of 
their way to install most plugins outside of geany-plugins, and there 
is some vetting for that list of plugins.  I say by keeping the 
restrictions minimal on what plugins can access, we can get more 
powerful plugins and not block off potential plugins by our 
over-abstraction.


Take chrome/chromium browser, for instance.  They basically have 
restricted all plugins to be at most a button on the toolbar or 
effecting web pages.  There seems to be no possible way to write a 
plugin to get vertical tabbing I so appreciate in firefox (and geany 
for that matter) because chrome seems to have this stuck-up mac 
attitude that it's the way they intended, no customization allowed, 
mission accomplished https://www.youtube.com/watch?v=MgSQA1jqFpM.  
Maybe I'm wrong, maybe that's not chrome's motive, but I certainly 
don't like the lack of flexibility of their plugin architecture.  (If 
anyone knows a way on linux to get vertical tabs in chrome, that would 
be awesome ;-)


I suppose you could argue that having access to almost everything 
requires more frequent updating of plugins, but personally I haven't 
had more than one or two line changes with any update to geany.  Plus 
then we have to worry more about plugin support and it's own set of bugs.


That's just my opinion.  Thoughts?


We never supported plugins that call non-API functions. In fact, that 
it's possible now is a mistake. And the reason is simple: We can only 
maintain a defined API. We are not able to able to provide backwards 
compatibility for plugins that call functions we cannot know about.


Therefore we define the API, and commit to support that API. If you 
think the API is insufficient, then please speak up, describe your use 
case and get the function(s) you need added to the API. Then we can 
support these function and keep your plugin working. And that means that 
we keep your users happy. I think we are generally not that rigid at all 
as to what's added to the API, but it has to be formally defined. I 
think this is also in your interest, as it means less headaches for you 
going forward.


Don't think of the API as a restriction, instead it's the set of 
functions that Geany developers maintain on your behalf.


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

Re: [Geany-Devel] New plugin loader mechanisms

[Thomas Martitz]

Am 18.03.2015 um 23:21 schrieb Matthew Brush:

On 15-03-18 03:05 PM, Thomas Martitz wrote:

Am 18.03.2015 um 22:15 schrieb Matthew Brush:



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


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


Thinking about it, if the plugin can't run because it's missing resource
files required for its operation, then I think it should be treaded like
incompatible plugins. This has the benefit that they will be attempted
to be loaded on the next startup if the user had previously selected it.


For resource files like say a GtkBuilder UI file, I'd agree, but there 
may be some other cases, for example if a plugin dynamically loaded 
some particular library (or variant of a library) based on user 
configuration, it'd be useful to report to the user that the library 
is wrong, or no longer available, or whatever.




Based on user configuration implies that it's a decision that is made 
after the plugin's init(). If it allows the user to configure it without 
this dependency then the plugin is considered operational, and init() 
should not fail. Remember that a init() == FALSE would imply that the 
plugin cannot be activated, and therefore not configured (i.e. you 
cannot configure back so that it doesn't need the missing dependency).


Such custom requirements  errors are better placed in the plugin code 
itself.





I'm thinking if the plugin loaded successfully, then it should be
operational too. Meaning that init() should not fail, but simply
activate the plugin. As outlined above, my proposal already covers the
case compatible but not operational due to missing runtime
dependencies you described.



For cases like GeanyPy which loads arbitrary Python scripts (which are 
even fully executed on import), and in a language where Exceptions are 
common (especially during development), it would probably be useful to 
signal that the plugin script couldn't be loaded and maybe even be 
able to provide a formatted traceback of the Python exception or such.


In my roadmap geanypy does not load scripts in its init(), but through a 
separate API (so that the scripts integrate into the main plugin 
manager). Anyway, geanypy init() isn't the right place because geanypy 
can load multiple scripts, and which scripts can change afterwards after 
init has run. And finally, all those scripts do not change the fact that 
geanypy itself is operational, and this is what we're talking about.


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

Re: [Geany-Devel] New plugin loader mechanisms

[Thomas Martitz]

Am 18.03.2015 um 22:23 schrieb Lex Trotman:

Hi Thomas,

In general this looks like an improvement to the current method of
setting up plugins, except it continues to require the plugin .so file
to be dlloaded just to populate the plugin manager.  That will run the
dll initialization code, and may therefore break Geany.  Have you
thought about having a separate plain data file with the data for the
plugin manager so the dll doesn't need loading until its activated by
the PM?

A few specific things in-line below.


Yes I have thought a lot about this, and I concluded that libpeas is the 
right way to accomplish this. Therefore my longterm goal is to use 
libpeas for geany plugins. According to my current roadmap I'll 
implement this as a plugin (i.e. a plugin that uses libpeas to proxy 
other plugins), which I already have prototyped. In this scenario the 
other plugins use the peas-style .ini metafile.


To be able to do this I need a few, relatively minor changes, to Geany 
to support this infastructure. This will also benefit geanypy, which can 
then too act as a proxy and finally show scipts in the main PM dialog 
and support keybindings properly. All of these infrastructure changes 
remain API and ABI compatibility to all existing plugins.


For Geany core I don't plan to bring a metafile soon. I tried to get 
libpeas into the core, but such major changes are not feasible at the 
moment.



Ok, the number of symbols went from 5-6 to 1 but we still have the
same name exported from each dll, so the original problem of symbols
still exists.  I don't think there is a solution really.


This is a solution, and I think it's the only one. The difference is 
that with this symbol it is only referenced once through 
g_module_symbol() by geany, by using the GModule handle. This way 
namespace collisions *cannot* occur. Afterwards the function is never 
referenced anymore, neither by the core nor plugin, so in the case that 
a second plugin's geany_load_module() collides with the one of the first 
plugin the first one is never referenced again anyway. There is no 
problem here.


Whereas now plugins reference their geany_plugin globals (without 
g_module_symbol()) which, unless measures are taken, collide accross 
plugins (so plugin 1 could accidentally access plugin 2's geany_plugin).


There is no other way of loading C shared libraries and registering them 
as plugins.




And the only thing this function ought to do is to call
geany_plugin_register(). This does 4 things
1) Provide the plugin handle to the plugin very early
2) Perform abi and abi checks, so this is finally done inside geany. Added
bonus is that geany knows the requested api and can possibly apply
backcompat workarounds on a per plugin basis (instead of globally), warn
about very old plugins or even deny loading them.

This precludes the plugin from adapting itself to Geany since the
plugin is not supplied with the API and ABI numbers.  It would be good
if a plugin could do simple things like:

 if (ABI  124) f1() else f2();


Surely you mean if (API  124) f1() else f2() right?

But indeed, the API version could be passed to geany_load_module() to 
allow for the above. Passing the abi version is pretty useless as the 
plugin will only load with one specific abi anyway so it can't adapt.




Also it would be good to consider the semantics of API and ABI since
there are some conditions where we cannot express a change in the
interface except for the hammer of an ABI break.


We should be able with the new loader mechanism, since we learn about 
the plugin's minimum API version. Now we can not only deny based on the 
ABI version but also based on the minimum API (we could possibly deny 
loading plugins which are written against too old API version).


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

Re: [Geany-Devel] New plugin loader mechanisms

[Thomas Martitz]

Am 18.03.2015 um 22:15 schrieb Matthew Brush:



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


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



+1, I've always wanted a way to signal Geany don't bother, it's just 
going to crash you if you keep going. The only way I can see to 
handle critical failures without a status return from there is to keep 
a global variable and guard each function so it can't execute its 
normal code, which is a bit of a pain and weird for users if the 
plugin loads but doesn't do anything.


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



Thinking about it, if the plugin can't run because it's missing resource 
files required for its operation, then I think it should be treaded like 
incompatible plugins. This has the benefit that they will be attempted 
to be loaded on the next startup if the user had previously selected it. 
Incompatible plugins simply return false in geany_load_module() [I've 
implemented a safety guard geany_load_modules() even though the abi/api 
version check failed]. The plugin can also print the reason to 
stdout/msgwin/error dialog from within that function, although IMO a 
dialog is too intrusive.


I'm thinking if the plugin loaded successfully, then it should be 
operational too. Meaning that init() should not fail, but simply 
activate the plugin. As outlined above, my proposal already covers the 
case compatible but not operational due to missing runtime 
dependencies you described.


I said in my proposal it should do nothing but call 
geany_register_plugin(), but I guess we can relax that by allowing also 
for testing if the plugin itself is operational.


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

Re: [Geany-Devel] Proxy Plugins Update

[Thomas Martitz]

Am 11.07.2014 um 22:03 schrieb Colomban Wendling:

Le 07/07/2014 18:48, Thomas Martitz a écrit :

[...]

In my last post I've followed the approach of proxy plugins, aka pluxys.
This approach is based on geanypy and implements a plugin API for
plugins to act as proxy. I have mostly finished that (including an
trivial example pluxy), and ported geanypy to this framework. The result
is that with this approach I was successfully able to load python
plugins with the core, including access to the plugin API, to the extend
that geanypy allows plus keybindings via a new (experimental) API call.
I think this should cover almost everything you would want for python
plugins.

Since with that work you can successfully load python plugins I consider
this approach workable.

Nice.


Now that the pluxy approach is in the final stages I went onto toying
with libpeas.

[...]

There are three areas of problems with libpeas before we can adapt it,
two of which I could already solve in a fork.

[...]

If using libpeas really requires having a modified version of it lying
in our code, I'm not convinced it's a great idea.




FWIW, I did talk to the libpeas maintainer, Garret Regier. I cc'd him to 
get him into the loop.


Unsurprisingly, I met resistance to allow any changes that are only 
useful to load legacy plugins, I don't see any hope in this direction.


However, the Garret made a proposal that could enable us to load our 
existing plugins (using libpeas) without relying on any modifcations to 
libpeas.


Please note before juding that this needs only be done for 
non-peas-enabled plugins. We can peas-enable all of geany-plugins at 
compile time (using a mechanism not described here but which I already 
thought out) so this really does not apply g-p, but only out-of-tree 
plugins. And if it turns out we care too little about these out-of-tree 
plugins we can skip the whole backward-compat loading stuff and make an 
immediate switch to libpeas, and treat it like an ordinary API/ABI bump.


The proposal:
1) Scan the plugin dir for non-peas-enabled plugins (they can be 
distinguished by a) lacking a corresponding .plugin and b) missing the 
lib prefix in the filename)
2) For each of these, copy them to a user-writable dir (perhaps 
~/.config/geany/XXX or ~/.local/lib/geany/XXX), if not already done by a 
previous session
3) Load the plugin into a special environment for the purpose of 
extracting it's metadata and generating a correspoding .plugin file. The 
environment can be a separate process (geany or separate binary) or 
within geany itself
4) Write the .plugin file for each to next to the copied plugin binary 
(can use GKeyFile API for that).
 *** The Module key needs to point to a wrapper binary that can provide 
the plugin entry point required by libpeas, I'll call it modlib. And the 
Module key needs to be unique across all available plugins, as required 
by libpeas

5) Load the plugin-specific modlib copy using standard libpeas apis

Point 5) is the most tricky. The modlib's job is only to load the actual 
plugin and create the gobject interface instance. It is suggested that 
the modlib implements the PeasExtensionBase [1] interface so that it can 
itself determine which actual plugin to load, by looking at its 
PeasPluginInfo. There needs to be a copy of the modlib for each actual 
plugin, to keep the Module key in the .plugin unique. And the modlib 
needs to register a unique GObject (GType) per plugin that libpeas 
instantiates (this would proxy the actual plugins exported functions).


Please comment on what you think.

[1]: https://developer.gnome.org/libpeas/stable/PeasExtensionBase.html
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] Infobar file deleted/renamed behaviour

[Thomas Martitz]

Am 23.10.2014 um 04:11 schrieb Matthew Brush:

On 14-10-22 06:53 PM, Lex Trotman wrote:

On 23 October 2014 11:53, Matthew Brush mbr...@codebrainz.ca wrote:

Hi All,

Since there's some discussion about infobar behaviour, I thought I'd 
mention

a couple things I've noticed using it in my day-to-day workflow.

When you delete a file from disk, and then assuming the infobar 
kicked in
(see below), it pops up the infobar as expected. The problem is that 
there's

no quick way to say Ya, ya, I deleted that on purpose, just close the
file. IMO, there should be a Close button on the infobar that 
allows you
to bypass the redundant dialog that pops up when trying to close a 
document

that you've been notified about, for example:

-
File foo.txt was not found on disk [Resave][Dismiss][Close]
Some different message here
-

Clicking the proposed [Close] button would have the same effect as what
currently requires two steps; clicking the tab close button or Close 
menu
item and then clicking the Don't Save button in the dialog that 
pops up.


Does that sound reasonable?


Yes, would just ask for some space between dismiss and close for those
with bad aim (like me :)
BTW which is default (if any)?



The other thing I wondered is, should we not do a disk check on a 
file
that hasn't been switched to when it's being closed? I mean we do 
the check
and show the infobar on tab-switch (due to lacking proper/usable 
inotify
support), but if the user doesn't actually switch to the tab, then 
we just
close the file without any warning that the buffer in that document 
has no

disk file anymore and closing it will lose those contents forever.


Sounds like a sensible safe default behaviour, but with a various pref
to turn it off for those whose workflow makes it *really* annoying.



And/or a way to dismiss many together for bulk operations like Close 
All and Close Others (and obviously when exiting). Sometimes you 
see those dialogs like:


++
|-  Unsaved Changes!  -X-|
++
| The following files are not saved: |
| == |
|   [ ] Resignation_Letter.txt   |
|   [ ] Wedding_Vows_WIP.md  |
|   [ ] Baby_Pictures.xpm|
|   [ ] ...  |
| == |
| Do you want to save them?  |
| -- |
| [ No, Just Exit] [ Yes Please ] [ Cancel ] |
++

We could do something like that.


Nice idea. Perhaps add a check box [x] Remember this decision, and 
store that in a pref.


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

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

[Thomas Martitz]

Am 13.10.2014 15:21, schrieb Colomban Wendling:

Le 13/10/2014 08:06, Thomas Martitz a écrit :

Hi,

this is about commit ab7a0018b2518793f26af2fe20a06a8a1886e031 and the
message reads 
Don't prompt for reload from infobar when there are no unsaved changes.

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


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

Even when clicking the Reload button from the infobar?



No. The commit msg read like the infobar wouldn't even pop up. The 
infobar requires explicit user action. One instance of explicit user 
action is sufficient. Sorry for the noise.


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

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

[Thomas Martitz]

Hi,

this is about commit ab7a0018b2518793f26af2fe20a06a8a1886e031 and the 
message reads 

Don't prompt for reload from infobar when there are no unsaved changes.

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


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

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

[Thomas Martitz]

Am 21.09.2014 um 15:48 schrieb Dimitar Zhekov:

Hi,

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


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


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



This is a joke right?

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


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


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


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

[Geany-Devel] Patch for scintilla (Enable g-ir-scanner for ScintillaWidget.h)

[Thomas Martitz]

Hello,

I proposed a patch for scintilla, to make it more g-ir-scanner-friendly. 
If you want to chime in, or if this patch conflicts with Geany in a way 
that I'm not aware of, please join the fun.


https://groups.google.com/d/msg/scintilla-interest/Z7lk3SkBkxs/nHIHPGYCgbkJ

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

Re: [Geany-Devel] Proxy Plugins Update

[Thomas Martitz]

Am 12.07.2014 01:35, schrieb Lex Trotman:

On 12 July 2014 09:25, Matthew Brush mbr...@codebrainz.ca wrote:

On 14-07-11 01:25 PM, Thomas Martitz wrote:

Am 11.07.2014 22:03, schrieb Colomban Wendling:

Le 07/07/2014 18:48, Thomas Martitz a écrit :

[...]

In my last post I've followed the approach of proxy plugins, aka pluxys.
This approach is based on geanypy and implements a plugin API for
plugins to act as proxy. I have mostly finished that (including an
trivial example pluxy), and ported geanypy to this framework. The result
is that with this approach I was successfully able to load python
plugins with the core, including access to the plugin API, to the extend
that geanypy allows plus keybindings via a new (experimental) API call.
I think this should cover almost everything you would want for python
plugins.

Since with that work you can successfully load python plugins I consider
this approach workable.

Nice.


Now that the pluxy approach is in the final stages I went onto toying
with libpeas.

[...]

There are three areas of problems with libpeas before we can adapt it,
two of which I could already solve in a fork.

[...]

If using libpeas really requires having a modified version of it lying
in our code, I'm not convinced it's a great idea.


It's because we require modifications to it for backwards compat, this
way we could maintain ABI and API stability across a transition to
libpeas. We can drop it from our source after the transition period
and/or convince upstream to accept rather geany-specific code (unlikely).

Another issue is that upstream libpeas tends to require recent glib/gtk
versions even when not justified. The fork would allow us to lower the
glib/gtk requirements.


If they're not justified, then why not provide upstream with a patch that
lowers them to minimum version required?


libpeas is tiny, and is not actively developed (one can consider the
project mostly done). So I don't think it's a big deal really. On the
other concept of libpeas does provide a lot of benefits so it's worth it
IMO.

What alternatives can you propose?


Thomas,

As I understand it you only need to bundle peas to be able to add the
backward compatible loader?


Yes.



If that is going to be for a limited deprecation period (say two
release periods after the peas version is released) then it is
reasonable to argue that the changes to libpeas are Geany specific,
for a limited period and not worth pushing upstream.



The changes would be very geany specific, although the first one 
(supporting plugins that are not described by a .plugin file) can 
perhaps be made generic in some way. But the loader is always going to 
be highly Geany specific, and I don't think it would be accepted by 
upstream, seeing that they even dropped a java script loader that is not 
app-specific.


But yea, but I didn't ask yet either. This is in part because the last 
mailing list activity is from 2012 which didn't receive any response.


I'd like to remember you about another point: Even if libpeas would 
accept all our modifictions like tomorrow, Geany realistically couldn't 
depend on it for the near future anyway (too new). By the time we can 
depend on it, i.e. when it lands in the current enterprise distros (REHL 
will probably only have it by RHEL 8), we probably don't even need to 
modifications anymore. This is the main reason that I don't think it's 
worth even trying to push the changes upstream: we wouldn't be able to 
use that upstream for a few years, and once we can we don't need these 
changes anymore.


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