[Geany-Devel] Intro

[Mark Robinson]

Hi All,

Just a note to introduce myself.  I am Mark, an old-timer coming from the world 
of Fortran.  My interest in Geany is to use it as a platform to introduce 
specific functionality to help me and others in my line of work.

I work for a software company that writes simulation software.  You probably 
thought of flight simulators, right?  Well no.  We write software that 
simulates the behaviour of real world physics, like how a car behaves when you 
drive it round a corner, or how cracks propagate material.  For this, we 
develop mathematical solvers that solve partial differential equations and use 
numerical integration to compute solutions to physical environments.  The 
solvers use a text file input as their definition, and have a macro based 
language that controls the operations of the solver.  If you know Matlab, you 
know the idea.  We just do it on an industrial scale.

I'll be requesting an additional file type (additional lexer I have written) be 
added to Geany, but thereafter I expect most of the functionality will come in 
the form of a plugin (I am writing one of these as well).  I am not a strong 
user of C/C++, as I said procedural Fortran is my forte, and this is my first 
plunge into contributing to an open source project, so expect some dumb 
questions.

Enough of the intro; I'll post specifics in a separate thread.

Kind regards,

Mark Robinson

Never give in.  Winston Churchill.

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

Re: [Geany-Devel] On Deprecation of Platforms

[Thomas Martitz]

Am 03.10.2013 02:19, schrieb Lex Trotman:

All Developers,

Its time we deprecated windows support!!


It's not. See other's replies and my points below. I should mentioned 
that I do use Geany on Windows at work successfully. I don't use it to 
build/compile so the process spawning bug doesn't affect me.




The windows code in Geany is:

- unmaintained and bit-rotting


It's not as actively maintained as the Linux code. However the current 
state is *working*. Why drop support for a working platform if it's 
mostly working? It's not like it's costing us anything at the moment.




- buggy


Not significantly more buggy than the Linux version. The most prominent 
problem is the process spawning which doesn't handicap Geany's main 
purpose: editing source code. I don't know about a bug that is so severe 
that it requires immediate action.




- holding us at an unreasonably old GTK version


As others have mentioned, this is not true. LTS distros are. Windows has 
a more recent stable GTK release since a while. The problem is that the 
installers are still generated with the old one. Who can fix this? Are 
the scripts for this in Git?




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

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


You can also do (limited) testing with Wine. It doesn't even need a 
Windows license.


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

Re: [Geany-Devel] Intro

[Thomas Martitz]

Am 05.10.2013 11:11, schrieb Mark Robinson:


Hi All,

Just a note to introduce myself. I am Mark, an old-timer coming from 
the world of Fortran. My interest in Geany is to use it as a platform 
to introduce specific functionality to help me and others in my line 
of work.




Welcome!


I’ll be requesting an additional file type (additional lexer I have 
written) be added to Geany, but thereafter I expect most of the 
functionality will come in the form of a plugin (I am writing one of 
these as well). I am not a strong user of C/C++, as I said procedural 
Fortran is my forte, and this is my first plunge into contributing to 
an open source project, so expect some dumb questions.




First of all, we have an upstream first ideology, partly because we 
don't have the resources to extra maintain patches for the projects we 
use. That means that if you write a lexer you should post that to 
Scintilla upstream, so that it will land into Geany when we update our 
copy. Then we can accept the filetype definition as well.


Secondly, I think it might actually possible to write plugins mostly in 
fortran (although I'm not sure Fortran is a suitable language for this, 
I know nothing about it) with a little C boilerplate code. But GCC 
allows to call C functions from fortran doesn't it?



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

Re: [Geany-Devel] Intro

[Lex Trotman]

On 5 October 2013 19:20, Thomas Martitz <
thomas.mart...@student.htw-berlin.de> wrote:

> Am 05.10.2013 11:11, schrieb Mark Robinson:
>
>>
>> Hi All,
>>
>> Just a note to introduce myself. I am Mark, an old-timer coming from the
>> world of Fortran. My interest in Geany is to use it as a platform to
>> introduce specific functionality to help me and others in my line of work.
>>
>>
> Welcome!
>

And Hi also.


>
>> I’ll be requesting an additional file type (additional lexer I have
>> written) be added to Geany, but thereafter I expect most of the
>> functionality will come in the form of a plugin (I am writing one of these
>> as well). I am not a strong user of C/C++, as I said procedural Fortran is
>> my forte, and this is my first plunge into contributing to an open source
>> project, so expect some dumb questions.
>>
>>
> First of all, we have an upstream first ideology, partly because we don't
> have the resources to extra maintain patches for the projects we use. That
> means that if you write a lexer you should post that to Scintilla upstream,
> so that it will land into Geany when we update our copy. Then we can accept
> the filetype definition as well.
>

> Secondly, I think it might actually possible to write plugins mostly in
> fortran (although I'm not sure Fortran is a suitable language for this, I
> know nothing about it) with a little C boilerplate code. But GCC allows to
> call C functions from fortran doesn't it?
>

See http://gcc.gnu.org/onlinedocs/gfortran/Interoperability-with-C.html but
C string handling in Fortran is messy, and for an IDE most code is string
handling.  As Thomas said, I think Fortran is probably not the right
language to use for a plugin.  In particular as all the plugin API is
actually calls via a function pointer, not direct function calls.

You should read (and re-read) the HACKING file, it covers adding a file
type and other issues around Geany development.

Cheers
Lex


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

Re: [Geany-Devel] Intro

[Mark Robinson]

Hi Thomas,

Thanks for the welcome.  You answered one of my first questions, concerning the 
lexer, about adding it to the Scintilla project.  I will endeavour to do this, 
but that means joining that group as well - remember I am a procedural guy, so 
time will tell.

Oh my goodness, inter-language calls from Fortran to C to Fortran.  Yuk.  I 
learnt this interface for those solvers I mentioned and it is kludgey; it is 
easier (and more effective) to learn C/C++, which I am trying to do.  My remark 
about C/C++ was intended to alert you (the group) not to expect me to 
understand everything you tell me straight away.

Once I have the lexer added to Scintilla, I will return with the other 
modifications to support the new filetype (called DMAP by the way).

Thanks again for the welcome...M

-Original Message-
From: devel-boun...@lists.geany.org [mailto:devel-boun...@lists.geany.org] On 
Behalf Of Thomas Martitz
Sent: 05 October 2013 11:20
To: Geany development list
Subject: Re: [Geany-Devel] Intro

Am 05.10.2013 11:11, schrieb Mark Robinson:
>
> Hi All,
>
> Just a note to introduce myself. I am Mark, an old-timer coming from 
> the world of Fortran. My interest in Geany is to use it as a platform 
> to introduce specific functionality to help me and others in my line 
> of work.
>

Welcome!
>
> I'll be requesting an additional file type (additional lexer I have
> written) be added to Geany, but thereafter I expect most of the 
> functionality will come in the form of a plugin (I am writing one of 
> these as well). I am not a strong user of C/C++, as I said procedural 
> Fortran is my forte, and this is my first plunge into contributing to 
> an open source project, so expect some dumb questions.
>

First of all, we have an upstream first ideology, partly because we 
don't have the resources to extra maintain patches for the projects we 
use. That means that if you write a lexer you should post that to 
Scintilla upstream, so that it will land into Geany when we update our 
copy. Then we can accept the filetype definition as well.

Secondly, I think it might actually possible to write plugins mostly in 
fortran (although I'm not sure Fortran is a suitable language for this, 
I know nothing about it) with a little C boilerplate code. But GCC 
allows to call C functions from fortran doesn't it?


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


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

Re: [Geany-Devel] Intro

[Mark Robinson]

Hi Lex,

Thanks for the welcome.  Yes, I read the HACKING doc., and followed it to the 
letter.  I have the new lexer up and working on a private link from a GIT 
extract.  The plugin seems to be working as well, so my C skills are getting 
better (I think).  The idea is to take the snippets in snippets.conf and allow 
the user to select them (double click to insert snippet) from a scroll window 
in the side-bar rather than have to remember the keyword (I'm old as well, so 
memory is an issue :)).  The new filetype I want to add has over 500 functions 
in its library, so you (I) can't remember the snippet keyword for all of them.  
It occurred to me that this should work for any snippets, and it does.

However, although the plugin works for any filetype, it has a "look up this 
snippet in a PDF file" capability that needs the new filetype to demonstrate 
it.  So, one thing at once (I am a procedural guy, remember), I'll request 
addition of the filetype to Scintilla and then move forward.

Regards...M


From: devel-boun...@lists.geany.org [mailto:devel-boun...@lists.geany.org] On 
Behalf Of Lex Trotman
Sent: 05 October 2013 11:36
To: Geany development list
Subject: Re: [Geany-Devel] Intro



On 5 October 2013 19:20, Thomas Martitz 
mailto:thomas.mart...@student.htw-berlin.de>>
 wrote:
Am 05.10.2013 11:11, schrieb Mark Robinson:

Hi All,

Just a note to introduce myself. I am Mark, an old-timer coming from the world 
of Fortran. My interest in Geany is to use it as a platform to introduce 
specific functionality to help me and others in my line of work.

Welcome!

And Hi also.


I'll be requesting an additional file type (additional lexer I have written) be 
added to Geany, but thereafter I expect most of the functionality will come in 
the form of a plugin (I am writing one of these as well). I am not a strong 
user of C/C++, as I said procedural Fortran is my forte, and this is my first 
plunge into contributing to an open source project, so expect some dumb 
questions.

First of all, we have an upstream first ideology, partly because we don't have 
the resources to extra maintain patches for the projects we use. That means 
that if you write a lexer you should post that to Scintilla upstream, so that 
it will land into Geany when we update our copy. Then we can accept the 
filetype definition as well.

Secondly, I think it might actually possible to write plugins mostly in fortran 
(although I'm not sure Fortran is a suitable language for this, I know nothing 
about it) with a little C boilerplate code. But GCC allows to call C functions 
from fortran doesn't it?

See http://gcc.gnu.org/onlinedocs/gfortran/Interoperability-with-C.html but C 
string handling in Fortran is messy, and for an IDE most code is string 
handling.  As Thomas said, I think Fortran is probably not the right language 
to use for a plugin.  In particular as all the plugin API is actually calls via 
a function pointer, not direct function calls.

You should read (and re-read) the HACKING file, it covers adding a file type 
and other issues around Geany development.

Cheers
Lex



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

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

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

[Nick Treleaven]

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

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

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


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

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

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

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

[Nick Treleaven]

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

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

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

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

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

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

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

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



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


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



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


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



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


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


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


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


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


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



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


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


I did try.


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

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




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


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



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


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


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


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

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


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




Cheers,
Matthew Brush

[1]: Causes a command prompt to popup, doesn't support filenames with
spaces, uses a temp file, uses system(), leaves a bunch of complicated
dead code, now 3rd way to spawn process, etc.
[2]: https://bugzilla.gnome.org/show_bug.cgi?id=510664



___
Devel mai

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

[Nick Treleaven]

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

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


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


I did try.


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



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

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





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


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


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

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

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

Re: [Geany-Devel] Intro

[Matthew Brush]

On 13-10-05 03:12 AM, Mark Robinson wrote:

Hi Lex,

Thanks for the welcome.  Yes, I read the HACKING doc., and followed
it to the letter.  I have the new lexer up and working on a private
link from a GIT extract.  The plugin seems to be working as well, so
my C skills are getting better (I think).  The idea is to take the
snippets in snippets.conf and allow the user to select them (double
click to insert snippet) from a scroll window in the side-bar rather
than have to remember the keyword (I'm old as well, so memory is an
issue :)).  The new filetype I want to add has over 500 functions in
its library, so you (I) can't remember the snippet keyword for all of
them.  It occurred to me that this should work for any snippets, and
it does.



Oliver Marks made a GeanyPy plugin that sounds very similar to this. I 
can't find the Github repo anymore but you can see the Google+ posting 
about it here[1] and the Ubuntu PPA is here[2].


Just thought I'd mention it since it sounds so similar.

Cheers,
Matthew Brush

[1]: https://plus.google.com/108080448324780364479/posts/5KTLneQbxyG
[2]: https://launchpad.net/~oly/+archive/geany
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

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

[Matthew Brush]

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

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

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


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


I did try.


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



Ugh, been there, I feel for ya :)


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

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






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


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


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

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



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


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


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


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


Cheers,
Matthew Brush

[1]: And maybe fix it so it does cmd.exe quoting properly.
[2]: Of course it's in Git history so if async spawning ends up not 
working for many people we can always put it back later.

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

Re: [Geany-Devel] Interested making a patch to add QML support

[Tory Gaurnier]

Just thought I'd give everyone an update, it's still coming along, I 
have the tree view in the symbol list working as expected (it was easier 
than I thought, I was overcomplicating it at first), right now I'm 
working on cleaning up my code, and optimizing certain things.


I would be done by now if I wasn't working so much, but I should have 
QML support finished within the next few days (if I have the time I'll 
get it finished tonight). Then I'll be ready to submit my work to ctags, 
and Geany.

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

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

[Dimitar Zhekov]

On Sat, 05 Oct 2013 07:40:15 -0700
Matthew Brush  wrote:

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

Scope uses g_spawn_async_with_pipes() on Win~1 to both read from and
write to gdb without any problems that I know of. Could be because of
the specially written event source, or simply my ignorance. Also
can't remember whether I specially tested stderr.

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

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

[Lex Trotman]

On 6 October 2013 06:06, Dimitar Zhekov  wrote:

> On Sat, 05 Oct 2013 07:40:15 -0700
> Matthew Brush  wrote:
>
> > So with the pull request adding system() as a fallback/hidden
> > preference, maybe we could just drop the win32 API code altogether,
> > switch back to using the same codepath as all platforms (ie. GLib async
> > spawning) and if people experience issues, we can use as further data
> > points to troubleshoot GLib async spawning and we can recommend they try
> > the system() option[1] as a workaround?
>
> Scope uses g_spawn_async_with_pipes() on Win~1 to both read from and
> write to gdb without any problems that I know of. Could be because of
> the specially written event source, or simply my ignorance. Also
> can't remember whether I specially tested stderr.
>
>
Or possibly works because its just short messages, IIRC one of the problems
only showed up with lots of data.

Cheers
Lex



> --
> E-gards: Jimmy
> ___
> 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] Interested making a patch to add QML support

[Lex Trotman]

On 6 October 2013 01:25, Tory Gaurnier  wrote:

> Just thought I'd give everyone an update, it's still coming along, I have
> the tree view in the symbol list working as expected (it was easier than I
> thought, I was overcomplicating it at first), right now I'm working on
> cleaning up my code, and optimizing certain things.
>
> I would be done by now if I wasn't working so much, but I should have QML
> support finished within the next few days (if I have the time I'll get it
> finished tonight). Then I'll be ready to submit my work to ctags, and Geany.


One thing you could do to assist is to make a test suite for the tag
parser, see the preliminary ones Colomban has been adding.  Another thing
is to see if you can get others to use and comment on the filetype.  There
is some reluctance to commit new filetypes for languages that the Geany
devs don't know, because of the effort required to learn the language to
tell if the colouring and symbology make sense.  Having more than one user
of the filetype makes it more likely that it will be "just accepted".

Cheers
Lex

>
> __**_
> 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