Re: [Geany-devel] Separating session file lists from config (again)

2012-09-11 Thread Thomas Martitz

Am 11.09.2012 19:48, schrieb Dimitar Zhekov:

Yes, and I would expect that to be everyone who keeps a project file
in *public* VCSes, nobody else in the world cares which files you had
open last time you did something on the project.

If by public you mean somewhere in the internet, I haven't seen a
single OSS that includes with $project.geany, not even Geany itself or
geany plugins.


That's because it's not a sensible thing to do currently, because 
session information is in $project.geany as well. See $topic.


Best regards.
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel


Re: [Geany-devel] Ship with Grep on Windows?

2012-09-03 Thread Thomas Martitz

Am 03.09.2012 14:38, schrieb Colomban Wendling:

Le 03/09/2012 09:57, Matthew Brush a écrit :

Hi,

It would be useful to ship the Grep binary[1] (and dependencies) with
Geany for Windows. It could be added to the installer for not too much
extra size[2] and would enable the Find in Files feature to work on
Windows by default. Normally I wouldn't like to add more stuff to the
installer but I think without it Geany is missing a very useful feature
on Windows by default.

Does it sound reasonable or no?



+1


It looks reasonable and even desirable to me, but I must admit I don't
really care since I almost never use Windows anyway…

BTW, you say it adds 1-2MB, but what's the overall size of the
installer?  If it is 2MB on a 4MB installer it looks huge, but if the
installer was already 40MB large I doubt anybody would notice.



For 1.22, the geany-only installer is 2MB and the geany+gtk one is 8MB. 
Perhaps only put it into the gtk one.


___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel


Re: [Geany-devel] Indicators improvement

2012-08-01 Thread Thomas Martitz

Am 01.08.2012 12:02, schrieb Lex Trotman:

Matthew,

Try this attachment.

Cheers
Lex


What is this about?

Best regards.
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel


Re: [Geany-devel] Third party plugin publish and third party library bundle problem

2012-07-16 Thread Thomas Martitz

Am 16.07.2012 16:41, schrieb Hong Xu:

On 2012/7/15 20:28, Frank Lanitz wrote:

On Sun, 15 Jul 2012 21:56:32 +1000
Lex Trotman ele...@gmail.com wrote:


BTW you mentioned a third party library, but you didn't say what
library.  It would of course have to have a suitable license to allow
it to be included.


Yes. I missed that too. Most plugins are GPL2+ so it needs to be also
GPL2+... BSD should also be fine in most cases. But LGPL could be
problematic.




I prefer Simplified BSD License for this plugin. What do you mean it 
should be fine for most cases? Could you explain more?


The 2-clause BSD is always fun. As is LGPLv2+.

Best regards.
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel


Re: [Geany-devel] Third party plugin publish and third party library bundle problem

2012-07-15 Thread Thomas Martitz

Am 15.07.2012 14:26, schrieb Frank Lanitz:

On Sun, 15 Jul 2012 19:01:53 +0800
Hong Xu d...@hong.me wrote:


On 07/15/2012 03:40 PM, Frank Lanitz wrote:

On Sun, 15 Jul 2012 09:27:46 +0800
Hong Xu d...@hong.me wrote:


And, BTW, why geany-plugins project doesn't use a submodule for
each plugin? Not all people need to clone the whole repository,
and as it is separated to submodules, the permission control can
be better for developers.

IIRc this was under discussion in past but was dismissed due to
adding complexity and little overall understanding of this.
However, I don't think cloning the repository is this much traffic.
Also a goal was to have plugins and its patches being reviewed
before entering master to enforce a minimum on quality. This also
includes some fire-and-forget-plugins of some developers as you can
see from MAINTAINERS files there are a lot of plugins out of
maintenance.


Thanks. However, I have to make a pull request for any trivial
changes in this way. Do you think this is unnecessary?

We are still in finding a good flow on this as I agree its not optimal.
  


Most of the time changes are not actually trivial. Also multiple small 
and trivial changes can be submitted as a single pull request.


Anyway this is the linux kernel dev model and it works good (for some 
projects) even if tiny changes need to go through the chain as well.


Best regards.
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel


Re: [Geany-devel] draggable tabs - current state?

2012-07-14 Thread Thomas Martitz

Am 14.07.2012 04:20, schrieb Lex Trotman:

On 14 July 2012 07:07, Sean Felipe Wolfe ether@gmail.com wrote:

I'd like to be able to have 2-3 columns of tabs and be able to drag +
rearrange, something like Eclipse's draggable tab setup -- one of the
few things I like about Eclipse.

I assume this is non-trivial ... how horribly difficult would it be?

Multiple columns/rows of tabs, how hard can it be?

@#* hard, AFAICT you will have to change GTK, not Geany.

Note drag re-ordering already works.

Cheers
Lex



Can I at least have multiple sidebars with tabs being draggable between 
them (or make the message window a sidebar) ? :)


Currently Geany isn't so nice on a wide screen setup because much of the 
horizontal space is wasted, being bound to 80 or 100 column limit for 
source code. Vertical space is wasted because the message window could 
be a sidebar on wide screens.


Best regards.
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel


Re: [Geany-devel] draggable tabs - current state?

2012-07-14 Thread Thomas Martitz

Am 14.07.2012 12:39, schrieb Lex Trotman:

On 14 July 2012 20:21, Thomas Martitz
thomas.mart...@student.htw-berlin.de wrote:

Am 14.07.2012 04:20, schrieb Lex Trotman:


On 14 July 2012 07:07, Sean Felipe Wolfe ether@gmail.com wrote:

I'd like to be able to have 2-3 columns of tabs and be able to drag +
rearrange, something like Eclipse's draggable tab setup -- one of the
few things I like about Eclipse.

I assume this is non-trivial ... how horribly difficult would it be?

Multiple columns/rows of tabs, how hard can it be?

@#* hard, AFAICT you will have to change GTK, not Geany.

Note drag re-ordering already works.

Cheers
Lex



Can I at least have multiple sidebars with tabs being draggable between them
(or make the message window a sidebar) ? :)

Hi Thomas,

Well, tabs are part of the GTK notebook that the edit window is in, so
to put them in a sidebar you would be re-implementing part of GTK,
maybe instead look at making the document sidebar re-orderable instead
of sorted?




I didn't mean document tabs. I meant the symbols, files, etc tabs in the 
side bar which should be draggable to a second sidebar on the right 
(basically split the current sidebar into two with the editor in the 
middle).


Best regards.
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel


Re: [Geany-devel] draggable tabs - current state?

2012-07-14 Thread Thomas Martitz

Am 14.07.2012 13:55, schrieb Matthew Brush:


You can imagine also how this would be useful for plugins such as 
Webhelper or MultiTerm (or the builtin terminal). Like this:


http://tinypic.com/r/2d1px90/6


Or debugger. +1 :)

Best regards.
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel


Re: [Geany-devel] More Per-Project Configuration Options

2012-07-10 Thread Thomas Martitz

Am 10.07.2012 07:37, schrieb Matthew Brush:

On 12-07-09 04:57 PM, Braden Walters wrote:

Hi. I noticed a problem that affected me back in 0.2x that thankfully is
(mostly) solved in 1.22. When I say mostly, I mean it fixes how the
problem affects me right now, but possibly not for others, and I feel
this may also affect me again eventually. The problem I noticed is that
not all configuration options that may change from project-to-project
are actually settings you can change on a per-project basis. The options
that concern me the most are those that deal with the format of the
saved file (line ending characters, new line at end of file (fixed in
1.22), tabs/spaces (not a problem), file encoding). I'm interested in
the developers' opinions on this.

Someone in IRC also mentioned that if many more options become
configurable per-project, the global application options might be
rendered useless (as project settings will override everything). Perhaps
this could be solved by having a way to reset individual project options
(perhaps a list of all things that have been changed, and a Reset to
Global button to reset that individual item so it does not appear in
that project's file).

I'm curious what the core developers' opinion is on this. If it sounds
good, I'd definitely be interested in helping make it possible (although
I don't know the Geany code base, I could learn my way around relevant
parts).


Hi,

What about just adding new settings to the project config file without 
messing with the UI? Those who need them can RTM and see what settings 
are available, those who are content with what exists currently can go 
on happily ever after. You can add as many project preferences as you 
care to code and document this way.



I hate needing to edit config files directly. This is not user friendly.




If a user sets something in the project config file, it overrides the 
global config file when that project is open, end of story, no UI 
tricks needed to tell her this, it's just how it is (documented).


The other way(s) discussed seem like they would Eclipse the UI's 
usability.





I actually quite like how Eclipse handles this, it should be considered 
for Geany too:


Each global settings tab (given it can be overridden by a project) has a 
line at the top saying that it can be overridden on a per-project basis.


Then, for each project, each tab in the project preferences have a 
checkbox at the top that choose whether to inherit from global settings 
or override all settings in the tab. Unchecking the checkbox immediatly 
applies the global settings to the project. Checking the box prefills 
the settings with the values from the current global settings but can be 
changed obviously.


Note that settings are grouped in tabs, so there is not one checkbox per 
setting, but per tab.


This UI makes it easy to discover if stuff can be/is overriden by a 
project. It makes it easy to revert to global settings. It makes it 
possible without a massive amount new per-setting checkboxes to decide 
whether to override.


PS: Eclipse's way to handle per-file settings is also quite OK IMO but I 
guess that's another topic.


Best regards.
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel


Re: [Geany-devel] Remove MSYS dependency of Geany on Win~1

2012-06-28 Thread Thomas Martitz

Am 28.06.2012 15:41, schrieb Nick Treleaven:


-include localwin32.mk
ifdef MSYS
CP = cp
CP_R = cp -r
RM = rm
DIRSEP = /
endif

And then perhaps use $(MAKE) CP=$(CP) RM=$(RM) to pass these 
variables to the sub-makefiles so they don't need to have copies of 
the ifdef. They only need CP and RM.




Make variables are survive recursive invocations don't they?

Best regards
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel


Re: [Geany-devel] Crash when pasting a Zero-width space

2012-06-26 Thread Thomas Martitz

Am 26.06.2012 11:53, schrieb Harold Aling:

Updated to Geany 1.23 (git = 40da14b)

1. Create a new document (ctrl-n)
2. Copy/paste m​A (already has a zero-width space in the middle)
3. Press 'home'
4. Press 'delete'
5. Crash - 100% CPU


Works for me. No crash and no 100% CPU usage.



Geany also counts that character as 3 positions instead of 1.


Depending on your POV, this is the correct behavior (the pos field 
actually shows the byte offset since the start of the file, hence it's 
0-based also).

___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel


Re: [Geany-devel] [Geany] ANN: Geany 1.22 is out!

2012-06-21 Thread Thomas Martitz

Am 18.06.2012 23:56, schrieb Enrico Tröger:

And now also the Windows installers (with and without bundled GTK
runtime) are available.

On http://www.geany.org/Download/Releases and http://download.geany.org/.




Is there any particular reason you ship the old 2.16 gtk, instead of the 
supposedly superior 2.24x?


Best regards.
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel


Re: [Geany-devel] Geany Newsletter Issue #5

2012-05-28 Thread Thomas Martitz

Am 28.05.2012 13:27, schrieb Lex Trotman:


This doesn't actually call the C++ constructors/destructors in the way
they would be in normally be if the plugin had been statically linked.

This simply labels a C function to be called at dlopen time.  It may
be used to do some initialisation, but you would have to manually call
each constructor, ... too error prone, Franks advice to create
everything dynamically is sound.



I meant to say that global/static constructors/destructors are in fact 
called when a library is dlopened(), regardless of the language of 
calling code.


Anyway, I thought an example illustrates it better:


$ cat test.c
#include dlfcn.h
#include stdlib.h
#include stdio.h
int main()
{
void* h = dlopen(/tmp/foo/libtestcpp.so, RTLD_NOW);
if (!h) { printf(no lib %s\n, dlerror()); exit(-1); }
void (*fn)(void) = dlsym(h, hello);
if (!fn) exit(-2);
fn();
dlclose(h);
return 0;
}


$ gcc -o test test.c -ldl -g


$ cat test.cpp
#include iostream

namespace std {

class Test
{
public:
Test() { cout  Hello from Test  endl; }
~Test() { cout  Bye from Test  endl; }
};

static Test test;

}

extern C {

#include stdio.h

void hello(void)
{
printf(hello from extern C function\n);
}

}


$ gcc -o libtestcpp.so -shared -fPIC test.cpp -g -lstdc++ 
-Wl,--no-undefined



$ ./test
Hello from Test
hello from extern C function
Bye from Test



FWIW, does anyone know why I needed to link libstdc++ explicitely in my 
testing?


Best regards.
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel


Re: [Geany-devel] tagmanager changes

2012-05-09 Thread Thomas Martitz

Am 09.05.2012 07:47, schrieb Lex Trotman:

Using ctags, including locals in the tags generated from Geany source,
slightly more than doubled the number of tags, and for some C++ I have
around nearly four times the number.


But you only need the tags for the current scope and can drop them if 
you enter another (non-nested) scope. This surely doesn't double or 
quadruple the tags.


If I'm editing func A I don't want the locals of func B through Z in my 
autocompletion list.


Best regards.
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel


Re: [Geany-devel] tagmanager changes

2012-05-09 Thread Thomas Martitz

Am 09.05.2012 09:37, schrieb Lex Trotman:

On 9 May 2012 16:54, Thomas Martitz
thomas.mart...@student.htw-berlin.de  wrote:

Am 09.05.2012 07:47, schrieb Lex Trotman:


Using ctags, including locals in the tags generated from Geany source,
slightly more than doubled the number of tags, and for some C++ I have
around nearly four times the number.


But you only need the tags for the current scope and can drop them if you
enter another (non-nested) scope. This surely doesn't double or quadruple
the tags.

You can't drop them from the tags structures because when you are
parsing you don't know which scope the cursor is in.  So you have to
add them all, then decide which ones apply to the current scope.


Okay, but still only for the current file and not an entire project.

Best regards.
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel


Re: [Geany-devel] gitignore needs updating?

2012-04-22 Thread Thomas Martitz

Am 22.04.2012 10:40, schrieb Matthew Brush:


Also, `doc/geany.html` shouldn't be tracked, but I guess this one is 
on purpose, for people who build from Git but can't install 
`python-docutils` for whatever reason.



You _know_ it is on purpse but you never give up dont you? :)

Best regards.
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel


Re: [Geany-devel] Commit messages on merges

2012-03-05 Thread Thomas Martitz

Am 05.03.2012 00:13, schrieb Matthew Brush:

On 12-03-04 01:29 PM, Frank Lanitz wrote:

On Sun, 04 Mar 2012 13:01:27 -0800
Matthew Brushmbr...@codebrainz.ca  wrote:


On 12-03-04 07:07 AM, Colomban Wendling wrote:

Le 04/03/2012 09:28, Frank Lanitz a écrit :

On Sun, 04 Mar 2012 03:40:29 +0100
Colomban Wendlinglists@herbesfolles.org   wrote:


IMO we should not record merges when there is only one single
commit or when the commits are unrelated (though the latter
should probably be less common) and rather rebase or cherry-pick
the commits.

However, we must keep the merge when the commits are a whole
thing not to lose that information (when several commits are
needed to implement a single thing).


I agree. And in second case we have to keep care that merge
message is informative enough to don't go into complete tree just
to understand what have been done there. Personally I started
using the git merge command from command line more often instead
of github's web interface as its not satisfying my understanding.


Same for me, moreover because I prefer to test the PR locally as a
simple branch before doing the merge, so it's not much effort than
using the GitHub UI, and it's a lot more powerful.



Same here, but I don't think it matters whether using `git merge` or
the Github GUI to do it, there's still a need to change the default
merge message (apparently).


Issue on github is, that you aren't able to change the first line ...



... Which isn't necessarily a bad thing. It keeps them standard and 
the default first line contains useful information like that it was a 
merge, the PR #, the person who made the PR and their branch name.


In any case, I'm fine with doing it however everyone wants. I use gitk 
to view the history usually, so it's pretty obvious what all has 
happened.



IMO merge X from Y is perfectly fine. The commit is just that, a merge 
commit. It isn't necessary to contain more information, since the merged 
commits are there as well. They are not lost and they still describe 
what they change.  And the merge itself commit doesn't actually contain 
code changes so it might even be wrong to add a story to it (although 
describing the rationale of the merge is also good).


If merge commits are annoying they can be hidden from the log as I 
mentioned before.


Best regards.
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel


Re: [Geany-devel] Commit messages on merges

2012-02-27 Thread Thomas Martitz

Am 27.02.2012 08:44, schrieb Lex Trotman:

[...]

I guess if we can filter out merge commits and only show the real commit
information it should be good?

(See other message with individual commit messages)

Yeah, IMO git gives us lots of un-needed merge messages, not much more
we can really say other than merged master into branch, so we will
have to filter them for human consumption in newsletters anyway.



git log --no-merges
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel


Re: [Geany-devel] [geany/geany] 795ee4: Merge pull request #28 from RetroX/patch-1

2012-02-25 Thread Thomas Martitz

Am 25.02.2012 09:55, schrieb Lex Trotman:

On 25 February 2012 19:35, Frank Lanitzfr...@frank.uvena.de  wrote:

On Sat, 25 Feb 2012 10:43:10 +1100
Lex Trotmanele...@gmail.com  wrote:


On 25 February 2012 09:44, Thomas Martitz
thomas.mart...@student.htw-berlin.de  wrote:

Am 24.02.2012 23:34, schrieb Lex Trotman:


I don't agree with this change, the types are just that, types, not
keywords, they should not be highlighted as keywords.  They are not
always available.  This change should be reverted.


The list contained types before the commit and the commit just
added more for completeness.

I suggest using the secondary for types instead.

Yes, good idea, if I understand the comment in
highlightingmappings.h:206 it is meant for types.

Cheers
Lex

PS the existing list contains the fundamental types that are always
available without headers, these new ones need a header (though size_t
is used so much that almost any header will do :)


I did like that idea adding more often used one. But you are right
cleaning up a bit and maybe resorting them would be might a ice idea.

Cheers,
Frank

Hi Frank,

I think Thomas' idea of adding those that are not fundamental types to
the secondary list is the right thing, they get highlighted as types
not keywords and as you say the common ones are then available.  Best
of both worlds :).

I think all the ones that were originally in the list were fundamental
in C++11, so its only the new ones IIUC.




My idea was adding *all* types to secondary. Why differentiate between 
fundamental/needs header and others? The important point is they are 
types and not keywords.


Best regards.
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel


Re: [Geany-devel] [geany/geany] 795ee4: Merge pull request #28 from RetroX/patch-1

2012-02-24 Thread Thomas Martitz

Am 24.02.2012 23:34, schrieb Lex Trotman:

I don't agree with this change, the types are just that, types, not
keywords, they should not be highlighted as keywords.  They are not
always available.  This change should be reverted.



The list contained types before the commit and the commit just added 
more for completeness.


I suggest using the secondary for types instead.

Best regards.
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel


Re: [Geany-devel] Plugins Guidance

2012-02-21 Thread Thomas Martitz

Am 21.02.2012 05:15, schrieb Lex Trotman:

2. don't spread menu items through the Geany menus, users don't know
where to look and if several plugins add things to the same place the
menu may become unworkable.  You don't know what other plugins the
user will enable at the same time.




You don't propose a solution. What would be the correct place for menu 
items? Also I don't quite get what you're trying to say. You seem to say 
both, spreading menu items and adding them to the same place is 
unworkable, but that contradicts.


Best regards.
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel


Re: [Geany-devel] Opening unmounted GIO URIs

2012-02-04 Thread Thomas Martitz

Am 31.01.2012 01:30, schrieb Colomban Wendling:

Hey Nick, Matthew, Lex, Frank, Enrico, whoever cares,

https://github.com/b4n/geany/commit/01fd682674286dada6d6b77d0e3064c89a28df64




FWIW, I find it a strange feature for an IDE. While it provides 
conviniences, I'm not sure it should be core functionality. Perhaps a 
plugin would be a better fit?


Best regards.
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel


Re: [Geany-devel] Next version number

2012-01-09 Thread Thomas Martitz

Am 09.01.2012 02:26, schrieb Matthew Brush:

Hi,

This is regarding the change from v0.21-1.22 for the next release.

I totally agree that by now Geany has been long stable enough to have 
been in a 1.x series (or more) of releases, but I'm just wondering now 
about the jump. There's been some fairly majour and intensive changes 
since last release:


  - Complete re-write and cleanup of the highlighting/scintilla 
mappings code.

  - Switch to entirely GRegex/PCRE from old GNU regex.
  - Switch from Glade 2 generated code to Glade 3 / GtkBuilder XML.[1]
 - Translation changes for this
  - Massive changes to filetypes for color scheme support.
 - Default themes not compatible with existing filedefs.[2]
  - Lots of other stuff.

I think considering the massive amount of user-facing changes that 
have occurred in the last cycle that it might be misguided to jump to 
a 1.X version in declaration of being stable. I'd argue in fact that 
while there's been some really awesome improvements, we are far less 
stable than in previous versions.


Is that true? Does Geany really crash or show glitches _more_ often? Are 
there many regressions over 0.21? It's not like 0.21 is 100% stable. 
And, what's more important, can't the bugs be worked on until the release?




Since we haven't released with the new versioning scheme, IMHO, it 
would make sense to jump to something like 0.98/0.99 in preparation 
for the next cycle, rather than a whole 1.00.




IMO this many intensive and user visible changes make the 1.x even 
*more* justified.




[1] Don't under-estimate this, while 100% necessary, it's not just for 
the code changes which weren't really that big, but for the 
build-system changes, the added file dependency for the UI XML, the 
exporting of a bunch of new symbols (-Wl,--export-dynamic and 
G_MODULE_EXPORT) and interactions with plugins (there was recently a 
bug due to this in GeanyLatex)..


What do build system changes, dependencies and exported symbols have to 
do with the version number? These are not user visible and should affect 
the stability. As for plugins, well it's the plugins job to keep up with 
Geany development. I would dislike if Geany would take a step back/slow 
down just because the plugins aren't fixed in a timely manner. They're 
external and not part of the core for a reason.





[2] This is going to be a frequent bug/issue: My colours don't work. 
The answer is that they have a customized filetypes.* files overriding 
the newly mapped named styles and messing with highlighting. It's an 
awesome upgrade in functionality but I *guarantee* it will be a source 
of numerous bug reports.


Incompatibilities are not unusual for major version changes. In fact, 
they're many times the very reason for that. So I'd say this is one 
another reason to finally do the change to 1.x.



Conclusion: The list of changes speaks actually even more for doing 1.x. 
And the release isn't soon (is there actually a planned date) so 
remaining bugs can be fixed.


Best regards.
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel


Re: [Geany-devel] Geany-Plugins: MAINTAINERS file

2012-01-07 Thread Thomas Martitz

Am 07.01.2012 17:34, schrieb Eugene Arshinov:

Hi.

Here's xmlsnippets' maintainer info (e.g., mine)



I suggest you to use git format-patch, as to preserve author and commit 
message information. Probably not a big deal for this one though.


Best regards.

___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel


Re: [Geany-devel] Q: how to switch to new Git repo?

2012-01-06 Thread Thomas Martitz

Am 06.01.2012 16:32, schrieb Eugene Arshinov:

Hi guys!

It's me again, after a long time.  Please help me organize my Geany
repository.  The last time I worked on Geany it was in SVN repository,
and I was using it through git-svn.  Now there are two Git repositories:
the main one [1] and the one containing my sm-branch [2].  I assume I
should make the fork of the former and put my sm branch there, but how
do I transfer my sm branch, preserving merge commits (master -  sm)?

[1]: https://github.com/geany/geany
[2]: https://github.com/techee/sm-branch/





I don't think you can preserve merge commits. The history of the new git 
and the old git-svn repos are incomatible (e.g. the new history has 
proper author information) so they're meaningless anyway.


I suggest you rebase in the old repo and use patches to apply the 
changes to the new repo on the same revision/commit. Using 'git 
format-patch' and 'git am' you can preserve your non-merge commit 
history. Or just do 'git diff' for a single big patch,


Best regards.
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel


Re: [Geany-devel] Request: multithreaded tag generation?

2012-01-03 Thread Thomas Martitz

Am 03.01.2012 12:10, schrieb Lex Trotman:

I'm going to give up on Gproject and either try GeanyPRJ again or
ditch project support altogether. This simply doesn't work.


The standard Geany project support doesn't provide some of the nice
features of these plugins, but it also doesn't tag parse your whole
directory tree each startup, so performance should be ok.



Both plugins (IIRC) offer a check box to disable tag generation.

Best regards.
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel


Re: [Geany-devel] Replacing the control socket with dbus

2012-01-02 Thread Thomas Martitz

Am 01.01.2012 01:49, schrieb Matthew Brush:
As the others have said the two key issues here are 1) too new 
GTK/GLib version and 2) dependence on DBus which I'm going to guess 
isn't easily working and installable on Win32/OSX?


Isn't it GLib that has the dependency on DBus (to implement 
GApplication), not Geany?


Best regards.
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel


Re: [Geany-devel] Geany-Plugins: git repo up and running

2011-12-30 Thread Thomas Martitz

Am 19.12.2011 20:05, schrieb Frank Lanitz:


Well..

I would like to see process as I described. But as there have been a
lot of comments on I'm not sure whether its wished at all.




Well, it appears nobody strictly disagrees with this policy. So, I'd say 
it's up to you to enforce it.


Best regards.
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel


Re: [Geany-devel] GtkFileChooser recent annoyance

2011-12-20 Thread Thomas Martitz

Am 20.12.2011 05:07, schrieb Matthew Brush:

Hi,

Is anyone opposed to me committing the trivial patch attached here.  
The comment I think describes it well enough, and if you're using 
recent GTK+ 2.24.x you probably already know about it.


I didn't want to commit without asking since maybe some people will 
find this new feature[1][2] useful, I personally find it extremely 
annoying, but I wouldn't want to fix it at the expense of annoying 
others.


Cheers,
Matthew Brush 



I quite like that it starts in recently used. $HOME is never the right 
location to save for me, so I always need to click. And recently used is 
usually less clicks because the last folder in there.


You add in the comment that recently used is only one click away. 
However, the same can be said about $HOME.


Why is it so annoying to you? Do you often save in $HOME? Recently 
Used fixes an annoyance for me, and gnome page you linked describes it, 
that I save (accidentally) in $HOME.


Slightly related: How do you make the file chooser (when opening a file) 
hide filename entry by default? In gtk+3 there's a dconf setting for it, 
but I don't know for 2.x.


Best regards.
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel


Re: [Geany-devel] GtkFileChooser recent annoyance

2011-12-20 Thread Thomas Martitz

Am 21.12.2011 02:58, schrieb Matthew Brush:


And maybe add an hidden option in case ppl actually like the GTK 
feature?




It's actually a *GNOME* feature that crept into GTK+.  This seems to 
be a pattern lately that makes me very sad. I guess they think because 
their target users are idiots that everyone that uses GTK+ in their 
program has the same target users.


But it's in GTK, and it'll behave that way everywhere where GTK is, no? 
I.e. on non-Gnome DEs. So how's that a Gnome-only thing? Unless GTK has 
a if (gnome) {} code path?


Best regards.
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel


Re: [Geany-devel] Detachable Tab

2011-12-19 Thread Thomas Martitz

Am 19.12.2011 02:38, schrieb Lex Trotman:

On Mon, Dec 19, 2011 at 6:56 AM, Matthew Brushmbr...@codebrainz.ca  wrote:

On 12/18/2011 09:13 AM, David Gomes wrote:

Since I changed the name in the new_tab function of notebook.c, I expect
all notebooks in Geany to have been changed, because all are notebook.c
right?

And yes, I know set_id is not necessary in GTK 3, so I just put both lol.

I'm trying to achieve being able to send tabs from various geany
notebooks.


Hi,

If you dig around in the mailing list archive, you should be able to find a
patch I submitted that does exactly what you're trying to do. IIRC there
were two main problems, the first is that some code (might) expect that the
tab be in a specific notebook (I'm think more of plugins who add tabs here),
and the second was that we would need a way to save which tabs ended up
where when the program closes, otherwise everything would revert back when
you restart Geany.



Even if complicated to implement, I would love being able to have 2 or 
even 3 side bars with tabs draggable between them.


Best regards.
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel


Re: [Geany-devel] Geany-Plugins: git repo up and running

2011-12-18 Thread Thomas Martitz

Am 12.12.2011 14:54, schrieb Frank Lanitz:

Hi folks,

Just I case you missed the news inside the threads: the new git repo for
geany-plugins is online and can be found at
https://github.com/geany/geany-plugins




So, what is the policy for geany-plugins now?

Can everybody push to the master repo as it was with svn, or did we 
switch to the pull-style where Frank would pull changes from the 
maintainers repos (changes in the common part or the plugin for a release)?


Best regards
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel


Re: [Geany-devel] Just a stupid github question: How to merge a pull request with fast forward?

2011-12-13 Thread Thomas Martitz

Am 13.12.2011 09:24, schrieb Frank Lanitz:

Hi folks,

See question from subject line. How can I merge a pull request without
adding a new commit stating the merge? Is there some kind of ff or
cherry-pick available through front end?

Cheers,
Frank


It'll automatically fast-forward if it's possible. For that, the branch 
should be rebased onto the branch you merge into.


However, don't rebase other people work yourself.

Best regards.
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel


Re: [Geany-devel] Unit tests for Geany (continued from Github)

2011-11-30 Thread Thomas Martitz

Am 30.11.2011 08:39, schrieb Matthew Brush:

On 11/29/2011 11:12 PM, Frank Lanitz wrote:

Am 30.11.2011 07:36, schrieb Nathan Broadbent:

P.S. The documentation needs to be updated for the 'waf' build system,
in quite a few places, including geany-plugins.


I don't refer to other points as I would need to catch up discussion on
github before (wth why are we using differnt chanels? can we turn off
the github commenting stuff.. its a nightmare)



It's not a nightmare if you use it.  Comments are essential for code 
review, pull requests and useful for discussion of specific code. You 
can configure your Github notifications to email you just about 
everything and you can reply using your email client, if it's too much 
trouble bouncing between web browser and email client.



Can new comments on github (perhaps except line-specific ones) forwarded 
to this or a separate mailing list? Having to remember to always look at 
github as well is annoying.


Best regards.
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel


Re: [Geany-devel] --readonly handling

2011-11-17 Thread Thomas Martitz

Am 17.11.2011 19:20, schrieb Dimitar Zhekov:

Hi,

Is there any technical reason to check cl_options.readonly in
document.c, and clear it load_startup_files(), instead of simply
invoking document_open_file(filename, cl_options.readonly, ...) from
main_handle_filename()?



In an earlier version it also worked when opening a .geany file (so all 
session files would be opened readonly). As opening via socket also goes 
through main_handle_filename() (and hopefully nothing else?), I guess 
there's no real reason anymore.


Best regards.
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel


Re: [Geany-devel] Some sort of thoughts about geany-plugins-devel-git-repo

2011-11-16 Thread Thomas Martitz

Am 15.11.2011 17:55, schrieb Frank Lanitz:

We will have one master branch where all changes intended for releasing
are going in. Features and new plugins are going to be developed inside
branches (more late onto this topic) and once they are in a suitable
status, they are getting merged into master branch.
Release are generated from master branch and are getting marked with a
tag. If there is any need for some minor release as we had e.g. with
0.21.1 there will be a release branch that will include all patches
going in. If they are also needed to get applied on master, we can
cherry-pick them or find some other way of merging them back.



I like this proposal. Requiring pull requests will also formally mean 
get your plugin in shape before release. I'd like to extend this to 
the point that if a plugin is not ready (due to bad code, inactive 
maintainer, or otherwise) the snapshot from the previous release will be 
taken as to not lose functionality (this is in most cases automatic, 
since the merge didn't happen). I strongly advice against delaying 
releases for individual plugins.


However, there's one problem that isn't addressed, and I'm not sure it 
can be technically since it's more a cultural problem: There's IMO too 
little collaboration on plugins. It's kind of each plugin to its 
maintainer, with little to no collaborative effort to form the best and 
greatest plugins. It feels like the source is available but not really 
open. OTOH perhaps my perception is just wrong, and this cannot be fixed 
by technical measures anyway.



Regarding the ideas with separate repos/submodules: This basically 
breaks what the initial idea of geany-plugins was. To share 
infrastructure, build system and translations. The combined release 
idea came actually some time after that.


If the repos are separate and only merged for release, then they can 
just as well be separate entirely. So I disagree with that.They should 
be one repo, since they share a common code base via the translation and 
infrastructure.


Am 16.11.2011 07:12, schrieb Lex Trotman:

Although I am not a plugin developer I have a couple of suggestions
based on the following needs:

1. Individual plugin maintainers shouldn't care about all the other
plugins in the combined release


Not caring about other plugins is ok, but that doesn't mean his 
clone/checkout must not have other plugins.



2. Users getting the combined release to build should get everything
in one command


This is status quo, and should be kept, yes.


3. The combined release maintainers still need to be able to make
changes to each plugin in case of urgent bugfix and temporarily or
permanently missing individual plugin maintainer.


I agree.


4. Not all plugins are in the combined release, due to quality,
timing, or maintainer availability issues.  But users rely on plugins
so it is bad to remove their availability.


Covered by my suggestion to simply re-use the previous release.

Best regards.
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel


Re: [Geany-devel] Objective-C Support (was Highlighting setup refactoring?)

2011-11-10 Thread Thomas Martitz

Am 10.11.2011 05:06, schrieb Matthew Brush:

+++ b/tagmanager/objc.c
@@ -0,0 +1,1146 @@
+
+/*
+*   Copyright (c) 2010, Vincent Berthoux
+*
+*   This source code is released for free distribution under the terms of the
+*   GNU General Public License.
+*
+*   This module contains functions for generating tags for Objective C
+*   language files.
+*/
+/*
+*   INCLUDE FILES
+*/


The license is quite unclear. Also no standard disclaimer.

Best regards.


___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel


Re: [Geany-devel] Request: multithreaded tag generation?

2011-11-08 Thread Thomas Martitz

Am 08.11.2011 03:13, schrieb Lex Trotman:


Not so easy, from the sqlite faq:

(6) Is SQLite threadsafe?

 Threads are evil. Avoid them.

And what they don't mention is that you can deadlock your system if
the access isn't coordinated, ... back to square one.



They do mention though that SQLite is thread-safe, and that a db 
connection can be shared across threads. So your quote draws things 
worse than they are.


Doesn't Anjuta use SQLite? Are they using it multi-threaded?

Best regards.
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel


[Geany-devel] Fwd: Re: [Geany] A read-only command line option

2011-11-07 Thread Thomas Martitz

I figured this should probably moved to geany-devel.

Best regards.


 Original-Nachricht 
Betreff:Re: [Geany] A read-only command line option
Datum:  Thu, 03 Nov 2011 22:42:42 +0100
Von:Thomas Martitz thomas.mart...@student.htw-berlin.de
Antwort an: Geany general discussion list ge...@uvena.de
An: ge...@uvena.de



Am 06.03.2010 12:15, schrieb LUK ShunTim:

 Enrico Tröger wrote:

 On Thu, 4 Mar 2010 12:47:35 +1100, Lex wrote:

 Hi,


 I'd suggest the simplest solutions,

 --readonly applies to all files on the command line irrespective of
 positioning and has no effect on any other files opened by session or
 menu. This answers 1,2,3,4 (Note POSIX says it must be before any
 files but GNU allows anywhere)

 Current behaviour on attempting to re-open a file with different
 read-only status is that nothing happens, the already open file is
 raised but not changed.  I would leave this as is irrespective of
 method of second opening (cli or menu)
 This answers 5,6.

 I complete second this suggestion, not only because it would be simple
 to implement but also because it is simple to understand and so use.

 If there are no major objections, I'll implement this in the near
 future (whatever this means in terms of my limited spare time). Of
 course, if anyone is faster than me and posts a patch, that'd be much
 appreciated :).


 Regards,
 Enrico

 It'd be a nice-to-have, convenient enhancement. No hurry. Please take
 your time.



As I need it myself now, I implemented it. It was indeed relatively easy
to do. I've done it in the exact way as Lex suggested. You can find the
according pull request here: https://github.com/geany/geany/pull/11

Please feel free to comment, I hope I did it correctly. It seems to work
fine for me.

I didn't update the manual because I don't know how to do it.


On a related note: IMO the behavor of 5/6 should be changed in a
separate patch. Especially if you open from the command line, but also
with the file browser, you may get unwanted behavior (even data loss in
the extreme case) if you opened a file in read-only mode but it didn't
do it because it was already opened (I would switch to readonly for
non-readonly files, but not the other way around, i.e. play safe).

Best regards.
___
Geany mailing list
ge...@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany

___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel


Re: [Geany-devel] [RFC] Document Messages

2011-11-07 Thread Thomas Martitz

Am 07.11.2011 16:34, schrieb Colomban Wendling:

However, I'm not sure fallback to modal dialog is that good… let me
explain: a GtkInfoBar is a kind of non-intrusive messaging to the user,
where modal dialogs (or dialogs in general) is intrusive.  This means
one could easily ignore the info bar but not the dialog.



I assumed the editor widget would be frozen/set read-only until the info 
bar is processed by the user, so both seem intrusive.


OTOH the info bar would probably allow switching documents without doing 
anything which would solve a (for me) major annoyance with the modal 
dialog when ctrl-tabbing through docs. So not equally intrusive.


What solution can you suggest? I find the info bar superior and don't 
care about the fallback really.


Best regards.
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel


Re: [Geany-devel] Request: multithreaded tag generation?

2011-11-07 Thread Thomas Martitz

Am 07.11.2011 17:06, schrieb Colomban Wendling:

Hi,

Le 07/11/2011 16:35, Harold Aling a écrit :

Dear Geany Devs,

I recently switched from GeanyPRJ to Gproject. Since Gproject doesn't
support multiple open projects I have to switch between projects, but
it takes up to 4 minutes to close one project and open another. A
project consists of roughly 1000-2000 php-related files.

The Generate tags for all project files causes this massive delay,
but I really need that feature.

At work I have a 2-core CPU, where 1 is completely idle and on my
desktop at home there are 5 cores are doing nothing while generating
tags. Can't they be utilized to speed up the tag generation?

TL;DR: it's really not that easy.




Might or might not be related. It's rather annoying how long geany takes 
to load files. Fine for single files, but a session of (say) 50 ones 
takes a while And the situation on my end hasn't improved by buying an 
SSD, so I don't think it's I/O related, so suspect tagmanager.


Best regards.

Best regards
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel


Re: [Geany-devel] Request: multithreaded tag generation?

2011-11-07 Thread Thomas Martitz

Am 08.11.2011 02:44, schrieb Matthew Brush:


I suspect it's that TagManager, for every single tag, is inserting the 
tag into the tags array, removing duplicates, and then re-sorting the 
entire array.


Is it possible to fix that part,  i.e. sort/de-duplication after initial 
parsing (even if reading would be denied until that happened)?


Early geany+late tags is better than late geany+late tags, IMO.

Best regards.
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel


Re: [Geany-devel] Stub project files for sharing

2011-11-04 Thread Thomas Martitz

Am 03.11.2011 15:45, schrieb Nick Treleaven:


My solution:

A foo.geanystub project file goes in version control. It is never 
written to. It should be prepared by manually editing a copy of a 
local project file.


On opening a foo.geanystub file, Geany creates foo.geany in the same 
path then opens it.


When opening foo.geany, if foo.geanystub exists, then override 
settings with the stub contents.


This way the VC file can decide which settings are not overridable.

My solution shouldn't require much code to implement. I've only noted 
the bare bones of it, there are some things that could be added to 
make it better. Even with these I think it's simpler and neater.




That solution seems awkward to me. Especially the creation part where 
you need to copy, then hand-edit.


Normally you don't need to touch such project files at all, but you 
require not only that, but also that the people know which parts to take 
out.


Also, one could argue that foo.geany should override the stub file. 
Anyway this is a feature not covered by the separate-file approach.


So, it seems more complicated for users, since the separate-file 
approach would just work (no hand-editing required), so I disagree it's 
simpler. OTOH it's probably simpler to implement (just load the stub 
after, so things get overridden automagically) and 
backward-compatibility is not an issue.


Best regards.
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel


Re: [Geany-devel] Proposal: Project settings split

2011-11-02 Thread Thomas Martitz

Am 01.11.2011 23:39, schrieb Lex Trotman:


The point is to get the session file out of the project tree, so no
this defeats the purpose.



The point was to get the file list (i.e. what would be in that session 
file) out of VCS while keeping the project settings in.


This works with separate files even if in the same directory, since 
every reasonable VCS supports ignoring certain files (svn:ignore, 
.gitignore).


Best regards.
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel


Re: [Geany-devel] Proposal: Project settings split

2011-11-02 Thread Thomas Martitz

Am 02.11.2011 13:10, schrieb Lex Trotman:


Well, it comes down to how groups and individuals work, you may not
want to share projects settings, but I am part of groups who do.

Everything else is shared via VCS, so its annoying that one thing isn't.

Whats the problem with doing it?



Even if it's supported, people can chose to not share project settings 
by adding it to the ignore list. This way both is supported (which 
currently isn't the case).


Best regards.


___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel


Re: [Geany-devel] [RFC] Geany Plugin Names

2011-11-02 Thread Thomas Martitz

Am 02.11.2011 15:27, schrieb Johann SAUNIER:


I couldn't live without it either at work or at home.


It would be interesting to know which features you enjoy most. Perhaps 
gproject already offers them or can be extended.


Best regards.
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel


Re: [Geany-devel] Geany Plugins SVN Commit URLs

2011-11-01 Thread Thomas Martitz

Am 01.11.2011 14:11, schrieb Jiří Techet:

where command would be some sed expression which would substitute the
current format with the required format. Maybe a bit easier, still
something I don't want to spend my time on ;-). The only reason I
included the SVN metadata was the commit ID which is useful to have
because some commits refer to it in their comments and this
information would be lost otherwise.




I agree the commit url isn't terribly important, and even less under 
whose control the old svn repo since, you know, the history is there in 
that very git clone :)


Best regards.
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel


Re: [Geany-devel] GIT commit mails format

2011-10-25 Thread Thomas Martitz

Am 25.10.2011 01:23, schrieb Matthew Brush:
 I do like having the diffs in the mails normally, but I also don't 
much mind clicking a hyperlink to see a well coloured and laid out diff.


I'd actually prefer clicking+colored over in-mail.

OTOH I couldn't care less because I'm not subscribed to the (or any) 
commit mailing list so my opionion doesn't count :)


Best regards.
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel


Re: [Geany-devel] Geany is on Github

2011-10-07 Thread Thomas Martitz

Am 07.10.2011 17:28, schrieb Matthew Brush:

Hi all,

For the tl;dr crowd: https://github.com/geany



Really awesome work! I can't wait for the git switch!



Now, what we could do, for example, is to create another Team called 
Contributors or something, and this Team could have Pull only access 
(even without being in a team, anyone can still clone/pull).  Myself, 
I would probably go into the Contributors Team, since I contribute a 
fair bit, but I don't have commit access.


Man, give this man commit access already!

You've done so much invaluable work for this project, you well deserved it.



Another Team could be called Translators, and have one of the three 
levels of access control mentioned above, and it could be for all the 
Geany repositories, since translators likely work on both Geany and 
Geany-Plugins.  Another Team could be Newsletter Writers or 
something and they could have perhaps Push and Pull access on the 
newletters repository only.




Translators could have push access only to the directory where the 
translation files are in. But I dont think github can do this?




Comments, questions, and slander are welcome.  And don't forget to 
give me your Github usernames!




I don't think it's relevant, but you asked for it: kugel- :)

Best regards.
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel


Re: [Geany-devel] geany on github; why not?

2011-10-06 Thread Thomas Martitz

Am 06.10.2011 11:01, schrieb Jiří Techet:


Yeah, I have my .gitignore too. Anyway, I don't plan to make any
real commits during the conversion so it's easier to verify the
sources are in the same state as before (on the other hand, this could
really speed up the merging of my patches; I'm starting considering it
;-). I'd suggest it should be handled as an ordinary patch by the
maintainers after the conversion.



Speaking of which, would you be so kind to bring your patches in sync 
with svn head? I had major headaches trying to do it myself yesterday.


Best regards.
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel


Re: [Geany-devel] New Feature(plugin OR geany self)

2011-09-29 Thread Thomas Martitz

Am 29.09.2011 09:57, schrieb Jacques du Rand:

BottomLIne:
Almost like a MRU(Most Recently Use) Cache for the Open Document list
a which highlight/icon'ify the top 3-6  Documents in order ?

Your thoughts ?



This is already implemented, though not visualized in the side bar.

I don't remember if I use the default keybinding, but for me CTRL+TAB 
walks the MRU list of opened documents.


Best regards
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel


Re: [Geany-devel] New Feature(plugin OR geany self)

2011-09-29 Thread Thomas Martitz

Am 29.09.2011 10:13, schrieb Lex Trotman:

On 29 September 2011 18:03, Thomas Martitz
thomas.mart...@student.htw-berlin.de  wrote:

Am 29.09.2011 09:57, schrieb Jacques du Rand:

BottomLIne:
Almost like a MRU(Most Recently Use) Cache for the Open Document list
a which highlight/icon'ify the top 3-6  Documents in order ?

Your thoughts ?


This is already implemented, though not visualized in the side bar.

I don't remember if I use the default keybinding, but for me CTRL+TAB walks
the MRU list of opened documents.

I thought that too at first, but the MRU is ordered by open order, not
by activation order.



This is only true if you freshly started geany. It turns into an MRU of 
activated files afterwards (think of implicitely activating each file 
upon opening).


Best regards.
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel


Re: [Geany-devel] New Feature(plugin OR geany self)

2011-09-29 Thread Thomas Martitz

Am 29.09.2011 10:21, schrieb Lex Trotman:


Yes but after opening you can activate documents with the tabs without
reordering the MRU list.  The MRU list only re-orders when you use it
to activate documents. Of course maybe the MRU list should re-order on
any method of activation, including go to error tabs etc, thats open
for discussion.



I don't think I experienced that, but I almost exclusively use ctrl+tab 
to switch files. So if that's the case it's a bug and should be fixed.


FWIW, it appears this is a rather unknown feature, even though it's 
really awesome. Can discoverability of such features possibly be improved?


Best regards.
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel


Re: [Geany-devel] editing big files can be too slow with tag reparsing

2011-09-24 Thread Thomas Martitz

Am 24.09.2011 13:32, schrieb Lex Trotman:

Hi Colomban, Thomas,

I disagree, it is a bad idea to turn off a setting that changes the
behavior.  The user is likely to be confused by the unexpected change
in behavior (new symbols no longer in autocompletes, new types not
being highlighted etc).  Having it automagically turn off is bad.  At
most, pop up a dialog suggesting turning it off and noting where, but
only ever once per session.


I too think there should be a notification. But I think turning it of 
per-file (without touching the actual setting) is also good and the user 
will appreciate that.


Note that it would be turned off in the case symbol generation takes a 
long time, so it wouldn't go unnoticed if it's deactivated.




Colomban is right in trying to evaluate where Nicks problem is first,
thats far more likely to be productive, this sort of thing is the last
option not the first.



I agree.

Best regards.
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel


Re: [Geany-devel] AUTHORS THANKS files

2011-09-23 Thread Thomas Martitz

Am 23.09.2011 05:33, schrieb Matthew Brush:
On a similar topic, I noticed in the source files, on top of the 
license in the comments, some files list Nick and Enrico as the 
copyright holders, some also have Frank, others Colomban, and yet 
others Lex (and maybe others still).  It seems as though if you 
contribute significant portions of code to a file, you should add your 
own copyright blurb in the comments?  Would it not make more sense to 
have a single copyright holder for all files in the project, be it a 
person (ie. the current lead/maintainer), or an organization (ie. The 
Geany Software Foundation :)


Copyright assignment is seen as a bad thing generally. Why would you 
want to give up rights on your code?




Also, if someone contributes a significant amount of code to one or 
more files, does that mean they hand-over the copyright of that code 
to one (or maybe all?) of those people listed in the various file 
headers?


The reason I ask about the copyright thing is that I'm currently 
working on something that basically adds entirely new files and I 
wasn't sure if I should add my own copyright blurb in the fileheader 
or that of someone else.  It almost seems like currently the copyright 
blurbs in the file header comments are more like an Authorship or 
Attribution than copyright.


You should definitely do that. You own the copyright, and no other 
author. And code can't have no copyright holder (unless auto generated 
perhaps). And you should defintely add yourself for significant changes.




I think it might be useful to put some information about this in the 
HACKING file so that contributors clearly know whether to put their 
own copyright in the header, or if not, who's name/info to pass the 
copyright on to.  Also whether they should add their names to the 
AUTHORS file, or THANKS file, and whether they should update the 
ChangeLog (if that sticks around) and to update the documentation.  It 
also wouldn't hurt to mention in there that all of the submitted code 
will become/has to be GPL, just in case that's not clear.  We're 
coders after all, not law talkin guys.




It's implicitely GPL if you're editing GPL code. That's a) due to 
copyleft and b) patches generally don't relicense.


For new files it's actually up to you. You can submit it under GPL, or 
some other license. It's up to the committer to accept the license (or 
to relicense before submitting).


Best regards.
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel


Re: [Geany-devel] saving plugin settings in a project file

2011-09-23 Thread Thomas Martitz

Am 21.09.2011 18:01, schrieb Dimitar Zhekov:

On Wed, 21 Sep 2011 17:18:14 +0400
Alexander Petukhovde...@apetukhov.ru  wrote:


What I wanted was to have debug settings loaded at the same time I open
files I worked with last time. [...] but now I realize that I can store
debug settings for a session in plugins own config, where all other
plugin level stuff reside and if a user works with a project - store
debug settings in a project, [...]

What you need is debug sessions, and they depend on the executable being
debugged. It doesn't make sense to use the same breakpoints, watches
etc. for more than one program, or two sets of these for the same
program.


I disagree with the very last statement. If you're working at the same 
project in different branches you might want to debug different parts. 
And if you have a project/session file per branch then it even matches 
with debug sessions.




I think you can store the debug session settings in the plugin main and
only configuration file, with section names dependent on the full
executable name, for example it's md5 sum:

/home/build/projects/testing/geany -  [945b93c3fe68a0fe63ac6e8e528c59a5]
...settings...

/home/build/source/fnatools/fnstofna -
[1b216f36ac78dd903085214692c821cc]
...settings...

etc. Note that the projects sessions do not necessarily match the
debug sessions - for example, a project may produce several executable
files, and they will not share the same debugging session.



That's what I said in the other mail. I think debug sessions is 
overengineering it, adding complexity for little value.


Bes regards.
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel


Re: [Geany-devel] How about calling the next release 1.0?

2011-09-20 Thread Thomas Martitz
Am Di, 20.09.2011, 13:43 schrieb Lex Trotman:
 On 20 September 2011 21:23, Frank Lanitz fr...@frank.uvena.de wrote:
 Hi,

 Am 20.09.2011 12:07, schrieb Ji?í Techet:
 just one very quick and possibly stupid idea. How about getting rid of
 the 0 version prefix and calling the next release 1.0?

 To make it short: As we are about two weeks ahead of next release I
 disagree. After 0.21 release we got a lot of structural changes we might
 could think about a 1.0 too, but I don't feel its needed at the moment.

 I have to disagree with you on this Frank, the version number is
 nothing to do with structural or technical issues, it is a project
 issue.  Changing the version number doesn't affect translation or
 anything else that takes time to do, so it isn't going to delay the
 release.



I agree. There's no reason to wait until after the upcoming release. 1.0:
the earlier, the better.

This release should be the most stable one ever made, so 1.0 is even more
justified. 0.X simply isn't justified anymore. It sounds like Geany was
alpha software, but it has indeed better release quality that the majority
of software out there.

Best regards.

___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel


Re: [Geany-devel] saving plugin settings in a project file

2011-09-20 Thread Thomas Martitz

Am 19.09.2011 11:13, schrieb Lex Trotman:

On 19 September 2011 18:38, Alexander Petukhovde...@apetukhov.ru  wrote:

I would like to store debugger settings such as watches, breaks, target etc
in a project file.

These are not the settings that apply to a plugin in a whole but look like
being related to files
user is working with, i.e. a project.

The files a user is working with are not necessarily a project.
Especially for something as general as debugging it is important that
you also support workflows that don't involve having a project file
open (as well as ones that do of course).


Doesn't that mean another type of session is needed? a debug session?


I think it makes sense to tie debug stuff to projects. Doing it any 
other way probably means lots of extra work and maintainance effort, for 
a use-case the author doesn't even have.


Best regards.
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel


Re: [Geany-devel] Adding size_t before release

2011-09-15 Thread Thomas Martitz

Am 15.09.2011 02:39, schrieb Matthew Brush:


What I'd like to know is where is size_t defined?  According to what 
I've read, it's supposed to be in stddef.h but I can't find it 
anywhere in GNU libc downloaded the other day.




Should be (also) in string.h, since that's what strlen() returns.

Best regards.
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel


Re: [Geany-devel] SF.net SVN: geany:[5909] trunk/src/utils.c

2011-09-12 Thread Thomas Martitz

Am 12.09.2011 11:09, schrieb Lex Trotman:

On 12 September 2011 18:16, Frank Lanitzfr...@frank.uvena.de  wrote:

Am 11.09.2011 23:53, schrieb Colomban Wendling:

Le 11/09/2011 23:32, Lex Trotman a écrit :

[...]

What about adding chrome?

Yeah, why not (though this list is a fallback one), it's very easy now :)

We might then also want to add also Safari, Epihpany (GNOME) and Midori
(Xfce)... does anybody knows if safari runs Safari under MacOSX, or
what is the command name?

I disagree to add all known browsers to this list as they might appear.
Its still a fall back which means something didn't work before this list
has been called.

The thing that didn't work is the tool setting which defaults to firefox.

If we have any fallback at all then we should hake a reasonable job of
it, eg IIUC iceweasel is the debian project default browser not
firefox and debian is the basis of many more distros.


Yes, and calling Firefox Firefox is one of the reasons for those distros 
to fork debian :)


Since iceweasel is a pure debian thing, it should perhaps the 
responsibility of the debian package maintainer to add iceweasel.



Given the rate bugs get found in browsers I wouldn't want to
unexpectedly run an old un-updated browser, thats a real risk.


I think that's a bit exaggerated.

Best regards.
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel


Re: [Geany-devel] SF.net SVN: geany:[5909] trunk/src/utils.c

2011-09-12 Thread Thomas Martitz

Bringing this back to geany-devel.

Am 12.09.2011 11:23, schrieb Lex Trotman:

Hi Thomas,

[...]

Yes, and calling Firefox Firefox is one of the reasons for those distros to
fork debian :)

Since iceweasel is a pure debian thing, it should perhaps the responsibility
of the debian package maintainer to add iceweasel.

Then we should add this to the distro packaging instructions and tell
them where to change the hardcoded tools prefs default as well.


Given the rate bugs get found in browsers I wouldn't want to
unexpectedly run an old un-updated browser, thats a real risk.

I think that's a bit exaggerated.

So you are happy to keep using the compromised CAs then, since updates
only just removed them? Gee, I've got just the web page for you to
type your banking details into ;-)



No, but this is not Geany's concern.

Best regards.
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel


Re: [Geany-devel] geany on github; why not?

2011-08-29 Thread Thomas Martitz

Am 28.08.2011 23:33, schrieb Jiří Techet:

On Sat, Aug 27, 2011 at 20:50, Frank Lanitzfr...@frank.uvena.de  wrote:
So I suggest this: Jiri can you help to do so (or does maybe the 
github svn clone tools does this correct?) we surely can also offer 
something like that from git.geany.org. But here import is needed FMPOV. 

I could, but it needs some manual work and I'd like to do it just
before the switch because I'm not sure if I could easily add  the
commits (commits on different branches and especially merges) you do
between now and the switch. I was too missing a few committer names -
see the original email here

http://lists.uvena.de/geany-devel/2010-June/002672.html

which I'd need to get first before performing the conversion.



I could also ask the one that successfully converted our Rockbox svn 
repo to git, including proper branch, tag and author conversion, to 
write up the steps it needed. I think it was less than a day of work for 
him (and the Rockbox tree and history is considerably larger and more 
complicated than Geany's).


Best regards.
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel


Re: [Geany-devel] Use of Scintilla word boundaries for word searches

2011-08-22 Thread Thomas Martitz

Am 19.08.2011 18:10, schrieb Colomban Wendling:

Hi,


Just curious. How does search for whole words in find in files adds to 
this mix? IIUC it uses grep's -w option?


Best regards.
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel


Re: [Geany-devel] Use of Scintilla word boundaries for word searches

2011-08-22 Thread Thomas Martitz

Am 22.08.2011 12:59, schrieb Lex Trotman:

On 22 August 2011 20:14, Thomas Martitz
thomas.mart...@student.htw-berlin.de  wrote:

Just curious. How does search for whole words in find in files adds to this
mix? IIUC it uses grep's -w option?

Only in that it uses the same technique to select the default search
string, but you get the chance to edit it for FIF, you don't get the
chance for find usage, so find usage needs to be more correct or its
not useful.


Uhm, I mean for FIF grep decides about the word boundaries, which may be 
different to GEANY_WORDCHARS and everything discussed here, no?


Best regards.
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel


Re: [Geany-devel] Adding a list of filetypes into devel documentation?

2011-08-16 Thread Thomas Martitz

Am 16.08.2011 09:39, schrieb Frank Lanitz:



IIRC the theory is that ABI
changes don't require unchanged plugins to be recompiled (for example
if a structure is extended) but API changes require at least
recompile.  But I am not sure it is working that way though?

No. ABI changes need a recompilation while API don't necessary do.



Correct. ABI changes do need a recompilation. API changes need nothing.

Sometimes both the API and ABI break, and then you need changes in the 
source and of course a recompilation.


Extending a structure is ABI breakage if its size changes and the size 
is exposed (i.e. struct_ptr++ has a different effect in Geany and the 
plugin). That's why some projects pad structures to make extensions not 
change the size.


Best regards.
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel


Re: [Geany-devel] Adding a list of filetypes into devel documentation?

2011-08-16 Thread Thomas Martitz

Am 16.08.2011 15:04, schrieb Chow Loong Jin:


Sorry, I didn't read the second paragraph properly. I don't really see what kind
of change a purely API change (without changing ABI) would be, though.



Most importantly: Adding a function to end of the table of API 
functions. All existing plugins continue to work without changes or 
recompilation.


(This does change the size of that table, but plugins don't allocate 
that table and it's singleton, and therefore don't care about its size, 
so it's not considered an ABI change)


Changing the name of a function without changing the signature or 
changing the return value from int to short or so are pure API changes.


Best regards.
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel


Re: [Geany-devel] msgwin line and column position [was: Expose yellow wavy line in GeanyIndicators]

2011-08-14 Thread Thomas Martitz

Am 14.08.2011 06:27, schrieb Lex Trotman:

[..]

FIF will have to ask grep to mark the match(s) on the line and parse
them for character positions to be selected

That can be a bit tricky. -o -b returns what we need, but the normal
output is be lost, while --color=always will do, but the parsing is a
bit more complex, and we should invoke grep with a GREP_COLORS prefix.
Both assume GNU grep, of course.

Yes, I was thinking of (ab)using the colour markings for this purpose,
but we have already had problems with non-gnu grep, so maybe leave
this until later.


Perhaps just include gnu grep with geany if we're in fact depend on it?


What I meant is that focusing the window is not much use if the cursor
position is going to be start of line, since I have to click in the
window anyway to position the cursor (unless it happens that I want
something close to the start). [...]

I get it now. FIF / Find Usage will certainly be better with line and
column positioning, including Enter / double-click. Maybe implement that
for the Compiler tab first? Looks easy, once I find where is the default
error_regex. Huh.


Erm... looks easy? which compiler are you using that gives a column position?

GCC just gives a line number vaguely in the region that it sorta
guesses is the error ;-D



My gcc gives columns as well:
test.c: In function ‘main’:
test.c:13:2: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ 
before ‘return’


Perhaps a more recent feature.


Cheers
Lex
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel


___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel


Re: [Geany-devel] Me, Geany and the future

2011-08-11 Thread Thomas Martitz

Am 10.08.2011 23:38, schrieb Colomban Wendling:

Well, well, well... I thought a bit about it, and I think I'll accept
the position if others do.  The problem for me is that, ATM, I don't
have great plans for Geany's future -- meaning I don't know what I think
should be added, changed or greatly improved in Geany in the near future.



Perhaps focusing on the recent initiative for plugin API bindings for 
other languages than C, and hoping to get more contributions through 
plugins could be one way to go.


Best regards.
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel


[Geany-devel] geany-plugins waf install is slow

2011-07-17 Thread Thomas Martitz

Hello folks,

has the waf install step gotten very slow for everyone, or only for me?

It takes 36s or longer here, and this laptop has an SSD.

I attach the output of the install step.

Best regards.
Waf: Entering directory `/home/kugel/sources/geany-plugins/geany-plugins/_build_'
- install /usr/local/share/doc/geany-plugins/addons/AUTHORS (from addons/AUTHORS)
+ install /usr/local/share/doc/geany-plugins/addons/ChangeLog (from addons/ChangeLog)
- install /usr/local/share/doc/geany-plugins/addons/COPYING (from addons/COPYING)
- install /usr/local/share/doc/geany-plugins/addons/NEWS (from addons/NEWS)
- install /usr/local/share/doc/geany-plugins/addons/README (from addons/README)
- install /usr/local/share/doc/geany-plugins/codenav/ChangeLog (from codenav/ChangeLog)
- install /usr/local/share/doc/geany-plugins/codenav/AUTHORS (from codenav/AUTHORS)
- install /usr/local/share/doc/geany-plugins/codenav/COPYING (from codenav/COPYING)
- install /usr/local/share/doc/geany-plugins/codenav/README (from codenav/README)
- install /usr/local/share/doc/geany-plugins/codenav/NEWS (from codenav/NEWS)
+ install /usr/local/share/doc/geany-plugins/debugger/AUTHORS (from debugger/AUTHORS)
+ install /usr/local/share/doc/geany-plugins/debugger/ChangeLog (from debugger/ChangeLog)
+ install /usr/local/share/doc/geany-plugins/debugger/NEWS (from debugger/NEWS)
+ install /usr/local/share/doc/geany-plugins/debugger/COPYING (from debugger/COPYING)
+ install /usr/local/share/doc/geany-plugins/debugger/THANKS (from debugger/THANKS)
+ install /usr/local/share/doc/geany-plugins/debugger/README (from debugger/README)
+ install /usr/local/share/doc/geany-plugins/debugger/TODO (from debugger/TODO)
+ install /usr/local/share/doc/geany-plugins/devhelp/AUTHORS (from devhelp/AUTHORS)
- install /usr/local/share/doc/geany-plugins/devhelp/ChangeLog (from devhelp/ChangeLog)
+ install /usr/local/share/doc/geany-plugins/devhelp/COPYING (from devhelp/COPYING)
- install /usr/local/share/doc/geany-plugins/devhelp/NEWS (from devhelp/NEWS)
+ install /usr/local/share/doc/geany-plugins/devhelp/README (from devhelp/README)
- install /usr/local/share/doc/geany-plugins/geanycfp/AUTHORS (from geanycfp/AUTHORS)
- install /usr/local/share/doc/geany-plugins/geanycfp/ChangeLog (from geanycfp/ChangeLog)
- install /usr/local/share/doc/geany-plugins/geanycfp/COPYING (from geanycfp/COPYING)
- install /usr/local/share/doc/geany-plugins/geanycfp/NEWS (from geanycfp/NEWS)
- install /usr/local/share/doc/geany-plugins/geanycfp/README (from geanycfp/README)
- install /usr/local/share/doc/geany-plugins/geanydoc/AUTHORS (from geanydoc/AUTHORS)
- install /usr/local/share/doc/geany-plugins/geanydoc/ChangeLog (from geanydoc/ChangeLog)
- install /usr/local/share/doc/geany-plugins/geanydoc/COPYING (from geanydoc/COPYING)
- install /usr/local/share/doc/geany-plugins/geanydoc/NEWS (from geanydoc/NEWS)
- install /usr/local/share/doc/geany-plugins/geanydoc/README (from geanydoc/README)
- install /usr/local/share/doc/geany-plugins/geanydoc/THANKS (from geanydoc/THANKS)
- install /usr/local/share/doc/geany-plugins/geanyextrasel/AUTHORS (from geanyextrasel/AUTHORS)
- install /usr/local/share/doc/geany-plugins/geanyextrasel/ChangeLog (from geanyextrasel/ChangeLog)
- install /usr/local/share/doc/geany-plugins/geanyextrasel/COPYING (from geanyextrasel/COPYING)
- install /usr/local/share/doc/geany-plugins/geanyextrasel/NEWS (from geanyextrasel/NEWS)
- install /usr/local/share/doc/geany-plugins/geanyextrasel/README (from geanyextrasel/README)
- install /usr/local/share/doc/geany-plugins/geanygdb/ChangeLog (from geanygdb/ChangeLog)
- install /usr/local/share/doc/geany-plugins/geanygdb/AUTHORS (from geanygdb/AUTHORS)
- install /usr/local/share/doc/geany-plugins/geanygdb/COPYING (from geanygdb/COPYING)
- install /usr/local/share/doc/geany-plugins/geanygdb/NEWS (from geanygdb/NEWS)
- install /usr/local/share/doc/geany-plugins/geanygdb/README (from geanygdb/README)
- install /usr/local/share/doc/geany-plugins/geanygdb/THANKS (from geanygdb/THANKS)
- install /usr/local/share/doc/geany-plugins/geanygdb/TODO (from geanygdb/TODO)
- install /usr/local/share/doc/geany-plugins/geanyinsertnum/AUTHORS (from geanyinsertnum/AUTHORS)
- install /usr/local/share/doc/geany-plugins/geanyinsertnum/ChangeLog (from geanyinsertnum/ChangeLog)
- install /usr/local/share/doc/geany-plugins/geanyinsertnum/NEWS (from geanyinsertnum/NEWS)
- install /usr/local/share/doc/geany-plugins/geanyinsertnum/COPYING (from geanyinsertnum/COPYING)
- install /usr/local/share/doc/geany-plugins/geanyinsertnum/README (from geanyinsertnum/README)
- install /usr/local/share/doc/geany-plugins/geanylatex/AUTHORS (from geanylatex/AUTHORS)
+ install /usr/local/share/doc/geany-plugins/geanylatex/ChangeLog (from geanylatex/ChangeLog)
- install /usr/local/share/doc/geany-plugins/geanylatex/COPYING (from geanylatex/COPYING)
- install /usr/local/share/doc/geany-plugins/geanylatex/NEWS (from geanylatex/NEWS)
- install 

Re: [Geany-devel] geany-plugins waf install is slow

2011-07-17 Thread Thomas Martitz

Am 17.07.2011 13:34, schrieb Frank Lanitz:

On Sun, 17 Jul 2011 10:42:43 +0200
Thomas Martitzthomas.mart...@student.htw-berlin.de  wrote:


has the waf install step gotten very slow for everyone, or only for
me?

It takes 36s or longer here, and this laptop has an SSD.

Well, I don't think this is caused by waf itself. How do other
IO-actions, in special write actions, perform on your box?


Very well, as you'd except from an SSD. Throughput is ~160MB/s when writing.


BTW: Installing took 3.4s here


Seems to be limited to my system, then. Very strange.

Best regards.
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel


Re: [Geany-devel] Patch Tracker

2011-06-10 Thread Thomas Martitz

Am 10.06.2011 02:09, schrieb Matthew Brush:

On 06/09/11 10:40, Thomas Martitz wrote:

Am 27.05.2011 23:31, schrieb Matthew Brush:

Hi,

Would it be useful for someone with admin rights on SourceForge.net to
create a Patch Tracker? I've seen some projects with this[1].


We, at Rockbox, are in the process of abandoning our patch tracker.
Because it has grown to host over 400 patches, nice ones as well as bad
ones, which nobody looks at.

We made the following observation after years with a patch tracker. If
core developers are rare or lack time or can't otherwise regularly look
at the patches (which is the case for Geany too), it will become a place
to let patches rot.
The problem is that a patch tracker creates the idea that once a patch
is uploaded the project is responsible for them and not the contributor.
This means the contributor is less motivated to work on the patch to
make it committable or to pester developers.

The way I see it is that a patch tracker will not work for Geany.


So it's better to let them rot in the (non-searchable) archives of a 
mailing list? 


No it's not (in our experience anyway), since the possibility of getting 
lost in the mailing list motivates the contributors to regularly bring 
up the patches again and remind core developers. This doesn't happen on 
a patch tracker, but is happening right now on the mailing list.


It's at least a bit better than the current situation, since it's 
easier for a core developer to see a list of outstanding patches in 
one page, and people down the road can see the patches and update them 
to work with newer versions later if they get forgotten.


Unless the patch tracker lives long enough to grow to a couple (say 50) 
patches in which case patches not clearly represented anymore and it's 
de-motivating to even look at the patch tracker, let alone individual 
patches.




Of course, like you said, if nobody looks at it ever, it's still 
pretty useless.


Additionally, if the contributor is not motivated enough to bring up 
patches again and again then neither the maling list or patch tracker 
help. In this case it's simply the contributors fault.


Best regards.

___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel


Re: [Geany-devel] Patch Tracker

2011-06-09 Thread Thomas Martitz

Am 27.05.2011 23:31, schrieb Matthew Brush:

Hi,

Would it be useful for someone with admin rights on SourceForge.net to 
create a Patch Tracker?  I've seen some projects with this[1].


We, at Rockbox, are in the process of abandoning our patch tracker. 
Because it has grown to host over 400 patches, nice ones as well as bad 
ones, which nobody looks at.


We made the following observation after years with a patch tracker. If 
core developers are rare or lack time or can't otherwise regularly look 
at the patches (which is the case for Geany too), it will become a place 
to let patches rot.
The problem is that a patch tracker creates the idea that once a patch 
is uploaded the project is responsible for them and not the contributor. 
This means the contributor is less motivated to work on the patch to 
make it committable or to pester developers.


The way I see it is that a patch tracker will not work for Geany.

Best regards.
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel


Re: [Geany-devel] Build System User Guide

2011-05-18 Thread Thomas Martitz

I'm wondering why this shouldn't be part of the official manual?

I disagree that information about Geany's core features should be at 
different places.


Best regards.
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel


Re: [Geany-devel] Fix crash and memory leak in treeviewer.c.

2011-05-12 Thread Thomas Martitz

Am 02.05.2011 17:38, schrieb Thomas Martitz:

Here's the patch.



Hmm, no answer from the maintainer or anyone whatsoever. Is it OK if I 
commit it myself?


Best regards.
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel


Re: [Geany-devel] Fix crash and memory leak in treebrowser.c.

2011-05-12 Thread Thomas Martitz

Am 12.05.2011 20:32, schrieb Colomban Wendling:

The patch looks OK to me, but I wouldn't commit to a plugin without the
author's agreement.


Which is why I posted it here in the first place :) I'll wait a bit 
longer and deactivate the plugin in the meantime.



Anyway, you seem to have confused treeviewer and treebrowser in your
mail/patch titles, maybe it's not really good for visibility?



*Ooops* /me changes topic

Best regards.
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel


Re: [Geany-devel] Colorschemes/geany-themes branch

2011-05-03 Thread Thomas Martitz

Am 28.04.2011 10:06, schrieb Matthew Brush:

Hi,

I started working on merging geany-themes project into the Geany tree, 
as well as a few fixups to the Colorschemes menu, some of which are 
same as patches sent to the mailing list some time ago.  Mostly left 
is cleaning up themes that cause warnings on geany verbose output and 
to test the themes with more lexers.



Perhaps it should stay a separate project/repository. This is mostly 
about artwork, the potential contributors are different people than the 
ones who contribute code to Geany.



Best regards.
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel


Re: [Geany-devel] Git Switch (again)

2011-05-02 Thread Thomas Martitz

Am 02.05.2011 03:33, schrieb Matthew Brush:



[1] https://github.com/blog/626-announcing-svn-support
[2] https://github.com/blog/644-subversion-write-support



Ah, that was what I was asking for in my other mail. However, it seems 
not very ideal for SVN users.


Best regards.
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel


[Geany-devel] Fix crash and memory leak in treeviewer.c.

2011-05-02 Thread Thomas Martitz
In path_is_in_dir(), if it's about to return NULL (if the function 
parameters

have no path components in common) it tried to free() a string
literal, which causes a crash. In the same function, there was a memory 
leak,

because diffed_path was reassigned without being free()'d before.

Fix both problems.

___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel


Re: [Geany-devel] Fix crash and memory leak in treeviewer.c.

2011-05-02 Thread Thomas Martitz

Here's the patch.
From 6376d5c6c7d1ea1832bd7f427dc03e0bb5103f50 Mon Sep 17 00:00:00 2001
From: Thomas Martitz thomas.mart...@student.htw-berlin.de
Date: Mon, 2 May 2011 17:33:40 +0200
Subject: [PATCH] Fix crash and memory leak in treeviewer.c.

In path_is_in_dir(), if it's about to return NULL (if the function parameters
have no path components in common) it tried to free() a string
literal, which causes a crash. In the same function, there was a memory leak,
because diffed_path was reassigned without being free()'d before.

Fix both problems.
---
 geany-plugins/treebrowser/src/treebrowser.c |9 ++---
 1 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/geany-plugins/treebrowser/src/treebrowser.c b/geany-plugins/treebrowser/src/treebrowser.c
index 93ee0b4..b2b1b4b 100644
--- a/geany-plugins/treebrowser/src/treebrowser.c
+++ b/geany-plugins/treebrowser/src/treebrowser.c
@@ -222,13 +222,15 @@ utils_pixbuf_from_path(gchar *path)
 #endif
 }
 
+
+/* result must be freed */
 static gchar*
 path_is_in_dir(gchar* src, gchar* find)
 {
 	int i = 0;
 
 	gboolean found = FALSE;
-	gchar *diffed_path = , *tmp = NULL;
+	gchar *diffed_path = NULL, *tmp = NULL;
 	gchar **src_segments = NULL, **find_segments = NULL;
 	guint src_segments_n = 0, find_segments_n = 0, n = 0;
 
@@ -247,7 +249,9 @@ path_is_in_dir(gchar* src, gchar* find)
 			break;
 		else
 		{
-			tmp = g_strconcat(diffed_path, G_DIR_SEPARATOR_S, find_segments[i], NULL);
+			tmp = g_strconcat(diffed_path == NULL ?  : diffed_path,
+G_DIR_SEPARATOR_S, find_segments[i], NULL);
+			g_free(diffed_path);
 			diffed_path = g_strdup(tmp);
 			g_free(tmp);
 			found = TRUE;
@@ -258,7 +262,6 @@ path_is_in_dir(gchar* src, gchar* find)
 
 	if (found)
 		return diffed_path;
-	g_free(diffed_path);
 	return NULL;
 }
 
-- 
1.7.4.1

___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel


Re: [Geany-devel] Git Switch (again)

2011-05-01 Thread Thomas Martitz

Am 30.04.2011 11:52, schrieb Enrico Tröger:


But we have git.geany.org.
The mirror GIT repositories are synced from SVN and the sync is
triggered by commit mails.

So, we do have a kind of our own commit hook, from SVN as well as from
GIT. I just don't know what I should do in the hook :).




Assuming the current git mirror does git svn rebase upon the hook, you 
could extend the script to do the git push afterwards (according to 
Jiri's [1] command).


You need an intermediate git mirror which does the svn rebase anyway, I 
don't think github can offer that, but it doesn't necessarily need to be 
publicly available.


[1]: is it OK if I write your name that way? I don't know how to enter 
the characters on the keyboard. If not, I'm sorry.


Best regards.
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel


Re: [Geany-devel] GProject - missing Geany patches

2011-05-01 Thread Thomas Martitz

Am 02.05.2011 00:03, schrieb Jiří Techet:


I've tested it and my plugin works with mainline geany now - great!
I'll need one more thing - to bump the plugin API version number. Even
though the API hasn't changed, people shouldn't use my plugin with
previous versions of geany (it wouldn't work because they couldn't
specify the patterns).


Doesn't that mean the API actually changed? :)

Best regards.
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel


Re: [Geany-devel] GObject, new plugin interface .... Vala bindings

2011-04-29 Thread Thomas Martitz

Am 29.04.2011 19:12, schrieb Nick Treleaven:


I think this is great. It might be doable to maintain this with Geany's
API when ready. This would be a big leap forward for plugin writers,
and little/no impact on the existing API.



Will Geany's API ever be ready? I doubt so, especially at this 
development rate.

But this vala bindings are great for sure.


do discuss any further I'd like to point to an email Enrico sent
earlier this year onto this list:

http://lists.uvena.de/geany-devel/2011-February/003905.html

Originally Geany wasn't designed/coded to work with GObject. Moving to
an plugin interface using this would most likely cause rewriting of a
lot of code. However, if really somebody of you like to go this
further I suggest to start a new branch where all changes can be
tracked in.
But before we can discuss about the positive/negativ points I just
want to ask who likes to take over this task as a kind of lead
engineer and project manager to be the lead here having in mind it will
most likely not a 5-minute-task?

What's the outcome here? I saw a lot of technical discussion followed up
by my original posting but nobody took over the rule to bring all the
idea into synch. Not sure whether I might did miss something.

Just to add my point of view:

1. I think this would be very disruptive to both Geany's core and
existing plugins. I also really don't like GObject code in C.


Wasn't the idea to implement the GObject interface one by one, 
maintaining the current one in the meantime (and a bit after)? You can 
also always do compatibility magic with cpp or some sort. I don't see it 
disruptive for plugin writers.



2. Would it actually work? Geany is not a shared library, so this
might cause problems for dynamic language bindings. Until this and
perhaps other issues are dealt with, we should not start on using
GObject IMO. (To prove dynamic bindings would be possible, a minimal
binding for the current API could be made).


It works for all other the programs (e.g. gedit) too, doesn't it?


I don't hope you just killed all hope with your mail, we basically 
already agreed this would be a nice thing to have, no?


Best regards.
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel


Re: [Geany-devel] {datetime} {date} are updated only after config reload

2011-04-23 Thread Thomas Martitz

Am 23.04.2011 22:37, schrieb Liviu Andronic:

Right, distclean! I only fancied make clean. Now it worked.

The {datetime}  {date} templates seem to be updated, as expected,
upon inserting. Thanks!
Liviu



That make clean worked was would have been my expecation too. Is 
something wrong with the build system?


Best regards.

___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel


[Geany-devel] Scope (struct/class) completion broken

2011-04-18 Thread Thomas Martitz

Hello,

I just tried my patch again to make scope completion work better (see 
r4840), but I now noticed that scope completion doesn't work at all anymore.


tm_workspace_find() in autocomplete_scope() in editor.c returns NULL. I 
didn't investigate further. Could the recent tagmanager changes have 
caused this?


Best regards.
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel


Re: [Geany-devel] Scope (struct/class) completion broken

2011-04-18 Thread Thomas Martitz

Am 18.04.2011 15:04, schrieb Thomas Martitz:

Hello,

I just tried my patch again to make scope completion work better (see 
r4840), but I now noticed that scope completion doesn't work at all 
anymore.


Just for completeness. My way to open the scope completion list was (in 
this case) to type editor- or editor. in e.g. autocomplete_scope().


Best regards.
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel


Re: [Geany-devel] Scope (struct/class) completion broken

2011-04-18 Thread Thomas Martitz

Am 18.04.2011 15:26, schrieb Colomban Wendling:

Hi,

Le 18/04/2011 15:17, Thomas Martitz a écrit :

Am 18.04.2011 15:04, schrieb Thomas Martitz:

Hello,

I just tried my patch again to make scope completion work better (see
r4840), but I now noticed that scope completion doesn't work at all
anymore.

Just for completeness. My way to open the scope completion list was (in
this case) to type editor- or editor. in e.g. autocomplete_scope().

It still works for me, and I'd be surprised it to be broken by recent
changes. Maybe r5642 would have broken this, but it has been reverted by
r5711 because it did actually broke calltips.

However, scope completion only works when the variable type is known,
e.g. with globals only.


Pretty sure it worked with locals also, but I may be wrong.

Anyway, I tried it with something global and it doesn't work too. In 
editor.c, no list at all with editor_prefs, and a wrong list with 
editor_info.


Best regards.
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel


Re: [Geany-devel] Scope (struct/class) completion broken

2011-04-18 Thread Thomas Martitz

Am 18.04.2011 19:12, schrieb Colomban Wendling:

Le 18/04/2011 15:38, Thomas Martitz a écrit :

Am 18.04.2011 15:26, schrieb Colomban Wendling:

Hi,

Le 18/04/2011 15:17, Thomas Martitz a écrit :

Am 18.04.2011 15:04, schrieb Thomas Martitz:

Hello,

I just tried my patch again to make scope completion work better (see
r4840), but I now noticed that scope completion doesn't work at all
anymore.

Just for completeness. My way to open the scope completion list was (in
this case) to type editor- or editor. in e.g. autocomplete_scope().

It still works for me, and I'd be surprised it to be broken by recent
changes. Maybe r5642 would have broken this, but it has been reverted by
r5711 because it did actually broke calltips.

However, scope completion only works when the variable type is known,
e.g. with globals only.

Pretty sure it worked with locals also, but I may be wrong.

Since all completions, including scope ones, are based on tags, and we
never had local tags parsed AFAIK, I'm pretty sure it never worked. But
I'd be happy to be proven wrong :)


Nah, I suspect my memory is just wrong. It's been a long time since I 
paid attention to scope completion.


Best regards.
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel


Re: [Geany-devel] SF.net SVN: geany:[5724] trunk

2011-04-17 Thread Thomas Martitz

Am 17.04.2011 13:13, schrieb Lex Trotman:

I can completely understand the problem, I have a similar MAJOR
annoyance with Python, anything on the end of the line that is a
prefix of a completion gets the first completion chosen when return is
typed to end the line.  This doesn't happen in C or C++ since rarely
do lines end in a word, they mostly end in punctuation.

But for other languages the choice of return to select the item from
the completion list is inappropriate.  I have been forced to turn
autocompletion off for Python, but that means remembering it since
there is only one preference, not a per language one.


I seem to remember it was possible to close the autocompletion list with 
escape at some time which solved that for me sufficiently, but I 
remapped escape ages ago. Now I tried it again it is not possible 
anymore, the cancel autocompletion keybinding actually inserts the 
selected item.


Best regards.
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel


Re: [Geany-devel] geany-newsletter: License of newsletter

2011-04-08 Thread Thomas Martitz

Am 08.04.2011 18:18, schrieb Frank Lanitz:

Hi people,

I just want to ask about which license we shall use for the newsletter
in future. I'd like to prefer to put it under terms of one of the
CC-family licenses. CC-BY (by = Geany Newsletter Team) would fit most
IMHO. What's your opinion?


I never heard of licenses for newsletters.

Best regards.
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel


Re: [Geany-devel] [ANN] Fork of Geany

2011-03-31 Thread Thomas Martitz


Lex Trotman ele...@gmail.com schrieb:

Dear All, I has become apparent that Geany has moved away from its roots as a 
lightweight, low overhead editor for small computers. It is therefore proposed 
to fork Geany to return to its roots and pursue alternate user communities. The 
intention of the fork will be to shrink Geany as small as possible to target 
the neglected niche of wearable computers. In support of this Geany will be 
adapted to operate off head mounted accelerometer inputs allowing user input by 
inclining of the head. The lack of screens will of course require voice output 
to be added as well. I do hope that many developers will join in this exciting 
and innovative development of : Whiny Teany Weany Beany Leany Geany. Cheers Lex 
1 April (AEDT)_
Geany-devel mailing list Geany-devel@uvena.de 
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel


Will it run on my phone as an app too? :-)

Best regards.___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel


Re: [Geany-devel] Split Window Patches

2011-03-27 Thread Thomas Martitz

On 28.03.2011 02:31, Matthew Brush wrote:


So after spending way too much time on this, and getting nowhere, I 
give up.  I'm attaching a patch that no dev is going to like because 
it behaves differently on Windows than it does on non-Windows to work 
around a know issue in GTK+ that is not documented to affect Windows 
differently than X windows.  Either someone else needs to find the 
root of the problem deep inside GTK+ (ie. why it reparenting only 
breaks on Windows), we figure out what's happening in Scintilla, we 
use the slightly hacky approach of behaving differently on Windows, or 
we just leave the whole plugin stay disable and let the Windows users 
not have it, even though we *can* make it working.  Since it's just a 
plugin, completely separate from the core code, which is already kinda 
hacky with what it's doing, my opinion is just to use the patch.


It's not my call, but the patch is here if you want it. 


I agree here. Your patch is a lot better than not working at all, 
isn't it?


Best regards.
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel


Re: [Geany-devel] Changes to templates

2011-03-16 Thread Thomas Martitz

On 16.03.2011 00:29, Lex Trotman wrote:



Fix filetypes.c to use /* */ style comments rather than C++ style
comments.

I'd personally agree with this change, but it has a drawback: multi-line
C comments can't be nested. So the comment/un-comment command becomes a
little less useful since it'd break if commenting stuff including
comments.

My Geany comments C code with // so nesting can be infinite and that
makes function headers as /* comments */ fine and works on C99 +
compilers and the inserted function headers work on all compilers.

When compilers won't let you use // to comment out blocks and you
can't nest /* comments */ then thats a limitation of that version of
the language and no matter what Geany does you will always have to
comment around other comments.

So I'd agree with Matthew that the built in functionality should
support the lowest common denominator.



FWIW, C99 is the current standard in effect, since more than a decade 
already, and thus //-style comments are perfectly valid. It's not 
Geany's fault if you can't use them.


For CTRL+E, it's user configurable even, isn't it? Then I see no 
problem. But defaulting to //-style seems sane because it's very 
annoying to work around the nested comment problem.


But for templates /* */-style should be used, I agree.

Best regards.
___
Geany-devel mailing list
Geany-devel@uvena.de
http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel


Re: [Geany-devel] Ideas on increasing quality of plugins

2011-03-13 Thread Thomas Martitz

On 11.03.2011 19:37, Colomban Wendling wrote:


Do you have objections, comment or whatever?



I largely agree with all of what Lex said.

* I routinely add temporary debug code without the proper headers 
(because I know it works) so making this break the build would be 
inconvinient for me (and perhaps other experienced programmers)

* I agree with more warnings, though, generally
* I think they should be in the build system. Having them on the 
developers site has only created problems before, such as new devs 
simply missing them

___
Geany-devel mailing list
Geany-devel@uvena.de
http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel


Re: [Geany-devel] Stil of mailing list

2011-03-13 Thread Thomas Martitz

I agree with Frank, I hate unecessary full quotes.


On 13.03.2011 03:43, Lex Trotman wrote:

Hi all,

I'd like to add a couple of points to Franks excellent comments

On 13 March 2011 05:18, Frank Lanitzfr...@frank.uvena.de  wrote:

Hi guys,

Please give me the chance to point to the world famous usenet quoting
howto at http://www.netmeister.org/news/learn2quote.html
We are here at an mailing list, but most of the rules apply here also.

This howto is very worthwhile, but one of the problems with this, and
many other lists, is that many people don't read the whole thread, so
if you cut all the old content out you are forcing them to reply
without all the background.  Of course leaving all the content in
makes the mailing much larger and its harder to find the new content.
To combat this learn to use your mailers quoted text hiding features,
and if it doesn't have them, switch to one that does.


That assumes that I read all through the full quotes. That's of course 
not the case because I would be reading the same stuff a dozen times. I 
try to ignore them (reading only the actual bits that people are 
replying to), but that means I painfully need to search for new content.


IMO it's up to the reader to make sure he's got all background.

Your mails are particularly hard to read, sorry Lex.

Best regards.


___
Geany-devel mailing list
Geany-devel@uvena.de
http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel


Re: [Geany-devel] Adding .gitignore files to geany-plugins

2011-03-10 Thread Thomas Martitz

On 10.03.2011 02:47, Matthew Brush wrote:
 I don't even understand why anyone would use the Git mirror over 
git-svn for development.


The Git mirror is git-svn :) Cloning the mirror saves you the lengthy 
procedure of cloning the svn repo via git-svn (because the mirror 
already did this).


After cloning the Git mirror you can just do:

$ git update-ref refs/remotes/git-svn origin/master
$ git svn init|https://geany.svn.sourceforge.net/svnroot/geany/trunk|
$ git svn fetch



Best regards.
___
Geany-devel mailing list
Geany-devel@uvena.de
http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel


Re: [Geany-devel] Adding .gitignore files to geany-plugins

2011-03-09 Thread Thomas Martitz

On 09.03.2011 20:05, Enrico Tröger wrote:


I use SVN, so I don't care much about a .gitignore (read: I'm
neutral).

I just would suggest, if we use a .gitignore as well (assuming replying
svn:ignore won't work as expected with GIT), keep the .gitignore
somewhat in sync with the svn:ignore content.



That's best accomplished by setting svn:ignore and generating .gitignore 
from it.


IIRC, if you clone a svn repo with git-svn then it even automatically 
does this (and puts the ignores into .git/info/exclude).


Best regards.
___
Geany-devel mailing list
Geany-devel@uvena.de
http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel


Re: [Geany-devel] Ideas on increasing quality of plugins

2011-03-09 Thread Thomas Martitz

On 10.03.2011 01:23, Lex Trotman wrote:

On 10 March 2011 00:45, Colomban Wendlinglists@herbesfolles.org  wrote:

Le 09/03/2011 05:31, Lex Trotman a écrit :

Hi Colomban,

Agree with most, comment on the rest below.

On 9 March 2011 14:00, Colomban Wendlinglists@herbesfolles.org  wrote:

Le 08/03/2011 22:29, Colomban Wendling a écrit :

Le 08/03/2011 19:58, Enrico Tröger a écrit :

On Tue, 08 Mar 2011 11:06:16 +0100, Frank wrote:


Am 23.02.2011 01:10, schrieb Matthew Brush:

For first thing, maybe we could enforce use/passing of those tools
mentioned and these before adding to release, examples:
http://www.splint.org/
http://valgrind.org/info/tools.html
(suppression for GTK -
http://people.gnome.org/~johan/gtk.suppression)
http://www.gnu.org/software/indent/ (just for making coding styles
more consistent between plugins) http://check.sourceforge.net/ or
http://cutest.sourceforge.net/ or http://cunit.sourceforge.net/
Perhaps some or all of these could be automated.

I don't suggest (yet) to use splint, because I haven't found it useful,
it reported ways too much things (and some was false positive) to be
really usable. However, I probably don't know how to configure it (and
haven't the time to find out yet), so if somebody with experience with
it can provide some hints, maybe we can add this too.

For Valgrind however, I doubt we can do anything automatically, because
it's a runtime checker, and its output must generally be read with some
care. Writing some sort of guidelines and howto is probably the way to go.


I like that idea. Can someone of you build up a howto on how to use it?
I did try valgrind in past and wished for some advice ;)

One this is done we can think of automatic tests with some of this
tools.

I, and obviously, Colomban as well, though indepdent from each other :D,
recently played[1,2] with cppcheck. A small tool for static code
analysis which actually found a few things in the geany-plugins
repository.

As I'm currently reworking the system to create the nightly builds, we
could integrate such checks into the nightly builds, maybe run cppcheck
on the sources after the builds and present the results somewhere on
nightly.geany.org.

I think it's a good idea.

I did a few checks, and this is what I suggest:
1) run cppcheck on `make check` and abort if it detects an error;
2) enable by default (though in a portable manner) some compiler flags
such as -Werror-implicit-function-declaration [1] [2]

After a little more thinking and testing, I suggest:

* -Werror=implicit-function-declaration (see above);
* -Werror=pointer-arith, to avoid portability issues with untyped
pointer arithmetic;
* -Wundef because preprocessor tests should rely on defined variables or
explicitly use ifdef;
* -Wshadow because shadowing symbols is a Bad Practice (and maybe it is
even non-standard, not quite sure however);

Agree for shadow of locals and parameters, agree for globals but only
because all globals should be prefixed by a module prefix like the
Geany_ symbols are.  Is there any way to check this?

Not that I know, unfortunately. However maybe a dumb sed/grep might do
the trick.


* -Waggregate-return because returning aggregate values is no good for
performances and it's not a Good Practice in C;

Why isn't it good?  Performance should be as good if not better than
returning multiple parameters via pointers and then assembling the
aggregate in the caller.  Why isn't it Good Practice?? (your caps :-)
Its been standard ever since someone invented allocating the return
variable on the stack prior to the call, so it can be referenced
relative to the frame pointer.

Well... I must admit I'm not really pro on the subject, but AFAIK the
main problem is ABI, because since the return value will not necessarily
fit in registers the compiler is likely to generate a dummy parameter to
the function (as you might have done yourself), but this implicitly, so
changing the natural ABI of the function.

Functions that return too much to fit in the registers should use the
stdcall ABI which defines an extra reference parameter for the
aggregate. (Or rather the compiler should use it).  There is no such
thing as a natural ABI that is corrupted by aggregate returns, there
are ABIs defined by Intel and other CPU makers for all the required
call/return patterns.  Yes its slower than returning something in a
register, but if you have got to return an aggregate value thats too
big you have to return it.  Might as well let the compiler do the
heavy lifting rather than having to declare a temporary and pass a
pointer to it as an explicit parameter or otherwise return the
components and assemble the aggregate in the caller.



Returning an aggregate is exactly the same as manually allocating the 
aggregate and passing a pointer to the function (in order to let it fill 
the aggregate) on most if not all ABIs. Without any difference in 
performance.


Of course the latter has the advantage that you can additionally return 

Re: [Geany-devel] Devhelp integration plugin

2011-03-08 Thread Thomas Martitz

On 08.03.2011 15:15, Frank Lanitz wrote:

Am 06.03.2011 14:01, schrieb Thomas Martitz:

Am 06.03.2011 13:36, schrieb Enrico Tröger:

2) Is it possible to continue using Git (on GitHub) and still commit
to geany-projects SVN at the same time (when code on Git is good
enough to go into the official Projects SVN)?  I'm pretty new with VCS

Why not.
I'd say it's your business how you organise your development cycle. If
you prefer to use mainly GIT and use the Geany-Plugins repository to
put in some more matured code, why not.
Just be aware, most of the Geany-Plugins users will use the SVN
repository, I guess.


Indeed. You can continue using git and use git-svn to commit to the g-p
svn repo whenever you feel it's the right time.

This might will create some issues with build system etc. but in general
you are right.



Might or will? :)

Anyway, what problems do you see?

Best regards.

___
Geany-devel mailing list
Geany-devel@uvena.de
http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel


Re: [Geany-devel] Adding .gitignore files to geany-plugins

2011-03-08 Thread Thomas Martitz
git-svn supports svn:ignore property, perhaps use that instead. See git 
svn create-ignore/show-ignore.


Best regards.
___
Geany-devel mailing list
Geany-devel@uvena.de
http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel


Re: [Geany-devel] Real-time tag parsing (again) (was Geany FTW - better autocompletion)

2011-03-06 Thread Thomas Martitz

Am 06.03.2011 14:25, schrieb Enrico Tröger:

On Sun, 06 Mar 2011 00:57:32 +0100, Colomban wrote:


Hi all!

Le 19/12/2010 16:05, Colomban Wendling a écrit :

Hi!

[...]

Well! If you apply all these patches, you should have a working,
real-time, in-memory tag parsing that should look good :)

So, what's left? Testing of course, lot of it.
Also, for now it doesn't update tag list before the first save (for
new documents). I've not investigating the issue yet though.


So I'll stop here, thank you for your time reading and let you test
this, right? :)

I'm happy to announce that I've now committed these patches to trunk,
with some little improvements -- an option in the Preference dialog to
configure it, MIO integrated, better code in some places, etc.

Great stuff!

A few comments:
- I fixed the Waf build script and the Windows Makefiles, there were
just minor adjustments necessary and now it builds with Waf and on
Windows. Yay.
- you use va_copy() in MIO. va_copy is C99 while all the other va_*
functions are C89. So far, we tried to stay compatible with C89 even
though it is old (and it is old, and old). At least some years ago,
there were actually users who had to use a C89 compiler.
Maybe we should just stop C89 support as we are in 2011 in the
meantime...

Most important things is the licence of MIO.
I think it's possible to release Geany as GPLv2+ with MIO included even
though it's GPLv3. What I don't know is what's the overall licence of
the Geany package is then. I'm not that good in licencing stuff :).
And where do we need to state Geany contains GPLv3 code?


Since you link statically, the whole binary package is GPLv3 since GPLv3 
is not compatible to v2. For the source distribution it's up to each 
individual source file.


IMO it would be wiser to put mio GPLv2+ also. If it's ever packaged 
separately it can be changed to GPLv3.


OTOH I don't suppose you sue each other for GPLv2 vs GPLv3 issues, do 
you? :)


Best regards.
___
Geany-devel mailing list
Geany-devel@uvena.de
http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel


  1   2   >