from:"Colomban Wendling"

Hi,

Le 22/05/2012 20:40, Davide Andreoli a écrit :
 2012/5/21 Dimitar Zhekov dimitar.zhe...@gmail.com
 mailto:dimitar.zhe...@gmail.com
 
 [...]
 
 3. is there a way to really show multiple carets?

 No easy way AFAIK.
 
 
 hey! you are wrong :P
 
 I found the easy way (that also solve the issue 2). I just enabled
 scintilla
 multiple selections ! in fact scintilla is able to do exactly what I was
 searching for :)
 (thank go to elextr that point me to the right direction in IRC)
 
 ...and now the patch is just a 3 liner:
 
 +++ b/src/editor.c
 @@ -4677,6 +4677,11 @@ static ScintillaObject
 *create_new_sci(GeanyEditor *editor)
  /* virtual space */
  SSM(sci, SCI_SETVIRTUALSPACEOPTIONS,
 editor_prefs.show_virtual_space, 0);
 
 +/* multiple selection */
 +SSM(sci, SCI_SETMULTIPLESELECTION, 1, 0);
 +SSM(sci, SCI_SETADDITIONALSELECTIONTYPING, 1, 0);
 +SSM(sci, SCI_SETRECTANGULARSELECTIONMODIFIER, SCMOD_SUPER, 0);
 
 
 [...]

I was about to dig into the Scintilla doc to check whether that
functionality did already exist when I started reading the thread, but I
see you and Lex already found out it did :)

This is a lot better than the initial implementation and looks like an
awesome feature :)

 [...]
 
 note: this is my first geany patch... plese be kind :P

Hey, welcome to the dark side of the force^W application then! :)

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

Re: [Geany-devel] Incompatible UI change, removal of actions from ctrl-click

Hi,

Le 24/05/2012 03:27, Lex Trotman a écrit :
 [posted to both devel and user lists, sorry to those on both]
 
 Hi All,
 
 Geany currently hard codes two actions to the ctrl-left mouse down
 input, goto tag if the click is over an identifier or goto matching
 brace otherwise.
 
 This blocks the standard action of add to selection on ctrl-left
 click and ctrl-left drag.  (See Gnome HIG
 http://developer.gnome.org/hig-book/2.32/hig-book.html#input-mouse
 10.1.2)
 
 I did a quick check on my system and didn't find any application that
 did not comply with that guideline, so Geany is the odd one out.
 
 Geany has not supported multiple selections so it hasn't been an issue
 (other than being non-standard and occasionally confusing users), but
 as there is a proposal to add support for multiple selections to Geany
 this non-standard behavior is now a problem.
 
 As both actions now have a default keybinding (in Git version) I
 propose that the binding to ctrl-left mouse down simply be
 removed.

Your arguments looks sensible to me, as does the ones from Dimitar in
the other thread (that this Ctrl-LMB has too many things bound to it).
Of course it'd be better if we had configurable mouse bindings, but
that's another story.

I also think that if we want to keep a mouse binding for go to tag, we
could choose something less common -- Ctrl+Alt, Super, whatever uncommon
modifier.  Do we want to keep one?

Finally, although it's probably obvious, the multi-select feature should
have a keybinding.


Regards,
Colomban


PS: funny thing, I just discovered that Mozilla apps did support
multi-selection :)
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] Geany multicursors patch

Le 23/05/2012 21:19, Davide Andreoli a écrit :
 2012/5/23 Lex Trotman ele...@gmail.com:
 [...]

 IMHO the multiselection is now small enough (3 lines)  that a plugin
 would be overkill :)

 Davide, what is the impact of enabling this, how do existing features
 interact with multiple selections? Do any Geany actions that use
 selections fail when fed a multi-selection? How does paste work? And
 what if I actually select some text (ie ctrl-swipe not just click).
 
 I did not found any regression nor any strangeness or conflict yet.
 Yes, you can make real multiple selections (Ctrl+Alt+Drag) and the behavior
 is quite always the expected: 'copy' while multiple selection active will
 put in the clipboard all the selected text merged, 'paste' instead will only
 paste at the primary selection, 'typing' with multiple selection will do the
 same as a single selection (selected text cleared). All other commands
 should always work normally on the primary selection(the last one done).

After a very small time of testing I see:

*) Replace (^H) inside selection doesn't work properly when there are
multiple selections (the replacement is only done in the last
selection), while it works fine with rectangular selections.
document_replace_sel() should probably be updated then.

BTW, I'm wondering whether Scintilla has two distinct modes for
rectangular/multiple selections or if a rectangular selection is a
specialized multiple selection (in which case one single code for
handling multisel would be enough on our side).

*) Duplicate line/selection works just fine

*) Toggle case of the selection is buggy, it puts the newly-cased text
altogether on the last selection.  Works fine with rectangular selection.

*) Almost all selection-based actions (like Select current line(s),
toggle line(s) commentation, etc.) only selects the line of the last
selection


IMO Replace and Toggle Case must be updated to work properly.  The other
selection-based commands that doesn't handle the thing really fine would
benefit from handling it, but their result isn't as unexpected as the
two cited above.


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

Re: [Geany-devel] Geany multicursors patch

Le 23/05/2012 21:19, Davide Andreoli a écrit :
 [...]
 
 Ok, I also finished the snippets part, super-easy at the end :)
 you can find my new 'supersnip' branch at:
 https://github.com/DaveMDS/geany/tree/supersnip
 also included the multicursor 3 lines (needed)
 
 Here you can read the description, one example and
 the commit diff for the super snippets patch:
 https://github.com/DaveMDS/geany/commit/c7035d58f2b8b50df96e9cd9fbf6f9e73ec2ce74
 
 I think also this one is small enough for the core...29 lines :)
 
 [...]

No review yet but a small test: it looks pretty good, but it has a bug:
when no %wordN% is defined but there is a %cursor%, a second selection
is created at the very position of the cursor.

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

Re: [Geany-devel] geany-plugins: Autotools usage

2012-05-19 Thread Colomban Wendling

Sorry for the delay, I completely missed this mail.

Le 22/04/2012 20:14, Chow Loong Jin a écrit :
   [...]
 
 - FIXME: CSS? doesn't look like it's needed in geanygendoc -- there's a rule
   to generate manual.html from manual.rst and manual.css. (This probably
   shouldn't be dist'd, but Colomban would probably be in a better position to
   answer that)

Actually there is a bug in the current build system, because the
html4css1 stylesheet should either be distributed or embedded, which
isn't currently the case.

Attached are a few patches updating the build system to properly embed
both stylesheets, and a few other updates.  I didn't commit them/made a
PR yet because #2 is likely to conflict.


Regards,
Colomban
From b7c07dc512616b196d2705c4426d4e3c84285673 Mon Sep 17 00:00:00 2001
From: Colomban Wendling b...@herbesfolles.org
Date: Sat, 19 May 2012 16:59:36 +0200
Subject: [PATCH 1/3] geanygendoc: Update base stylesheet from docutils 0.8.1

---
 geanygendoc/docs/html4css1.css |   20 +++-
 1 file changed, 15 insertions(+), 5 deletions(-)

diff --git a/geanygendoc/docs/html4css1.css b/geanygendoc/docs/html4css1.css
index 030cf17..8160506 100644
--- a/geanygendoc/docs/html4css1.css
+++ b/geanygendoc/docs/html4css1.css
@@ -1,6 +1,6 @@
 /*
 :Author: David Goodger (good...@python.org)
-:Id: $Id: html4css1.css 5951 2009-05-18 18:03:10Z milde $
+:Id: $Id: html4css1.css 7056 2011-06-17 10:50:48Z milde $
 :Copyright: This stylesheet has been placed in the public domain.
 
 Default cascading style sheet for the HTML output of Docutils.
@@ -38,6 +38,10 @@ blockquote.epigraph {
 dl.docutils dd {
   margin-bottom: 0.5em }
 
+object[type=image/svg+xml], object[type=application/x-shockwave-flash] {
+  overflow: hidden;
+}
+
 /* Uncomment (and remove this text!) to get bold-faced definition list terms
 dl.docutils dt {
   font-weight: bold }
@@ -148,16 +152,22 @@ h2.subtitle {
 hr.docutils {
   width: 75% }
 
-img.align-left, .figure.align-left{
+img.align-left, .figure.align-left, object.align-left {
   clear: left ;
   float: left ;
   margin-right: 1em }
 
-img.align-right, .figure.align-right {
+img.align-right, .figure.align-right, object.align-right {
   clear: right ;
   float: right ;
   margin-left: 1em }
 
+img.align-center, .figure.align-center, object.align-center {
+  display: block;
+  margin-left: auto;
+  margin-right: auto;
+}
+
 .align-left {
   text-align: left }
 
@@ -170,7 +180,7 @@ img.align-right, .figure.align-right {
 
 /* reset inner alignment in figures */
 div.align-right {
-  text-align: left }
+  text-align: inherit }
 
 /* div.align-center * { */
 /*   text-align: left } */
@@ -230,7 +240,7 @@ pre.address {
   margin-top: 0 ;
   font: inherit }
 
-pre.literal-block, pre.doctest-block {
+pre.literal-block, pre.doctest-block, pre.math {
   margin-left: 2em ;
   margin-right: 2em }
 
-- 
1.7.10

From bdb96bf7a24c3c54c6dda53921a8cb0550cd0ddd Mon Sep 17 00:00:00 2001
From: Colomban Wendling b...@herbesfolles.org
Date: Sat, 19 May 2012 17:01:23 +0200
Subject: [PATCH 2/3] geanygendoc: Embed base stylesheet

Don't import the base CSS stylesheet from the custom one but rather
embed both in the output HTML.
---
 geanygendoc/docs/Makefile.am |4 ++--
 geanygendoc/docs/manual.css  |2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/geanygendoc/docs/Makefile.am b/geanygendoc/docs/Makefile.am
index 02df8ce..57d273d 100644
--- a/geanygendoc/docs/Makefile.am
+++ b/geanygendoc/docs/Makefile.am
@@ -14,7 +14,7 @@ plugindoc_DATA = manual.rst
 pluginhtmldoc_DATA = manual.html
 
 if BUILD_RST
-manual.html: manual.rst manual.css
-	$(AM_V_GEN) $(RST2HTML) -d --strict --stylesheet-path manual.css $ $@
+manual.html: manual.rst manual.css html4css1.css
+	$(AM_V_GEN) $(RST2HTML) -d --strict --stylesheet-path html4css1.css,manual.css $ $@
 endif BUILD_RST
 endif ENABLE_GEANYGENDOC
diff --git a/geanygendoc/docs/manual.css b/geanygendoc/docs/manual.css
index 4eff7f9..afb527e 100644
--- a/geanygendoc/docs/manual.css
+++ b/geanygendoc/docs/manual.css
@@ -6,7 +6,7 @@
 Stylesheet for use with Docutils.
 */
 
-@import url(html4css1.css);
+/*@import url(html4css1.css);*/
 
 html {
 	background-color: #ec;
-- 
1.7.10

From 54445e987fe07e2d43968bfb97e7889b68731041 Mon Sep 17 00:00:00 2001
From: Colomban Wendling b...@herbesfolles.org
Date: Sat, 19 May 2012 17:03:04 +0200
Subject: [PATCH 3/3] geanygendoc: Update generated manual

---
 geanygendoc/docs/manual.html |  313 +-
 1 file changed, 310 insertions(+), 3 deletions(-)

diff --git a/geanygendoc/docs/manual.html b/geanygendoc/docs/manual.html
index c411ef8..91c202f 100644
--- a/geanygendoc/docs/manual.html
+++ b/geanygendoc/docs/manual.html
@@ -3,11 +3,318 @@
 html xmlns=http://www.w3.org/1999/xhtml; xml:lang=en lang=en
 head
 meta http-equiv=Content-Type content=text/html; charset=utf-8 /
-meta name=generator content=Docutils 0.7: http://docutils.sourceforge.net/; /
+meta name=generator

Re: [Geany-devel] tagmanager changes

Le 07/05/2012 18:04, Nick Treleaven a écrit :
 On 02/05/2012 05:46, Lex Trotman wrote:
 Hi All,

 To summarise since the thread has several subthreads.

 1. Tagmanager Understandability

 a. I generated the doxygen documentation for tagmanager, it works if
 you set recursive, but didn't help much:

 - if its not OOP why does it say things like TMWorkspace is derived
 from TMWorkObject and similar?
 
 documentation bug IMO

I don't think so.  TM uses a more or less OOP-like approach.  See for
example TMWorkspace:

typedef struct
{
TMWorkObject work_object; /*! The parent work object */
GPtrArray *global_tags; /*! Global tags loaded at startup */
GPtrArray *work_objects; /*! An array of TMWorkObject pointers */
} TMWorkspace;

The first field (work_object) is the inherited class, here
TMWorkObject.  And you'll see numerous places where the code uses such a
derived structure as a TMWorkObject -- since it is one actually --,
which looks quite like OOP.

Or see tm_workspace.c:44:tm_create_workspace():  it uses
tm_work_object_register() to register itself as a new type of work
object with a few methods (or vfuncs), and the initializes iself with
tm_work_object_init(), etc.

I very well understand Lex's questionings about how it does actually
work, since it brings a second OOP-style programming in C, less well
known than GObject -- though of course less complex also, but still (BTW
maybe porting to GObject could help?)

 - its not clear how it all goes together, the workspace contains
 global tags and work_objects, or is that files and whats the
 
 workspace work objects are document tags. global tags explained in
 geany's manual.
 
 difference between source_file and file_entry?
 
 It doesn't look like tm_file_entry_ is really used.
 

 - similarly whats the difference between symbol and tag?
 
 tm_symbol_ doesn't seem to be used.
 

 2. Ability to expand tagmanager to handle names declared in lexical
 scopes (not to be confused with struct/class scopes).  Here is the
 example again with some numbers so I can refer to them

 { struct a o; struct a p;
  o./* struct a members */
 { struct b o;
   o./* struct b members */
   p./* struct a members */
 }
 o./* struct a members */
 p./* struct a members1  */
 { struct c o;
   o./* struct c members */
   p./* struct a members2  */
 }
 o./* struct a members */
 p./* struct a members */
   }

 a. yep, tries use more memory than an array, the usual speed/space,
 pick one, tradeoff :)

 b. @Nick, when you say sort by scope then name, are you wanting to
 have an entry in the table for each declaration of the name?
 
 no
 

 - If so this makes the array much bigger to search and your search
 speed depends on size, and it doesn't get you anything, you can't
 search by scope since you don't know if the name is declared in the
 scope you are in or an outer scope compare p at1  and2

 - having a single name array which then points to scope info for the
 name is a viable approach (disclosure, thats how I'm doing the symbol
 table for a language I'm developing) but the table being searched is
 usually larger than if you have nested arrays.  Being smaller these
 are faster to search if the search isn't O(1), hence the suggestion of
 trie instead of bsearch.
 
 the gain in simplicity makes a bigger array to search worth it.
 Remember, global tags aren't included in the workspace array of
 tagmanager, so we're not talking a big number of tags, and we have o(log
 n) searching.
 
 
 4. Ctags parsers

 Agree with Nick that the parsers are usable, but if we start modifying
 them to handle local declarations then they will be totally
 incompatible with the Ctags project so I guess it doesn't matter other
 than for getting languages we don't currently parse.
 
 ctags c.c already parses local tags
 

 5. Overloaded symbols

 Since Colombans patch, overloaded symbols are now stable for all
 practical code (I think theoretically it could get confused if the
 overloads are on the same line but thats unlikely enough to ignore for
 human generated code)
 
 If you're talking about master, I think I still experienced wrong
 parenting on reparsing when removing lines.
 
 6. Moving functionality from symbols.c to tagmanager

 a. Since its the 100th anniversary of the Titanic sinking, I think
 that shuffling the deckchairs is an apt analogy, the functionality
 has to be somewhere, its only useful to move it if the destination
 significantly reduces the effort required.
 
 I don't think I suggested moving functionality. I wondered whether TM
 could help make symbols.c less complex. I would need to understand the
 complexity to know whether this is appropriate or not.

Well, what symbols.c tries to do when updating the symbols tree is (as
documented above update_tree_tags() BTW):

1) update tags that still exist and remove obsolescent ones
2) add the remaining tags (new ones) to the tree

The implementation is a (tiny) little (bit) more

Re: [Geany-devel] tagmanager changes

Le 02/05/2012 06:46, Lex Trotman a écrit :
 [...]
 
 3. Background/asynchronous whatever you want to call it parsing
 
 a. @Colomban, you say that caches are created on first lookup, doesn't
 that throw work back into the UI thread which could have been done in
 the parsing thread?

Well, yes, the UI thread gets the load (unless there is background/async
lookups too :)).  However in my approach there can be any number of
caches [1], and those caches can't really be guessed, so... but maybe
it's simply a bad approach.  Or the used caches could be hard-coded in
CTM so they never get created implicitly -- quite ugly but works).

[1] cache means:  a array of tags sorted by a given sort function.  Each
cache is then used for a particular type of lookups:
* simple completions (sort by name);
* scope completion (uses more than one cache, sorted by scope and name,
and sorted by type);
* etc. (I think there is a third one we use somewhere, can't remenber
what though)
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] tagmanager changes

Le 08/05/2012 02:03, Lex Trotman a écrit :
 On 8 May 2012 02:04, Nick Treleaven nick.trelea...@btinternet.com wrote:
 [...]

 It doesn't look like tm_file_entry_ is really used.
 
 Along with your comment below and about project on the next post,
 sounds like tm code could be reduced significantly.  Might help :)

Agreed at 100%!  If we could cut down TM to remove the code that's
actually not used (or not useful for us) would certainly help a lot to
towards making it easier to understand.  (BTW I think I remember
something about Jiří having done something like it a long time ago)
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] tagmanager changes

Le 30/04/2012 18:54, Nick Treleaven a écrit :
 On 29/04/2012 15:42, Colomban Wendling wrote:
 * it support asynchronous parsing (though not concurrent parsing);

 What's the difference? Also, what does it buy us?

 What I meant when saying it's asynchronous but not concurrent is that it
 supports launching the parsers in a separate thread, but it cannot
 launch several parsers at once.  This is because CTags parsers aren't
 thread-safe (have a lot of global states and no locks).

 What asynchronous parsing gives us is quite simple: no blocking.  This
 means that a slow parser (like e.g. the HTML one on Windows before you
 changed the regex library) wouldn't lock Geany.  Same for project
 plugins that want to parse thousands of files:  this would still take a
 long time, but Geany would be still usable in the meantime.
 
 Ok. It seems a good idea to support this, but for parsing tags in open
 documents it doesn't seem particularly useful, as this ought to be fast.
 The regex problem was unusual IMO and due to an old version of GNU regex.

Right, though a really big file could also be slow to parse.

 BTW, how does TagManager do fast searches?  I always though it did a
 sorting with new attributes each time they changed, so in such
 situations it's even worse than O(n), isn't it?
 
 For searching, it doesn't do any sorting ever. For adding tags the work
 object (i.e. document tags) have to be sorted, which I think is good,
 but also the workspace tags are currently resorted, which I think may be
 a bad design.

If it is never resorted, it means ALL lookups are done on the same
criteria: the name.  Right?  If so, how could scope completion be fast?
 It requires a lot of different search:

1) name search for finding the type of the element to complete;
2) type search for resolving possible typedefs (recursively);
3) scope search for getting the actual results.

Or do I miss something again?

 - a multi-cache one that, as its name suggests, maintains
 multiple
   caches (sorted tags arrays).  it uses a little more memory and is
   slower on insertion since it maintains several sorted lists,
 but a
   search on an already existing cache is very fast.

 Won't this be slow for adding many tags at once? How is this design
 better than tagmanager?

 Well, adding a tag would require a bsearch() on each cache, yes.
 However, adding tags is mostly done in a separate thread (if async
 parsing it used), so it can be less of a problem.
 
 I haven't studied your design, but I would prefer that any design is
 efficient on all threads, so the user's computer can use remaining
 performance for compiling  whatever else they want.

Yeah of course.  One possible simple improvement would be to merge only
when all tags got parsed, getting something like you did earlier with
the patch on TM global tags loading.

But yes, it would still require insertions in multiple caches; but I
though it was worth it since it provided fast search for all caches (see
above for why I though/thinks multiple cache are useful).

 Also, what about global tags? Those can add a lot of tags all at once.

I didn't tried to deal with them yet, but I naively reproduced something
like in TM, e.g. another array (cache(s)) for them, so they shouldn't
make the whole think much slower.  However I'm not certain that having a
completely separate array is really good for searching, but again, I
just replicated the TM design here.

And again, I must admin I didn't actually implemented this for real yet
anyway, so I can't really tell.

 And a search is simply a bsearch() (O(n log n), right?) given the cache
 already exists.  If the cache doesn't exist, it has to be created so
 yeah on the first search it's slow.
 
 If it can be slow enough for the user to notice this is probably bad.

As said in another mail, if it's a problem the required caches can be
hard-coded so they are created anyway.  I doesn't seem a clean thing to
me, but that's very well doable.

 It's not strictly needed, but it makes some memory management easier,
 and fits well with GTK memory management.  And this last point helps a
 lot to maintain the GtkTreeStore on src/symbols.c, now tags are updated
 and not removed.
 But that's not new, I already added this in TM.
 
 Yes. Is the reason the tree should be updated and not recreated to
 preserve fold states and scrollbar position? In fact I'm a bit confused

Yes, that's the most prominent reason.  It's to:

* keep fold state
* keep selection
* keep scroll position
* avoid overall flickering

basically it tries to avoid any visible side effects of replacing the tree.

 about this, how come old tags are still accessed after reparsing the
 document with new tags?

That's the magic of reference counting :)  The GtkListStore actually
holds a reference to the tag, so they can still be used after TM dropped
them.  But anyway we always update the symbol list to have a reference
to the current TM tag/

 BTW, what don't you understand

Re: [Geany-devel] tagmanager changes

Le 08/05/2012 14:12, Colomban Wendling a écrit :
 Le 30/04/2012 19:07, Nick Treleaven a écrit :
 On 29/04/2012 15:47, Colomban Wendling wrote:
 Le 26/04/2012 18:53, Nick Treleaven a écrit :
 On 26/04/2012 16:02, Nick Treleaven wrote:
 On 24/04/2012 22:31, Colomban Wendling wrote:
 * it uses the same tag parsers tagmanager used, in ctagsmanager/ctags;

 BTW this is a good idea to clearly separate CTags from tagmanager. If
 this change can be applied separately, perhaps it could be merged into
 master.

 It should be quite easy -- though it won't still be a vanilla CTags of
 course, my own isn't either (yet?).

 I just thought it was a separate change from the TM rewrite.
 
 It could very well be I think, basically it only changes the directory
 structure a little.  I'll try to replicate this on TM.

Here we go: https://github.com/b4n/geany/commits/tm/tree-refactoring
Looks reasonable?

The Autotools and Waf build systems should be OK (tested  running), but
I haven't tested the makefile.win32s; so if somebody could check them
it'd be awesome.

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

Re: [Geany-devel] gtk_separator_tool_item_new() patch

Hi,

Le 29/04/2012 20:26, Dimitar Zhekov a écrit :
 Hi again, and excuse me for stuffing the list.
 
 Actually there is 1/2 error. The plugin toolbar items are inserted
 improperly, but added to plugin_items list in the right order. So
 using Customize Toolbar and adding/removing items or otherwise
 changing them fixes the order.
 
 Patch attached. Not in git format, sorry.

If I read the thing correctly, the patch is wrong because it would
possibly mixup tool items from different plugins if they aren't added at
the same time, wouldn't it?

But you're right that there is a problem.  Currently, it creates:

| Plugin_1_Item_2 Plugin_1_Item_1 | Plugin_2_Item_1 | Quit

and should create

| Plugin_1_Item_1 Plugin_1_Item_2 | Plugin_2_Item_1 | Quit

However with your patch, if plugins are added in the order
Plugin_1_Item_1, Plugin_2_Item_1, Plugin_1_Item_2, it would give:

| Plugin_1_Item_1 | Plugin_2_Item_1 Plugin_1_Item_2 | Quit

Which is also wrong (more wrong if I could say).


Getting that right seems a bit harder and would need to be able to know
what's the last item added by a given plugin.  Maybe tagging the widget
with the plugin it belongs to, and then search for the first
non-matching one would do the trick:

def get_insert_position(plugin):
pos = toolbar.get_default_insert_pos()

if plugin.autosep:
# find the last item belonging to @plugin
while pos  toolbar.get_n_items():
item = toolbar.get_item(pos)
if item.get_data(plugin) != plugin:
break

return pos

def add_item(plugin, item):
pos = get_insert_pos(plugin)

if not plugin.autosep:
plugin.autosep = create_sep()
toolbar.insert(plugin.autosep, pos)
pos += 1

item.set_data(plugin, plugin)
toolbar.insert(item, pos)

Maintaining an index don't seem really a good idea since it would be one
another thing to keep, and I don't think that adding a tool item is a
performance-critical thing so the possible overhead finding the position
(if there is already an item) should not be a problem.

Thoughts?

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

Re: [Geany-devel] tagmanager changes

Hi,

Le 26/04/2012 17:02, Nick Treleaven a écrit :
 On 24/04/2012 22:31, Colomban Wendling wrote:
 Le 17/04/2012 18:20, Nick Treleaven a écrit :
 Sorry for the long delays -- and also small activity -- recently.  I
 have/had a lot of non-Geany stuff to do and stuff, the whole story, you
 know.
 
 No problem.
 
 I finally committed it and pushed it so you can see it, comment, blame,
 flame  more:  see https://github.com/b4n/geany/tree/wip%2Fctagsmanager

 A few points, as they comes to my mind:

 * it support asynchronous parsing (though not concurrent parsing);
 
 What's the difference? Also, what does it buy us?

What I meant when saying it's asynchronous but not concurrent is that it
supports launching the parsers in a separate thread, but it cannot
launch several parsers at once.  This is because CTags parsers aren't
thread-safe (have a lot of global states and no locks).

What asynchronous parsing gives us is quite simple: no blocking.  This
means that a slow parser (like e.g. the HTML one on Windows before you
changed the regex library) wouldn't lock Geany.  Same for project
plugins that want to parse thousands of files:  this would still take a
long time, but Geany would be still usable in the meantime.

 * it is under the new ctagsmanager/ directory;
 * it uses the same tag parsers tagmanager used, in ctagsmanager/ctags;
 * all types have different names than the tagmanager ones, though
currently the API is almost an 1:1 mapping -- and that's maybe a
huge mistake?;
 
 I don't understand why tagmanager has to be replaced, why not just
 replace the parts you want to improve? Rewriting it is likely to lead to
 a new set of bugs and be hard to review and merge changes from master.

I think Lex and Matthew probably summarize it quite correctly:  it's not
that TM is bad or has to be replaced; it is that (I'm) unable to
understand it enough to fix anything in it, like scope completion.
Maybe it's only me, but I tried hard :)

And the only reason why maybe TagManager would need replacement/large
changes is asynchronous parsing.  I'm not sure how hard it would be to
get it with TM -- but again, maybe it's only that I don't understand it
enough.

 * there is 2 backends as of today:
- a simple one that is simple and that doesn't waste (too much)
  memory, but that searches in O(n);
 
 Linear searching seems like a bad idea when we currently have O(log n).
 Removing x tags is O(n * x) by the look of it.

I agree it's not interesting regarding performances, and this backend
isn't meant for it.  I needed an implementation for early testing, so I
wrote it simple.  And it showed useful for testing later on too, since
because of it's simplicity it isn't bugged -- just slow :)

BTW, how does TagManager do fast searches?  I always though it did a
sorting with new attributes each time they changed, so in such
situations it's even worse than O(n), isn't it?

- a multi-cache one that, as its name suggests, maintains multiple
  caches (sorted tags arrays).  it uses a little more memory and is
  slower on insertion since it maintains several sorted lists, but a
  search on an already existing cache is very fast.
 
 Won't this be slow for adding many tags at once? How is this design
 better than tagmanager?

Well, adding a tag would require a bsearch() on each cache, yes.
However, adding tags is mostly done in a separate thread (if async
parsing it used), so it can be less of a problem.

And a search is simply a bsearch() (O(n log n), right?) given the cache
already exists.  If the cache doesn't exist, it has to be created so
yeah on the first search it's slow.

 Given my global tags merge change (see below), I think tagmanager needs
 some changes to avoid sorting the workspace tags array each time tags
 are updated, but this is certainly doable.
 
In practice I haven't yet tested anything big enough to see any
difference in performances between these two backends, and that's
something that probably isn't worth bothering about for now.

 * this backend abstraction might be really overkill, and maybe we
could do better without it?;
 
 I don't see why having two is better. The memory overhead for a pointer
 array is not much vs. the size of the tag structures. Fast searching is
 important.

Multiple backends isn't really useful probably.  As said above, the
first was mostly a testing one, and I wanted to be able to keep both
during development for better testing.  At one point I also though maybe
there could be some backends optimized for particular situations, like
fast search, fast insertion, low memory consumption, etc., but I don't
see much use for this anymore.

 * tags (and most types) are reference-counted (so they aren't
necessarily duplicated, e.g. in the multicache backend);
 
 I don't really understand src/symbols.c since the real-time parsing
 change, so don't really understand why this is needed.

It's not strictly needed, but it makes some memory management

Re: [Geany-devel] tagmanager changes

Le 26/04/2012 18:53, Nick Treleaven a écrit :
 On 26/04/2012 16:02, Nick Treleaven wrote:
 On 24/04/2012 22:31, Colomban Wendling wrote:
 * it uses the same tag parsers tagmanager used, in ctagsmanager/ctags;
 
 BTW this is a good idea to clearly separate CTags from tagmanager. If
 this change can be applied separately, perhaps it could be merged into
 master.

It should be quite easy -- though it won't still be a vanilla CTags of
course, my own isn't either (yet?).

 For avoiding resorting of workspace tags when only reparsing one source
 object, we can remove the source object's old tags  merge the new tags.
 This is all O(n) for the workspace array. I haven't looked into
 implementing this yet because now it's clear you're working on a
 competing change.
 
 Another option is to remove the workspace array altogether and just have
 Geany collate tags from each (sorted) source object when needed. Not
 sure the implications of this yet but it would simplify tagmanager.

Well, tagmanager needs to know all tags to perform e.g. scope completion
beyond file's boundaries.  And for search too, it would need us to pass
it everything, or to perform a search on each document's tags and then
merge the result.  Doesn't sound sensible at a first glance, but maybe
I'm missing something.
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] tagmanager changes

Le 27/04/2012 07:30, Lex Trotman a écrit :
 [...]
   - a multi-cache one that, as its name suggests, maintains multiple
 caches (sorted tags arrays).  it uses a little more memory and is
 slower on insertion since it maintains several sorted lists, but a
 search on an already existing cache is very fast.


 Won't this be slow for adding many tags at once? How is this design better
 than tagmanager?
 
 Perhaps Colomban could confirm, but my first thought is that this is
 for nested scopes.

Not at all, sorry :)
It's only for performance, so search on different criteria can remain
fast (just a bsearch()).

 How does tagmanager handle nested scopes, or how would it need to be
 modified to do so, considering the example (in C)
 
 { struct a o; struct a p;
o./* struct a members */
   { struct b o;
 o./* struct b members */
 p./* struct a members */
   }
   o./* struct a members */
   p./* struct a members */
   { struct c o;
 o./* struct c members */
 p./* struct a members */
   }
   o./* struct a members */
   p./* struct a members */
 }
 
 How much needs to be changed in tagmanager so that the right
 autocompletes can be provided at each comment?  (assuming c.c is
 taught to parse local variables of course)
 
 And of course the same question for Colomban.

To really support such thing would require the parsers to provide a true
tree, not a flat thing.  However, my scope completion algorithm takes
into account a few things to try to find The Right Thing™:

1) the file in which the tag appears (e.g. tries to resolve things
locally first);
2) the distance in lines between the tags (e.g. the tag that comes
just before the one to complete has precedence over another one).

but this wouldn't be enough to get correct results with your example; it
would really need a tree.


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

Re: [Geany-devel] tagmanager changes

Le 29/04/2012 14:07, Nick Treleaven a écrit :
 On 27/04/2012 06:30, Lex Trotman wrote:
 [...]

 I don't understand why tagmanager has to be replaced, why not just
 replace
 the parts you want to improve? Rewriting it is likely to lead to a
 new set
 of bugs and be hard to review and merge changes from master.
 
 One of the problems with tagmanager is its complexity, leading to
 considerable wariness on the part of many of us about changing it
 since we don't understand what we might break.
 
 I don't see this myself, I see some complicating issues which could be
 resolved (and I'm willing to work on them), but generally a sound design
 for what it provides and for extra things we may want to add.
 
 Actually documenting the overall structure of tagmanager and how it is
 supposed to work would be a good thing, whats a workspace? what is it
 meant to represent, how are scopes represented? etc.
 
 Isn't it clear from the data structures? Look at TMWorkspace. Scopes and
 other tag metadata is the same as CTags. Obviously if we had at-a-glance
 overall documentation that would be good.

What I personally blame TM for is not the data structure or overall
design, but the code.  I can't get my head around the implementation.
Every time I try to get it, I get a headache and generally no fix :(

But maybe I'm just plain stupid, or maybe I just miss one or two key
things of how it's written to get it.

 One confusing thing is that a TMTag can be used for an actual tag or for
 a file. Probably that could be cleaned up.

Agreed, that's something I think that should be quite easy to fix and
that would make the thing easier to understand at first (though it's not
one of the things that makes me not understand TM ;)).  BTW, do we
actually use any file tags?

- a multi-cache one that, as its name suggests, maintains multiple
  caches (sorted tags arrays).  it uses a little more memory and is
  slower on insertion since it maintains several sorted lists, but a
  search on an already existing cache is very fast.


 Won't this be slow for adding many tags at once? How is this design
 better
 than tagmanager?

 Perhaps Colomban could confirm, but my first thought is that this is
 for nested scopes.
 
 I expect the design is better in some respects (and to be fair I didn't
 look for better things), but finding a tag based on its name is
 something we are always going to want to be fast. Even for scope
 completion, you still need to lookup a tag structure from a name string.
 So I think we will always want a sorted array of tags per document that
 we can bsearch (or something equally fast).
 
 Also, I've probably sounded quite harsh on Colomban's design, but I'm
 commenting on what I think is important. I am genuinely interested in
 why his design decisions are better. It's a lot to take in all at once,
 so probably needs some explanation. Sorry if I didn't make that clear.

Don't worry about sounding harsh or something, I totally agree that
changing for changing is not a good idea.  To be honest, there were
really two reasons why I tried to write a new tagmanager on the first place:

1) because I wasn't able to fix the current one;
2) to support asynchronous parsing.

And actually I haven't added much great design, it actually works quite
the same as does TM currently -- per-file tags, a workspace holding a
merge of all tags.

 [...]
 
 * tags (and most types) are reference-counted (so they aren't
necessarily duplicated, e.g. in the multicache backend);


 I don't really understand src/symbols.c since the real-time parsing
 change,
 so don't really understand why this is needed.

 Blame C++ and overloaded names I think.
 
 I looked at the thread about that, and from what I could tell, the
 problem was for reparsing unsaved files. Wasn't the order OK for files
 that have just been saved? (Also I don't follow what that has to do with
 reference counting).

We don't parse unsaved files at all because TM can't do that.  And
that's once another thing that should be fixed.

However I don't get the point you're talking about, maybe my answer is
OT then.


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

Re: [Geany-devel] tagmanager changes

2012-04-24 Thread Colomban Wendling

Le 17/04/2012 18:20, Nick Treleaven a écrit :
 Hi,
 How's it going?

Hi,

Sorry for the long delays -- and also small activity -- recently.  I
have/had a lot of non-Geany stuff to do and stuff, the whole story, you
know.

 Lex mentioned in this mail:
 http://lists.uvena.de/pipermail/geany/2012-April/007991.html
 
 that (according to him) you are working to 'replace it'. Maybe he's
 exaggerating, but this sounds interesting. If you have time could you
 maybe send me a link to the IRC log, or better, explain a little about
 the work on the devel list?

That's true, I have a WIP on writing a new ctags management code.  It is
far from being ready for production, and I'm not even sure the ideas in
it are really appropriate.  But yes, there is a something :)

I finally committed it and pushed it so you can see it, comment, blame,
flame  more:  see https://github.com/b4n/geany/tree/wip%2Fctagsmanager

A few points, as they comes to my mind:

* it is under the new ctagsmanager/ directory;
* it uses the same tag parsers tagmanager used, in ctagsmanager/ctags;
* it support asynchronous parsing (though not concurrent parsing);
* all types have different names than the tagmanager ones, though
  currently the API is almost an 1:1 mapping -- and that's maybe a
  huge mistake?;
* there is 2 backends as of today:
  - a simple one that is simple and that doesn't waste (too much)
memory, but that searches in O(n);
  - a multi-cache one that, as its name suggests, maintains multiple
caches (sorted tags arrays).  it uses a little more memory and is
slower on insertion since it maintains several sorted lists, but a
search on an already existing cache is very fast.

  In practice I haven't yet tested anything big enough to see any
  difference in performances between these two backends, and that's
  something that probably isn't worth bothering about for now.

* this backend abstraction might be really overkill, and maybe we
  could do better without it?;
* tags (and most types) are reference-counted (so they aren't
  necessarily duplicated, e.g. in the multicache backend);
* tag matching/finding is done using ctm_data_backend_find() (or a
  convenience wrapper), which takes 2 functions for performing the
  search:
  - a sort function, used to, heh, sort the tags to search and/or the
resulting list (the simple backend should use it to sort the
result; and the multi-cache backend uses it to sort the caches)
  - a match function, use to check whether a tag should be included in
the results.  Like the sort function it returns a strcmp()-like
value, with the only difference that it probably returns 0 for more
tags.

  It is somewhat similar to what tagmanager did, but it's more flexible
  -- and maybe complex, though many sort/match functions would already
  be provided.

* no pruning is done yet, so there is duplicate in the results;
* there is an (almost) working scope completeion implementation;
* ... I don't see anything to add, so I'll stop here :)

All this isn't of course written in stone: if we already redo a lot of
things, let's get something nice -- though IMO we'll always be better
than with tagmanager, since each time I wanted to touch it it took me
hours, and sometimes I even haven't been able to fix the problem
(thinking of e.g. scope completion...).

 Also, later in the thread he says that performance problems with
 resorting global and workspace tags cannot be fixed with the design of
 tagmanager. I've been working yesterday on improving this significantly
 by merging the new tags each time instead of resorting *all* the tags. I
 hope to commit this in the next few days.

Cool!  I haven't done any profiling on either tagmanager or may new
attempt, so I can't tell what's actually slow, but any improvement is
good to have :)


Regards,
Colomban

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

Re: [Geany-devel] [geany/geany] 5f0963: List package dependencies only in configure.ac

Le 12/04/2012 18:41, Colomban Wendling a écrit :
 Modified: wscript
 1 files changed, 1 insertions(+), 0 deletions(-)
 ===
 @@ -346,6 +346,7 @@ def build(bld):
  bld.new_task_gen(
  source  = 'geany.pc.in',
  dct = {'VERSION' : VERSION,
 +   'DEPENDENCIES': 'gtk+-2.0 = 2.16 glib-2.0 = 
 2.20',
 'prefix': bld.env['PREFIX'],
 'exec_prefix': '${prefix}',
 'libdir': '${exec_prefix}/lib',

I'm wondering if there is a way to get at least the version from the
configuration?  Like bld.conf.libs['GTK'].atleast_version or something?
 I haven't found how to do so, but maybe you'll know :)

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

Re: [Geany-devel] Development of code re-formatting plugin

Le 10/04/2012 01:59, Lex Trotman a écrit :
 On 10 April 2012 09:05, Colomban Wendling lists@herbesfolles.org wrote:
 Hi,

 Le 09/04/2012 12:41, Lex Trotman a écrit :
 On 9 April 2012 20:08, Nayan Shah na...@nayanshah.com wrote:
 Hello,

 I am planning to develop a code re-formatting plugin for geany. I want it 
 to
 be more on the lines of Notepad++'s C++ re-indent plugin which is pretty
 awesome.

 I don't know Notepad++, but I started a indenter plugin awhile ago, I'll
 try to check where it is and make the source available if it can be
 useful.  I should also finish it, but...

 The feature could be something like : user selects bunch of text and clicks
 beautify or maybe it works on the whole file by default.

 Astyle http://astyle.sourceforge.net/ is a small automatic formatter and
 released under LGPL. It is pretty small with loads of options. and supports
 C, C++, Java code.

 Can it be used for development of the plugin ?

 Any feedback / comments would be appreciated.

 Yes you could make a plugin to run astyle, but it would probably be
 easier to just use it as a custom command, see
 http://www.geany.org/manual/current/index.html#sending-text-through-custom-commands

 Unfortunately astyle does crazy stuff (like seeking back and forth) with
 
 I can understand why it would do that to look ahead, but it would be
 good if it documented that it *does not* work with pipes.
 
 its input, making impossible to pipe data to it (actually it'll work
 until the data size exceeds the OS's IO buffer size IIRC, but if it
 
 Looking at the code it should give an error message if it can't seek
 in the file, so it should just generate no output, but maybe thats
 recent.

Or maybe I simply misremember what was the problem and it only truncated
the output, I'm not 100% sure, though I think it was worst than that.

 exceeds that size astyle will just hang indefinitely).  Calling that
 executable requires a real file then.  The plugin I talked about
 previously has an astyle backend too, but it writes a temp file for the
 very reason above.
 
 Does that mean it is universal and can use any beautifier?

Well, universal is maybe a bit too presumptuous, but yeah, I wanted it
to support any intenter.   However, I made it backend-based style, so
it can use e.g. a library, but it then requires the backend to be
written, not simply a indenter program to exist.

 And maybe integrate Universal Indent GUI to set them up?

Isn't that a Qt program?  But yes, I wanted to do something like this --
actually each backend would export a set of options and a generic GUI
would display them and allow to edit them.

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

Re: [Geany-devel] [geany/geany] 5f0963: List package dependencies only in configure.ac

Le 12/04/2012 22:36, Enrico Tröger a écrit :
 On Thu, 12 Apr 2012 18:47:18 +0200, Colomban wrote:
 
 Hi,
 
 first, nice idea about making the dependency information more central!
 
 
 Modified: wscript
 1 files changed, 1 insertions(+), 0 deletions(-)
 ===
 @@ -346,6 +346,7 @@ def build(bld):
  bld.new_task_gen(
  source  = 'geany.pc.in',
  dct = {'VERSION' : VERSION,
 +   'DEPENDENCIES': 'gtk+-2.0 = 2.16
 glib-2.0 = 2.20', 'prefix': bld.env['PREFIX'],
 'exec_prefix': '${prefix}',
 'libdir': '${exec_prefix}/lib',

 I'm wondering if there is a way to get at least the version from the
 configuration?  Like bld.conf.libs['GTK'].atleast_version or something?
 I haven't found how to do so, but maybe you'll know :)
 
 Not completely sure what you mean by from the configuration. From
 where exactly do you want to read the versions?
 
 Do you want to read the line
 gtk_modules=gtk+-2.0 = 2.16 glib-2.0 = 2.20
 from configure.ac?

No, I meant fetch the version info from the waf configure() step (lines
131-134).  However we could simply put the package version info in a
global and use it in both places.

 That would be a bit hackish but definetely possible and would make
 maintaing the versions easier, a bit less obvious the fact we are using
 two build systems...(yes, I know...).

Well, although it'd make a GTK dependency version bump a little easier,
it's so hackish I doubt it's a good idea because of the potential
headache it it breaks at some point :)

Cheers,
Colomban

 
 If so, I could write a few lines to parse configure.ac :).
 
 Regards,
 Enrico
 

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

Re: [Geany-devel] [geany/geany] 5f0963: List package dependencies only in configure.ac

Le 12/04/2012 23:10, Enrico Tröger a écrit :
 On Thu, 12 Apr 2012 22:49:26 +0200, Colomban wrote:
 
 I'm wondering if there is a way to get at least the version from the
 configuration?  Like bld.conf.libs['GTK'].atleast_version or
 something? I haven't found how to do so, but maybe you'll know :)

 Not completely sure what you mean by from the configuration. From
 where exactly do you want to read the versions?

 Do you want to read the line
 gtk_modules=gtk+-2.0 = 2.16 glib-2.0 = 2.20
 from configure.ac?

 No, I meant fetch the version info from the waf configure() step (lines
 131-134).  However we could simply put the package version info in a
 global and use it in both places.
 
 Yeah, that sounds good, done in
 https://github.com/geany/geany/commit/012a904e7496699b792761c12385cd289d7b6f68.

Great, looks good :)

Cheers,
Colomban

 
 Regards,
 Enrico
 

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

Re: [Geany-devel] geany-plugins tests failures

2012-03-25 Thread Colomban Wendling

Le 25/03/2012 17:46, Quentin Glidic a écrit :
 Hello,
 
 While running geany-plugins tests, I hit two failures.
 
 The first one is that cppcheck is not happy about Vala, and since
 multiterm is fully in Vala, it fails.

ACK, running cppcheck on a non-C plugin seems stupid anyway.

 The second one is that it couldn’t detect an assignment nested in an array.

ACK, initializer element is not computable at load time which is bad C
anyway.

 Attached two simple patches to fix these.
 
 Cheers


BTW, my cppcheck (1.53) finds 5 things in debugger:

dbm_gdb.c:1304: error: Possible null pointer dereference: record
dbm_gdb.c:1579: error: Possible null pointer dereference: record
dbm_gdb.c:1700: error: Possible null pointer dereference: record
dbm_gdb.c:967: error: Memory pointed to by 'record' is freed twice.
debug.c:502: error: Possible null pointer dereference: expression

The first looks like a real possible problem, if exec_sync_command()
returns RC_DONE at line 618 because wait4prompt is false.

The others *may* be false positive because cppcheck guesses that if you
initialize a variable to NULL you expect that passing it by reference
may not change its value.  (e.g. foo=NULL; fun(foo); ...)

However they seem to be real problems to me here.  It seems to me that
exec_sync_command() can return RC_DONE either if it has or not set the
command_record argument, in which case the caller can't know whether it
has to free the value or if it wasn't set.  So, the caller must pass a
properly NULL-initialized variable;  but then the caller also have to
check whether that variable is non-NULL before dereferencing it -- and
must free() it whatever happens.

So, IIUC:

in dbm_gdb.c on lines 1304, 1579, 1700:
 * record should be checked against NULL before passing it to strstr()

in dbm_gdb.c on line 1579:
 * record should be freed even when rc != RC_DONE (line 1578)

in dbm_gdb.c on line 967:
 * record should be re-initialized to NULL after the first free on line 963

in debug.c on line 502:
 * IIRC expression might be NULL if it happens that the W_EXPRESSION
column isn't set in the model, so a NULL check should be done before
passing expression to strlen()
 * using strlen() to check whether a string is empty seems sub-optimal
too, and you could consider using the NZV() macro from geany's utils.h
-- and this macro handles NULL too


That's all for now :)  There are also some stuff that should be fixed
for good C practices and/or C89 compliance, but I'll check these later.

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

Re: [Geany-devel] C++ Symbols problem

2012-03-23 Thread Colomban Wendling

Le 18/03/2012 10:59, Lex Trotman a écrit :
 Hi Colomban,
 
 I used both patches all afternoon with no visible problems.  They seem
 to work as advertised.  Will keep using, thanks.

Great then :)  I now have committed the sidebar fixes.

Cheers,
Colomban

 
 Cheers
 Lex
 
 On 18 March 2012 08:36, Colomban Wendling lists@herbesfolles.org wrote:
 Le 13/03/2012 01:48, Lex Trotman a écrit :
 Hi All,

 Hey!

 Here's an initial patch that fixes the issue by better handling of true
 duplicate tags.  It's not necessarily the better fix for the issue,
 where maybe having the template type info would be better, but it is
 more generic since it would handle any duplicate.

 It's not much tested, but have fun :)

 Cheers,
 Colomban



 There is a problem with symbols in some C++ programs which causes some
 class members to appear and disappear or move in the sidebar.
 Needless to say this is *very* distracting.

 The minimal program to demonstrate this is:

 templatebool bclass problem;

 template class problemfalse {
 };

 template class problemtrue {
   int i_change;
 };


 The member i_change changes each time the symbols pane is updated,
 correctly showing as part of the class at line 6, then part of the
 class at line 3, then disappearing, then back to the class at line 6
 etc.

 In C++ this program has three class names:

 a) at line 1 declaration of problembool
 b) at line 3 definition of problemfalse
 c) at line 6 definition of problemtrue

 Note that these are distinct classes as if the names include bool,
 true and false.

 But neither symbols.c or the tagmanager parser includes the template
 parameters in the name, instead showing both of the classes at line 3
 and 6 as problem.

 Discussion with Colomban on IRC indicated that this may be confusing
 the symbol update algorithm.  Forcing a complete re-generation of the
 symbols did indeed stabilise the sidebar.

 I think that the problem is due to update_tree_tags() identifying the
 parent of i_change just by name so it can't tell if line 3 or line 6
 (or possibly line 1) is the parent.

 If  i_change is shown in the symbol tree as part of the class at line
 6 then it will be in the parent_tags hash with parent of problem.
 If this is taken as problemof line 3 as parent, it will delete it
 from the class at line 6 in pass 1 and as i_change is still in the
 tags list will add it to the class at line 3 since thats what the
 parent_tags hash says is its parent.

 On the next symbol update, since what it thinks is the parent of
 i_change (the class at line 3) does not in fact have i_change as a
 member, it will be deleted from the tree and the tags list, so it
 isn't added again in pass 2.

 On the next symbol update i_change is not in the tree so it isn't in
 the parent_tags hash so it is added where the tags list says is the
 correct place.

 If the order of the definitions at line 3 and 6 are reversed i_change
 just alternates on and off, suggesting that it isn't the first
 definition of the symbol problem that is the one found.

 At least I think this is the mechanism?

 Other than the hack to re-create the whole table each time, I'm not
 sure how to cure it without distinguishing the three class names, and
 that means modifying tagmanager/c.c (shudder).

 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

 ___
 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

[Geany-devel] Scope completion fix/reimplementation

2012-03-23 Thread Colomban Wendling

Hi guys,

I re-implemented scope completion some time ago and it seems to work
quite OK, at least far better than the current TM stuff that seem to
provide random results -- when it provides some.

I already posted the patch in the C++ Symbols problem, but it's here
again, since I want you to take a look at it.

So.  I'm wondering if you have some comments and/or options on the
patch, and if you think that I should commit it as at least an interim
solution until we get some working replacement for TM [1].

Known issues (they were already present in previous implementation BTW):

 * :: triggers the same as - or ., e.g. it fetches completions
for a variable name, not a class name.  This should be quite easy to fix
(if we can assume :: always completes a type name).

 * Currently only a single word is used to get the scope.  E.g., if
typing foo.bar.baz, only baz is used to find what the user wants to
complete.  This works completely fine if there is only possible
candidate for baz, but if there are multiple candidates, using the
previous scoping could help to find out which one is the right one.
   Normally the attached implementation does a fair job at guessing what
is the right thing to complete, but it still can't read your mind --
that could even be blank, sigh.

 * We only parse global variables in many languages, so scope completion
for local variables will probably not work -- though it works for
sub-members, like local.member.foo.


So.  I'm now waiting for your replies :)

Cheers,
Colomban



[1] because I don't think anybody understands the TM code anymore, and
it has some flaws we can't fix -- this one for example
From a96669230b860ae3229150715ff65621d3c37657 Mon Sep 17 00:00:00 2001
From: Colomban Wendling b...@herbesfolles.org
Date: Tue, 23 Aug 2011 02:20:11 +0200
Subject: [PATCH] First attempt at fixing scope completion

Actually it's a re-implementation that looks pretty well working.
---
 src/editor.c |  204 -
 1 files changed, 186 insertions(+), 18 deletions(-)

diff --git a/src/editor.c b/src/editor.c
index 67dd295..739c940 100644
--- a/src/editor.c
+++ b/src/editor.c
@@ -683,14 +683,190 @@ static void request_reshowing_calltip(SCNotification *nt)
 }
 
 
+/* mostly stolen from tm_workspace.c:match_langs() */
+static gboolean lang_matches(const TMTag *tag, langType lang)
+{
+	if (lang == -1)
+		return TRUE;
+
+	if (tag-atts.entry.file)
+	{	/* workspace tag */
+		if (lang == tag-atts.entry.file-lang)
+			return TRUE;
+	}
+	else
+	{	/* global tag */
+		if (lang == tag-atts.file.lang)
+			return TRUE;
+	}
+	return FALSE;
+}
+
+
+/* gets the real type of @name_orig by resolving the typedefs
+ * @file: (in/out) the preferred TMSourceFile, will be filled with the TMSourceFile in which the
+ *   returned is found. This may point to @NULL, but cannot be a NULL pointer */
+static const gchar *resolve_typedef(TMWorkObject **file, const gchar *type_name, langType lang)
+{
+	const TMWorkspace *ws = tm_get_workspace();
+	guint i, pass = 0;
+	GPtrArray *tag_arrays[3];
+	gboolean again;
+
+	g_return_val_if_fail(file != NULL, NULL);
+	g_return_val_if_fail(type_name != NULL, NULL);
+
+	tag_arrays[0] = (*file) ? (*file)-tags_array : NULL;
+	tag_arrays[1] = TM_WORK_OBJECT(ws)-tags_array;
+	tag_arrays[2] = ws-global_tags;
+
+	do
+	{
+		again = FALSE;
+
+		g_debug(resolving %s..., type_name);
+		for (i = 0; i  G_N_ELEMENTS(tag_arrays); i++)
+		{
+			const TMTag *tag;
+			guint j;
+
+			if (! tag_arrays[i] || tag_arrays[i]-len  1)
+continue;
+
+			foreach_ptr_array(tag, j, tag_arrays[i])
+			{
+if (! lang_matches(tag, lang))
+	continue;
+
+if (tag-type  tm_tag_typedef_t  strcmp(type_name, tag-name) == 0 
+	tag-atts.entry.var_type  strcmp (type_name, tag-atts.entry.var_type) != 0)
+{
+	type_name = tag-atts.entry.var_type;
+	/* we need to resolve the new name in case it is typedefed again, trying the
+	 * file containing the typedef first */
+	again = TRUE;
+	*file = TM_WORK_OBJECT(tag-atts.entry.file);
+	tag_arrays[0] = (*file) ? (*file)-tags_array : NULL;
+	break;
+}
+			}
+		}
+		pass++;
+	}
+	while (again  pass = 8);
+	/* 8 is an arbitrary limit not to loop infinitely on recurive self-referencing typedefs */
+
+	g_debug(resolved to %s., type_name);
+	return type_name;
+}
+
+
+/* tries to find children of type @type_name
+ * @file: the preferred TMSourceFile (e.g. the one containing the type definitions) */
+static GPtrArray *find_type_children(TMWorkObject *file, const gchar *type_name, langType lang)
+{
+	const TMWorkspace *ws = tm_get_workspace();
+	guint i;
+	gsize len;
+	const GPtrArray *tag_arrays[3];
+	GPtrArray *children = NULL;
+
+	g_return_val_if_fail(type_name != NULL, NULL);
+
+	g_debug(searching children for %s..., type_name);
+
+	type_name = resolve_typedef(file, type_name, lang);
+	len = strlen(type_name);
+
+	tag_arrays[0] = file ? file-tags_array : NULL;
+	tag_arrays[1

Re: [Geany-devel] Wrap words Addon patch

2012-03-21 Thread Colomban Wendling

Le 21/03/2012 08:21, Frank Lanitz a écrit :
 Am 21.03.2012 00:33, schrieb Colomban Wendling:
 Le 20/03/2012 22:14, Frank Lanitz a écrit :
 On Tue, 13 Dec 2011 17:46:47 +0800
 Nathan Broadbent nathan@gmail.com wrote:

 1. Visit https://github.com/pzoxiuv/geany-plugins-1
 2. Click 'Pull Request'
 3. In the box on the right, you will see the heading 'Head branch ·
 tag · commit'. There is an input field next to pzoxiuv/geany... @,
 where you should type your branch (addons_wraptext).
 4. You can enter a title  description, and double check the commits
 and changes. If everything looks good, click 'Send pull request'


 I guess you were answering to my Wrap Word Addon patches mail?

 Once this is done and Nathan is happy with your code he will send the
 pull request to geany-plugins and most likely I will have tons of
 comments but finally will add it ;) 

 Hum huh heh heuu… what?  You mean I create a pull request on
 geany/gneay-plugins right?  I don't know who's Nathan actually, but I
 doubt he's the new addons maintainer -- or I missed some mails hard and
 I misread the MAINTAINERS file.
 
 Nathan build the original patch set introducing wrap word into addons
 plugin.

If I read the mails and the blame correctly, it looks to me it was Alex
Meyer :)

 Anyway, I created a pull request on the GP repo directly, hopefully it's
 what you meant and everything's fine.
 
 Its fine.

Cool.


Cheers,
Colomban

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

Re: [Geany-devel] Wrap words Addon patch

2012-03-20 Thread Colomban Wendling

Le 20/03/2012 22:14, Frank Lanitz a écrit :
 On Tue, 13 Dec 2011 17:46:47 +0800
 Nathan Broadbent nathan@gmail.com wrote:
 
 1. Visit https://github.com/pzoxiuv/geany-plugins-1
 2. Click 'Pull Request'
 3. In the box on the right, you will see the heading 'Head branch ·
 tag · commit'. There is an input field next to pzoxiuv/geany... @,
 where you should type your branch (addons_wraptext).
 4. You can enter a title  description, and double check the commits
 and changes. If everything looks good, click 'Send pull request'
 

I guess you were answering to my Wrap Word Addon patches mail?

 Once this is done and Nathan is happy with your code he will send the
 pull request to geany-plugins and most likely I will have tons of
 comments but finally will add it ;) 

Hum huh heh heuu… what?  You mean I create a pull request on
geany/gneay-plugins right?  I don't know who's Nathan actually, but I
doubt he's the new addons maintainer -- or I missed some mails hard and
I misread the MAINTAINERS file.

Anyway, I created a pull request on the GP repo directly, hopefully it's
what you meant and everything's fine.

Cheers,
Colomban

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

Re: [Geany-devel] Default keybinding for Zoom In

2012-03-18 Thread Colomban Wendling

Le 19/03/2012 03:06, Matthew Brush a écrit :
 Hi,
 
 It's always bothered me that Geany uses the wrong keybinding for Zoom
 In, but I'm starting to think it's completely on accident. The normal
 keybinding for Zoom In on most applications is Control and Equal (same
 key as plus symbol). If you look at the default keybinding for Zoom In,
 it says Controlplus, which sounds right, but it should really say
 ControlShiftplus, since you have to press Shift to get the plus
 symbol. The correct default keybinding for Zoom In should be
 Controlequal, if it's to be like the vast majority of other software
 that supports zooming.
 
 Is anybody opposed to me correcting this?

I don't ack.  IMHO, ctl+ is the right keybinding and the fact some
apps handle ctl= just like ctl+ is only a facility and/or a
compatibility thing maybe.  E.g., Firefox simply accepts ctl+ or
ctl= interchangeably, but I never actually used ctl= since I didn't
though it even worked.

Also, I don't think that speaking of ctlshift+ is right, because the
fact + is available through shift on qwerty/azerty keyboards should
not matter to the app or even the user.  If typing ctl+ requires using
shift, fair enough.  If it doesn't that's fine.

Moreover, how would then be handled the keypad keys?  Currently they we
simply map them to the normal keys, eg KP_plus is the same as
plus.  With your proposal, how would you use the keypad to zoom
in/out?  I guess you couldn't since there isn't an equal sign on the keypad.
Ah, and that's also against the ctlshift+ representation since
there's no shift to access + on the keypad.


So you probably got it: I don't think it's a good idea.  BTW, for the
record, what are the applications using the normal keybinding you'd
like to see (^=)?

A few I have under the hand:
 * Mozilla products allows both
 * gnome-terminal only accepts ctl+ (no kp support)


Cheers,
Colomban

 
 P.S. I'm only talking about US-like keyboards here, since that's all
 I've ever used.
 
 Cheers,
 Matthew Brush
 ___
 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] C++ Symbols problem

2012-03-17 Thread Colomban Wendling

Le 16/03/2012 11:30, Lex Trotman a écrit :
 Hi All,

Hey,

I haven't had the time yet to try to fix the sidebar bug, but...

 So that I don't look unreasonable for criticising just Geany I

Sweet :p

 [...]
 
 In fact it would even be better if . and - autocomplete was turned
 off for C++ rather than offering complete crap (and that isn't related
 to this particular file unfortunately).

Try the attached patch maybe.  It's not really polished and I haven't
published it because it's not really the right fix, but if scope
completion is *that* broken with C++ maybe it's worth committing this at
least as an interim solution 'till I manage to get another tagmanager
impl working [1].  That patch is a reimpl of the feature that at least I
can understand (no TM stuff, heh), and it shows quite good results at
least for C (and smaaal C++ tests).


Cheers,
Colomban


[1] It's somewhat on the way, but it's far from being trivial work and I
have/had some non-geany stuff lately, so I wasn't able to work on this
that much

 As my brain is now drained from all those, I leave it to someone else
 to suggest some idea of a path forward.
 
 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] C++ Symbols problem

2012-03-17 Thread Colomban Wendling

Le 17/03/2012 15:28, Colomban Wendling a écrit :
 Le 16/03/2012 11:30, Lex Trotman a écrit :
 Hi All,
 
 Hey,
 
 I haven't had the time yet to try to fix the sidebar bug, but...
 
 So that I don't look unreasonable for criticising just Geany I
 
 Sweet :p
 
 [...]

 In fact it would even be better if . and - autocomplete was turned
 off for C++ rather than offering complete crap (and that isn't related
 to this particular file unfortunately).
 
 Try the attached patch maybe.

Hum, it'd be easier with an attachment.  Here it is.


 It's not really polished and I haven't
 published it because it's not really the right fix, but if scope
 completion is *that* broken with C++ maybe it's worth committing this at
 least as an interim solution 'till I manage to get another tagmanager
 impl working [1].  That patch is a reimpl of the feature that at least I
 can understand (no TM stuff, heh), and it shows quite good results at
 least for C (and smaaal C++ tests).
 
 
 Cheers,
 Colomban
 
 
 [1] It's somewhat on the way, but it's far from being trivial work and I
 have/had some non-geany stuff lately, so I wasn't able to work on this
 that much
 
 As my brain is now drained from all those, I leave it to someone else
 to suggest some idea of a path forward.

 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

From a96669230b860ae3229150715ff65621d3c37657 Mon Sep 17 00:00:00 2001
From: Colomban Wendling b...@herbesfolles.org
Date: Tue, 23 Aug 2011 02:20:11 +0200
Subject: [PATCH] First attempt at fixing scope completion

Actually it's a re-implementation that looks pretty well working.
---
 src/editor.c |  204 -
 1 files changed, 186 insertions(+), 18 deletions(-)

diff --git a/src/editor.c b/src/editor.c
index 67dd295..739c940 100644
--- a/src/editor.c
+++ b/src/editor.c
@@ -683,14 +683,190 @@ static void request_reshowing_calltip(SCNotification *nt)
 }
 
 
+/* mostly stolen from tm_workspace.c:match_langs() */
+static gboolean lang_matches(const TMTag *tag, langType lang)
+{
+	if (lang == -1)
+		return TRUE;
+
+	if (tag-atts.entry.file)
+	{	/* workspace tag */
+		if (lang == tag-atts.entry.file-lang)
+			return TRUE;
+	}
+	else
+	{	/* global tag */
+		if (lang == tag-atts.file.lang)
+			return TRUE;
+	}
+	return FALSE;
+}
+
+
+/* gets the real type of @name_orig by resolving the typedefs
+ * @file: (in/out) the preferred TMSourceFile, will be filled with the TMSourceFile in which the
+ *   returned is found. This may point to @NULL, but cannot be a NULL pointer */
+static const gchar *resolve_typedef(TMWorkObject **file, const gchar *type_name, langType lang)
+{
+	const TMWorkspace *ws = tm_get_workspace();
+	guint i, pass = 0;
+	GPtrArray *tag_arrays[3];
+	gboolean again;
+
+	g_return_val_if_fail(file != NULL, NULL);
+	g_return_val_if_fail(type_name != NULL, NULL);
+
+	tag_arrays[0] = (*file) ? (*file)-tags_array : NULL;
+	tag_arrays[1] = TM_WORK_OBJECT(ws)-tags_array;
+	tag_arrays[2] = ws-global_tags;
+
+	do
+	{
+		again = FALSE;
+
+		g_debug(resolving %s..., type_name);
+		for (i = 0; i  G_N_ELEMENTS(tag_arrays); i++)
+		{
+			const TMTag *tag;
+			guint j;
+
+			if (! tag_arrays[i] || tag_arrays[i]-len  1)
+continue;
+
+			foreach_ptr_array(tag, j, tag_arrays[i])
+			{
+if (! lang_matches(tag, lang))
+	continue;
+
+if (tag-type  tm_tag_typedef_t  strcmp(type_name, tag-name) == 0 
+	tag-atts.entry.var_type  strcmp (type_name, tag-atts.entry.var_type) != 0)
+{
+	type_name = tag-atts.entry.var_type;
+	/* we need to resolve the new name in case it is typedefed again, trying the
+	 * file containing the typedef first */
+	again = TRUE;
+	*file = TM_WORK_OBJECT(tag-atts.entry.file);
+	tag_arrays[0] = (*file) ? (*file)-tags_array : NULL;
+	break;
+}
+			}
+		}
+		pass++;
+	}
+	while (again  pass = 8);
+	/* 8 is an arbitrary limit not to loop infinitely on recurive self-referencing typedefs */
+
+	g_debug(resolved to %s., type_name);
+	return type_name;
+}
+
+
+/* tries to find children of type @type_name
+ * @file: the preferred TMSourceFile (e.g. the one containing the type definitions) */
+static GPtrArray *find_type_children(TMWorkObject *file, const gchar *type_name, langType lang)
+{
+	const TMWorkspace *ws = tm_get_workspace();
+	guint i;
+	gsize len;
+	const GPtrArray *tag_arrays[3];
+	GPtrArray *children = NULL;
+
+	g_return_val_if_fail(type_name != NULL, NULL);
+
+	g_debug(searching children for %s..., type_name);
+
+	type_name = resolve_typedef(file, type_name, lang);
+	len = strlen(type_name);
+
+	tag_arrays[0] = file ? file-tags_array : NULL;
+	tag_arrays[1] = TM_WORK_OBJECT(ws)-tags_array;
+	tag_arrays[2] = ws

Re: [Geany-devel] C++ Symbols problem

2012-03-17 Thread Colomban Wendling

Le 13/03/2012 01:48, Lex Trotman a écrit :
 Hi All,

Hey!

Here's an initial patch that fixes the issue by better handling of true
duplicate tags.  It's not necessarily the better fix for the issue,
where maybe having the template type info would be better, but it is
more generic since it would handle any duplicate.

It's not much tested, but have fun :)

Cheers,
Colomban


 
 There is a problem with symbols in some C++ programs which causes some
 class members to appear and disappear or move in the sidebar.
 Needless to say this is *very* distracting.
 
 The minimal program to demonstrate this is:
 
 templatebool bclass problem;
 
 template class problemfalse {
 };
 
 template class problemtrue {
   int i_change;
 };
 
 
 The member i_change changes each time the symbols pane is updated,
 correctly showing as part of the class at line 6, then part of the
 class at line 3, then disappearing, then back to the class at line 6
 etc.
 
 In C++ this program has three class names:
 
 a) at line 1 declaration of problembool
 b) at line 3 definition of problemfalse
 c) at line 6 definition of problemtrue
 
 Note that these are distinct classes as if the names include bool,
 true and false.
 
 But neither symbols.c or the tagmanager parser includes the template
 parameters in the name, instead showing both of the classes at line 3
 and 6 as problem.
 
 Discussion with Colomban on IRC indicated that this may be confusing
 the symbol update algorithm.  Forcing a complete re-generation of the
 symbols did indeed stabilise the sidebar.
 
 I think that the problem is due to update_tree_tags() identifying the
 parent of i_change just by name so it can't tell if line 3 or line 6
 (or possibly line 1) is the parent.
 
 If  i_change is shown in the symbol tree as part of the class at line
 6 then it will be in the parent_tags hash with parent of problem.
 If this is taken as problemof line 3 as parent, it will delete it
 from the class at line 6 in pass 1 and as i_change is still in the
 tags list will add it to the class at line 3 since thats what the
 parent_tags hash says is its parent.
 
 On the next symbol update, since what it thinks is the parent of
 i_change (the class at line 3) does not in fact have i_change as a
 member, it will be deleted from the tree and the tags list, so it
 isn't added again in pass 2.
 
 On the next symbol update i_change is not in the tree so it isn't in
 the parent_tags hash so it is added where the tags list says is the
 correct place.
 
 If the order of the definitions at line 3 and 6 are reversed i_change
 just alternates on and off, suggesting that it isn't the first
 definition of the symbol problem that is the one found.
 
 At least I think this is the mechanism?
 
 Other than the hack to re-create the whole table each time, I'm not
 sure how to cure it without distinguishing the three class names, and
 that means modifying tagmanager/c.c (shudder).
 
 Cheers
 Lex
 ___
 Geany-devel mailing list
 Geany-devel@uvena.de
 https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

diff --git a/src/symbols.c b/src/symbols.c
index ff9c210..a055081 100644
--- a/src/symbols.c
+++ b/src/symbols.c
@@ -1258,21 +1258,105 @@ static gboolean tree_store_remove_row(GtkTreeStore *store, GtkTreeIter *iter)
 }
 
 
-/* updates @table adding @tag-name:@iter if necessary */
+/* adds a new element in the parent table if it's key is known
+ * duplicates are kept */
 static void update_parents_table(GHashTable *table, const TMTag *tag, const gchar *parent_name,
 		const GtkTreeIter *iter)
 {
-	if (g_hash_table_lookup_extended(table, tag-name, NULL, NULL) 
+	GList **list;
+	if (g_hash_table_lookup_extended(table, tag-name, NULL, (gpointer *) list) 
 		! utils_str_equal(parent_name, tag-name) /* prevent Foo::Foo from making parent = child */)
 	{
-		g_hash_table_insert(table, tag-name, g_slice_dup(GtkTreeIter, iter));
+		if (! list)
+		{
+			list = g_slice_alloc(sizeof *list);
+			*list = NULL;
+			g_hash_table_insert(table, tag-name, list);
+		}
+		*list = g_list_prepend(*list, g_slice_dup(GtkTreeIter, iter));
+	}
+}
+
+
+static void free_iter_slice_list(gpointer data)
+{
+	GList **list = data;
+
+	if (list)
+	{
+		GList *node;
+		foreach_list(node, *list)
+			g_slice_free(GtkTreeIter, node-data);
+		g_list_free(*list);
+		g_slice_free1(sizeof *list, list);
 	}
 }
 
 
-static void free_iter_slice(gpointer iter)
+/* inserts a @data in @table on key @tag
+ * previous data is not overwritten if the key is duplicated, but rather the
+ * two values are kept in a list
+ * 
+ * table is: TMTag:GSListGListTMTag */
+static void tags_table_insert(GHashTable *table, TMTag *tag, GList *data)
 {
-	g_slice_free(GtkTreeIter, iter);
+	GList *list = g_hash_table_lookup(table, tag);
+	list = g_list_prepend(list, data);
+	g_hash_table_insert(table, tag, list);
+}
+
+
+/* looks up the entry in @table that matches @tag the better
+ * if there are more than one candidate, the one

Re: [Geany-devel] Fwd: Security issue in Terminal

2012-03-08 Thread Colomban Wendling

Le 08/03/2012 17:31, Johann SAUNIER a écrit :
 Which distros are still mounting /tmp on the hard drive rather than on a
 tmpfs file system ?

Not Debian Sid obviously:

$ /bin/df -h /tmp/
Filesystem  Size  Used Avail Use% Mounted on
tmpfs   767M   67M  700M   9% /tmp

...but Debian Stable does:

$ /bin/df -h /tmp/
Filesystem  Size  Used Avail Use% Mounted on
/dev/... 19G  3.8G   14G  22% /

 Le 8 mars 2012 00:20, Matthew Brush mbr...@codebrainz.ca
 mailto:mbr...@codebrainz.ca a écrit :
 
 
 Hi all,
 
 Just forwarding this along from the Xfce list as Geany (and many
 other programs) also use this same library for the Terminal feature.
 I'm not convinced it's a big deal, but none-the-less users should be
 aware of it. See the link in the forwarded message for more information.

I don't think it's really a big deal with Geany's terminal in which I
doubt users could do much sensible enough stuff.  However yes, it's
probably worth a note, maybe in the manual.  Though, as Johann pointed
out, at least some distros are mounting tmpfs on /tmp by default so
aren't affected by the issue.


Regards,
Colomban

 
 Cheers,
 Matthew Brush
 
 
  Original Message 
 Subject: Security issue in Terminal
 Date: Wed, 07 Mar 2012 11:28:58 -0500
 From: David Rosenstrauch darose   darose.net http://darose.net
 Reply-To: Xfce general discussion list x...@xfce.org
 mailto:x...@xfce.org
 To: x...@xfce.org mailto:x...@xfce.org
 
 Has there already been a bug report filed for this security issue in
 Terminal?
 
 
 http://www.climagic.org/__bugreports/libvte-scrollback-__written-to-disk.html
 
 http://www.climagic.org/bugreports/libvte-scrollback-written-to-disk.html
 
 Thanks,
 
 DR
 _
 Xfce mailing list
 x...@xfce.org mailto:x...@xfce.org
 https://mail.xfce.org/mailman/__listinfo/xfce
 https://mail.xfce.org/mailman/listinfo/xfce
 http://www.xfce.org
 _
 Geany-devel mailing list
 Geany-devel@uvena.de mailto:Geany-devel@uvena.de
 https://lists.uvena.de/cgi-__bin/mailman/listinfo/geany-__devel
 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

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

Re: [Geany-devel] small leak in keyfile.c

2012-03-08 Thread Colomban Wendling

Le 08/03/2012 18:06, Dimitar Zhekov a écrit :
 Hi,
 
 configuration_reload_default_session() does not free configfile.
 Patch attached.

Thanks, committed.

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

Le 04/03/2012 02:01, Jiří Techet a écrit :
 On Mon, Feb 27, 2012 at 08:33, Matthew Brush mbr...@codebrainz.ca wrote:
 On 12-02-26 11:20 PM, Frank Lanitz wrote:

 Hi folks,

 Just something I thought on last merges based on Jiri's patches. Its
 hard to understand what this merges do just by reading the commit
 message. Given, that we want to create the ChangeLog based on git log it
 will be nearly impossible to create a good ChangeLog/Newsfile if we
 don't keep care. Not sure how, but can we be more verbose here?


 [snip]

 Just to give everyone who hasn't checked the commits an idea of the
 verbosity that those commit messages has.
 
 Is it too verbose? I was trying to add some more detailed info because
 from my experience even though the patch seems to be clear now, when
 looking at it one year later I often feel like what does the hell the
 patch do? and why did I write something like that?. But if it's the
 preferred way I can move the explanation into the merge comment on
 github.

Nope, it's fine IMO  --  and I think Matthew quoted them just to tell
Frank that despite the unclear merge message the commits themselves were
well explained.

 By the way, because the patches I submitted weren't related in any
 way, I think they could have been rebased on top of master instead of
 doing merge.

Agreed, I prefer not to see merges where there's no relation between
several (2+) commits.

Cheers,
Colomban

 
 Cheers,
 Jiri
 ___
 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] Commit messages on merges

2012-03-03 Thread Colomban Wendling

Le 28/02/2012 06:59, Frank Lanitz a écrit :
 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.
 
 It's not git. It's most likely githubs's webinterface which is causing
 the entries I'm not happy about. Using command line git merge -m I just
 did some cool stuff would be a bit better. Now git log e.g. looks like

I agree that the merge commits should be a bit informative on what they
do, but the branch name should be a good starting point.  In the two
examples below the branch name make me clearly think that those
branches (actually pull simply requests I guess) simply holds random
stuff that doesn't depend on each other.  I guess if Jiří made a single
PR it's more because he though having one per commit was overkill rather
than because these commits had strong relationship.

Maybe the project_patches one has some semantic, but I doubt fixes
does.

 commit 3bcd7fc40078efd601f0e9bed8efec971d505db2
 Merge: 3d4e8b4 5cc8a96
 Author: Matthew Brush mbr...@codebrainz.ca
 Date:   Sun Feb 26 21:04:50 2012 -0800
 
 Merge pull request #19 from techee/fixes
 
 Fixes
 
 commit 3d4e8b41d419255ee1b0764fb60e45ea588bd800
 Merge: d7d5a6d ca9dca9
 Author: Matthew Brush mbr...@codebrainz.ca
 Date:   Sun Feb 26 20:50:01 2012 -0800
 
 Merge pull request #25 from techee/project_patches
 
 Project patches
 
 
 The alternative is to always re-base before committing merged branches
 to master, which is probably better since we don't care how the
 developer got to the end point and all the commits and merges she made
 on the way, we just care what the commit to master does.
 
 No. This will remove most probably of e.g. additional contributors.

Rebasing doesn't lose authorship information, it just loses original
commits hierarchy.  Sometimes this hierarchy is useful (like join_lines
patches which makes a whole) and sometimes it is just useless stuff that
makes the history less readable (like Jiří's fixes branch where each
commit is a whole without relationship with the other).

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


Regards,
Colomban

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

Re: [Geany-devel] Line operations

2012-02-23 Thread Colomban Wendling

Le 23/02/2012 11:08, Eugene Arshinov a écrit :
 On Mon, 6 Feb 2012 11:55:25 +0400
 Eugene Arshinov earshi...@gmail.com wrote:
 
 On Sun, 05 Feb 2012 20:50:38 +0100
 Colomban Wendling lists@herbesfolles.org wrote:

 Le 05/02/2012 13:51, Eugene Arshinov a écrit :
 Hello all.

 [snip]

 2) I want to raise a question, do we need a join lines command?
 This command would be a companion of the existing reflow
 paragraph command, but in contrast with the latter, it would
 only join lines, but not split them.

 This command may be useful when, let's say, you have a document
 created by someone else who sticks with line breaking and inserts
 \n at column 80.  Suppose that you prefer using line wrapping
 instead and want to remove those \n in a peace of a document which
 you're editing.  The new command would help you a bit.

 Implementation of the new join lines command could use the bits
 of code already written for reflow paragraph (though, those bits
 need to be extracted/refactored first).  Moreover, I already
 implemented it and, if the new command seems useful to anyone, I
 can put my implementation in a pull request.

 Not sure I see a use case for this (read: I probably wouldn't use it
 if it simply removes the EOLs), but why not if some wants it.  But
 maybe Scintilla already have a message for it and thus we'd only
 need to use it?


 As Lex already wrote, there is SCI_LINESJOIN.  And that's the command
 which is already used in Geany to implement reflow paragraph (to be
 more precise, two commands are used: LINESJOIN and LINESSPLIT).

 By the way, here is a related discussion: [Geany-devel] Support
 SCI_LINESJOIN and SCI_LINESSPLIT (patch included) [1].  The first
 message is authored by me :)

 [1]: http://lists.uvena.de/geany-devel/2009-July/000834.html

 
 I created pull request #26 [2] containing the implementation of the new
 Join lines command so that it won't get lost.

Good thing, since I finally took a look at it :)
A few remarks on the PR

Cheers,
Colomban

 
 [2]: https://github.com/geany/geany/pull/26
 
 --
 Best regards,
 Eugene.
 ___
 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] Some obsolete(?) bug reports

2012-02-22 Thread Colomban Wendling

Le 21/02/2012 19:06, Dimitar Zhekov a écrit :
 On Mon, 20 Feb 2012 21:00:44 +0100
 Colomban Wendling lists@herbesfolles.org wrote:
 
 To run a second instance of Geany, do not specify any filenames on
 the command-line, [...]

 This should be reworded since it's not true since a long time one
 need explicit -i, isn't it?  Or do I get the sentence wrong?
 
 Well, maybe secondary instead of second, since I used subsequent
 in the previous paragraph.
 
 -i is required only if you want to open CL files in a new instance,
 instead of passing them to an already running one (explained under
 Command line options before Startup). If you have a Geany, and
 start another from, say, your DE menu (i.e. without CL), it becomes
 (new instance) automatically.

Hum ok, that's true, my bad.  I actually never launch a second geany
without files nor -i so... :-'

So the patch is fine, I applied it thanks.

Cheers,
Colomban


___
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-22 Thread Colomban Wendling

Le 21/02/2012 05:15, Lex Trotman a écrit :
 In another thread
 http://lists.uvena.de/geany/2012-February/007808.html a couple of
 things were mentioned about guidelines for plugins to be good
 citizens.  So I thought it worthwhile gathering any suggestions so the
 docs could be updated in one go.
 
 Items mentioned to date:
 
 1. don't set default keybindings, users will be annoyed if you
 override their personal bindings.  Always let the user tell the plugin
 what to use.

I'm not convinced that saying not set default is the best solution to
the conflict problem.  Couldn't Geany simply not override an already
existent keybinding when installing a plugin's one?

 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.

I'm not sure about this one either, though I understand that too many
items everywhere may become a problem.

But if the plugin provides a feature like, say, uniqueness (ref. thread
in the general ml), the menu would better fit in edit-format or
something;  and e.g. GeanyGenDoc places an item in editor context
menu-insert.
IMO this makes the UI better than fulfilling the tools menu with various
stuff, since it's the appropriate place for such an item.

I understand that if 10k plugins adds items in various menus it'd start
to be annoying, but OTOH, is a tool menu with 10k items really better?


Cheers,
Colomban

 I add the following for consideration:
 
 3. be aware of the performance, especially if your plugin does
 something on every keystroke or change or at startup, other plugins
 are likely to want to as well.  Just because the plugin works ok or
 your computer by itself doesn't mean it will work well when the user
 combines it with 15 others on their old notebook and they have heaps
 of files open.
 
 And on the development side, these have been mentioned before
 ad-nauseum but still need emphasis:
 
 4. make your plugin compile clean with -Wall -Wextra -O2
 -Wno-unused-parameter with and without -ansi, and 64bit clean
 5. don't use anything not *documented* in the plugin interface, a
 change in Geany can make your plugin fail if you do.  But you are
 protected against changes in the interface.
 
 Any other thoughts?
 
 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] Some obsolete(?) bug reports

2012-02-20 Thread Colomban Wendling

Le 20/02/2012 18:34, Dimitar Zhekov a écrit :
 On Sat, 18 Feb 2012 14:17:17 +0100
 Colomban Wendling lists@herbesfolles.org wrote:
 
 So I'd say aye to Dimitar since he gently volunteered :)  Moreover
 if it is a preference I don't see any loss; but I'd better see this
 preference turned on by default for new configurations if the restore
 session one is on.
 
 Here's the patch. There is no additional preference - if Load files
 from the last session is checked, they are loaded, and that's it.
 Though it'll be easy to make it a pref...

Thanks a lot, committed.  Maybe an update of the manual to explain more
it needed?  Though anyway I think new behavior is much more expected so
that manual would be less read anyway :)

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

Re: [Geany-devel] Line operations

2012-02-20 Thread Colomban Wendling

Le 19/02/2012 20:01, Eugene Arshinov a écrit :
 On Sun, 19 Feb 2012 17:24:00 +0100
 Colomban Wendling lists@herbesfolles.org wrote:

 [...]
 
 The commands indeed work similarly to our own `move_lines`
 function.  I posted pull request #24 [3] which removes `move_lines`
 function and leverages the commands.  I hope it can be committed so
 that I can switch my effort of improving Move lines feature from
 Geany to Scintilla.

 Looks fine to -- apart of course it doesn't fix the initial problem
 yet. At least so there would be only one copy of the functionality.

 So just to be sure we understand each other: I drop your previous pull
 request (#21), apply this one (#24) and wait for your patch to be in
 Scintilla?

 
 Yes.  But I don't promise that I'll post a request to Scintilla *soon*…

No big deal IMO regarding how long this bug existed without any reports
about it.  See, while I use the feature quite often, I ran into the bug
only once in real situation.

So, it's now applied;  Waits for Scintilla update :)

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

Re: [Geany-devel] Some obsolete(?) bug reports

2012-02-20 Thread Colomban Wendling

Le 20/02/2012 20:29, Dimitar Zhekov a écrit :
 On Mon, 20 Feb 2012 20:00:38 +0100
 Colomban Wendling lists@herbesfolles.org wrote:
 
 Thanks a lot, committed.  Maybe an update of the manual to explain
 more it needed?
 
 Yes... An update is required because the manual explicitly says if
 you specify CL files, only they will be opened, and refers the user
 to Recent files. So I altered the Startup section a bit.

Thanks for that update again :)

To run a second instance of Geany, do not specify any filenames on
the command-line, [...]

This should be reworded since it's not true since a long time one need
explicit -i, isn't it?  Or do I get the sentence wrong?

Cheers,
Colomban

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

Re: [Geany-devel] Some obsolete(?) bug reports

2012-02-19 Thread Colomban Wendling

Le 19/02/2012 16:42, Enrico Tröger a écrit :
 Hey guys,
 
 
 1. Incorrect indentation guides - ID: 2637071 [1]

 I opened the attached document and did not see any issues with
 indentation guides.  I could miss something because I rarely use the
 guies, but...  Maybe it was already fixed in Scintilla?

 Enrico replied to this report in 2009.


 I think this bug is still present if I understand it correctly. The
 attached file causes indentation guides to be shown on the blank line
 that has no indentation at all.
 
 I can't reproduce it here, see attached screenshot.
 Maybe it's related to some preferences set?

I think you just don't have indent guides enabled ;)

 
 
 Regards,
 Enrico
 
 
 
 ___
 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] Some obsolete(?) bug reports

2012-02-19 Thread Colomban Wendling

Le 19/02/2012 01:06, Lex Trotman a écrit :
 [...]

 I just taught the file mangler to run geany -c so it never interrupts
 what a normal Geany is doing :)

 I don't think that's something everybody should need to do.

 
 Yes, true.
 
 [...]
 I personally do think what we do is definitely the Wrong Thing.
 Honestly, I always have found this behavior very counter-intuitive and
 not helpful.  I mean, if I tell Geany to restore my session, I expect it
 to be restored whenever I start Geany, not only in some cases.

 
 Looking at it like that, then the current behaviour is wrong.
 
 I also checked a few other apps and all restore past sessions and add
 the new file to it, so I would say this is the behaviour a user would
 expect.
 
 
 OK, for me it's not a real problem since I always have one or more Geany
 instance open, but remembering the early times I did unexpectedly lost
 some session data because of this behavior.

 To summarize, I think that the current behavior will most likely NOT be
 the expected one and will disturb most users.  See, even us do
 workaround that in some ways, either using -c or having an instance
 always open.
 
 Or both, so I *never* saw it as a problem :)
 

 So I'd say aye to Dimitar since he gently volunteered :)  Moreover if
 it is a preference I don't see any loss; but I'd better see this
 preference turned on by default for new configurations if the restore
 session one is on.

 
 Colomban has been so persuasive

Hehe :D

 that I don't even think it needs
 another option, the suggested behaviour is non-destructive, so why not
 just turn restoring sessions on or off.

Agreed, another pref isn't needed, either always restore or never
restore should be enough; IMO too.

Sounds reasonable to everybody?

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

Re: [Geany-devel] Line operations

2012-02-19 Thread Colomban Wendling

Le 19/02/2012 08:02, Eugene Arshinov a écrit :
 Hi there.

Hi Eugene,

 
 Quick overview - I posted a pull request [3] which removes `move_lines`
 function and uses commands already available in Scintilla.  See below.
 
 On Sun, 05 Feb 2012 20:50:38 +0100
 Colomban Wendling lists@herbesfolles.org wrote:
 
 Le 05/02/2012 13:51, Eugene Arshinov a écrit :
 Hello all.

 Hey Eugene,

 I have several suggestions and questions about certain line
 operations implemented in Geany.

 1) Recently I found that move lines up/down command does not work
 properly for the last line not ending with a newline.  You can
 easily check it yourself.  Couple of minutes ago I made a pull
 request [1] with an implementation of `editor.c:move_lines()` which
 handles the problem.  Dear unknown someone, please review and pull
 if it's okay.

 I know this problem, but it needed a so big code refactoring it hurts
 (I want as a proof the fact your rewrite is... huge), so... I just
 postponed it.  Ok, shame on me.

 I haven't reviewed the new code yet, but I'll do.  Just as a note,
 Scintilla has a command to do that that suffers (suffered?) of the
 exact same bug we had.  Maybe it'd be good to fix their copy and use
 the SCI message in place of our code.

 [snip]
 
 I didn't find those Scintilla commands (SCI_MOVESELECTEDLINES{UP,DOWN}
 to be precise) because they are not mentioned in the official Scintilla
 documentation [1], though they are of course mentioned in Scintilla.h.
 For completeness, here is the feature request for Scintilla where those
 commands came from - [2].

It is in the docs:
http://www.scintilla.org/ScintillaDoc.html#SCI_MOVESELECTEDLINESUP

 The commands indeed work similarly to our own `move_lines` function.  I
 posted pull request #24 [3] which removes `move_lines` function and
 leverages the commands.  I hope it can be committed so that I can
 switch my effort of improving Move lines feature from Geany to
 Scintilla.

Looks fine to -- apart of course it doesn't fix the initial problem yet.
 At least so there would be only one copy of the functionality.

So just to be sure we understand each other: I drop your previous pull
request (#21), apply this one (#24) and wait for your patch to be in
Scintilla?


Regards,
Colomban

 
 [1]:http://www.scintilla.org/ScintillaDoc.html
 [2]:https://sourceforge.net/tracker/?func=detailaid=3304850group_id=2439atid=352439
 [3]:https://github.com/geany/geany/pull/24
 
 --
 Best regards,
 Eugene.
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] Some obsolete(?) bug reports

2012-02-18 Thread Colomban Wendling

Sorry for the long delay, I was busy last week (OK, no one cares anyway)

Le 18/02/2012 02:45, Lex Trotman a écrit :
 On 18 February 2012 12:13, Matthew Brush mbr...@codebrainz.ca wrote:
 On 02/17/2012 09:42 AM, Dimitar Zhekov wrote:

 On Mon, 13 Feb 2012 17:14:19 -0800
 Matthew Brushmbr...@codebrainz.ca  wrote:

 3. geany xyz.txt does not load files from session - ID: 2838686 [3]

 Here it wasn't decided whether of not Geany should restore session.  I
 suggest we discuss this question and finally either fix the bug or mark
 it as WONTFIX.


 I don't often use Geany for opening files from the command line and
 usually I always have a Geany window open so if I do, it's not an issue,
 so I can't really provide a worthwhile opinion here.


 As the bug report states, opening a file _with your file manager_ or
 CLI loses the last [default] session [if no geany is running]. The
 complaints we usually got were I double-clicked foo.c and lost my
 session, to which we usually replied use projects. So this affects
 the GUI, even more than CLI.


 
 I just taught the file mangler to run geany -c so it never interrupts
 what a normal Geany is doing :)

I don't think that's something everybody should need to do.

 Yeah, I don't usually do that either. I almost always have an instance of
 Geany running on my 2nd monitor and if not, I'm usually not surprised by the
 behaviour since I do use projects mostly unless I'm just quickly editing a
 file or two.


 Why not have a vote and finally implement or wontfix it? I volunteer to
 write the preference, as a graphical or vaiouus preference, if we decide
 aye.


 
 Since there is no always right answer as to how Geany should react
 I'd say wont change since we have well known documented behaviour
 already.

I personally do think what we do is definitely the Wrong Thing.
Honestly, I always have found this behavior very counter-intuitive and
not helpful.  I mean, if I tell Geany to restore my session, I expect it
to be restored whenever I start Geany, not only in some cases.

OK, for me it's not a real problem since I always have one or more Geany
instance open, but remembering the early times I did unexpectedly lost
some session data because of this behavior.

To summarize, I think that the current behavior will most likely NOT be
the expected one and will disturb most users.  See, even us do
workaround that in some ways, either using -c or having an instance
always open.

So I'd say aye to Dimitar since he gently volunteered :)  Moreover if
it is a preference I don't see any loss; but I'd better see this
preference turned on by default for new configurations if the restore
session one is on.


That's my POV of course :)

Cheers,
Colomban


 
 Cheers
 Lex
 
 I have no opposition to this, though I wouldn't even know which way to vote.
 Why not setup one of those online polls and send a message to the mailing
 list(s) and see what happens?

 Cheers,
 Matthew Brush

 ___
 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

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

Re: [Geany-devel] Line operations

2012-02-05 Thread Colomban Wendling

Le 05/02/2012 13:51, Eugene Arshinov a écrit :
 Hello all.

Hey Eugene,

 I have several suggestions and questions about certain line operations
 implemented in Geany.
 
 1) Recently I found that move lines up/down command does not work
 properly for the last line not ending with a newline.  You can easily
 check it yourself.  Couple of minutes ago I made a pull request [1]
 with an implementation of `editor.c:move_lines()` which handles the
 problem.  Dear unknown someone, please review and pull if it's okay.

I know this problem, but it needed a so big code refactoring it hurts (I
want as a proof the fact your rewrite is... huge), so... I just
postponed it.  Ok, shame on me.

I haven't reviewed the new code yet, but I'll do.  Just as a note,
Scintilla has a command to do that that suffers (suffered?) of the exact
same bug we had.  Maybe it'd be good to fix their copy and use the SCI
message in place of our code.


 [1]: https://github.com/geany/geany/pull/21
 
 2) I want to raise a question, do we need a join lines command?  This
 command would be a companion of the existing reflow paragraph
 command, but in contrast with the latter, it would only join lines, but
 not split them.
 
 This command may be useful when, let's say, you have a document created
 by someone else who sticks with line breaking and inserts \n at column
 80.  Suppose that you prefer using line wrapping instead and want to
 remove those \n in a peace of a document which you're editing.  The new
 command would help you a bit.
 
 Implementation of the new join lines command could use the bits of
 code already written for reflow paragraph (though, those bits need to
 be extracted/refactored first).  Moreover, I already implemented it
 and, if the new command seems useful to anyone, I can put my
 implementation in a pull request.

Not sure I see a use case for this (read: I probably wouldn't use it if
it simply removes the EOLs), but why not if some wants it.  But maybe
Scintilla already have a message for it and thus we'd only need to use it?


Regards,
Colomban

 3) Here there should have been a point about some bug reports we have
 in Geany bug tracker, referring to reflow paragraph glitches.  As
 this message is already too long, I decided to designate a separate
 message for that (later).
 
 Thank you for reading :)  Please write your thoughts about 1) and 2)
 
 --
 Best regards,
 Eugene.
 ___
 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] Opening unmounted GIO URIs

2012-02-02 Thread Colomban Wendling

Le 31/01/2012 20:14, Enrico Tröger a écrit :
 On Tue, 31 Jan 2012 01:30:58 +0100, Colomban wrote:
 
 Ho Colomban and the rest,
 
 https://github.com/b4n/geany/commit/01fd682674286dada6d6b77d0e3064c89a28df64

 I wrote this patch that adds automatic mounting of volumes needed to
 open a GIO URI, so one don't have to first mount the corresponding
 volume in Nautilus/whatever.  This make opening arbitrary URIs from the
 
 whatever = Gigolo!
 
 :)
 
 
 I'm quite confident mounting the volume is a good idea in theory, but
 there is a small thing making it a bit tricky: GIO doesn't seem to
 provide a synchronous API to do that.

 So, it either requires the calling code to be asynchronous (which we
 don't have yet and that don't fit well with current code), or to hack
 around to make the asynchronous code look synchronous.

 I did the latter, and that's basically the reason why I post this mail:
 do you think it's too ugly, too useless, too something?
 
 I basically like the idea.
 If I remember correctly, the relevant code is also called when starting
 Geany and the main GUI isn't yet shown. If so, I see one
 big problem: 

Actually opening from CLI is ~ the only way to trigger the code since
most other would need the volume to be already mounted.  So startup and
remote control.

 if the mount won't finish in a short time, the user doesn't know what's
 happening and probably only notices that Geany doesn't start because no
 GUI is shown.
 So, I think at the very least we would need some sort of timeout, a
 short timeout, to cancel the mount operation if it takes too long. Not
 sure what exactly is 'too long', maybe a few seconds.
 Or even better (and more complex) we would show the user a dialog with
 a pulsing progressbar or so stating that a mount operation is in
 progress. A cancel button would be a big bonus but probabaly not
 necessarily needed.

Good point, here you go with a dialog, pulse  cancel:
https://github.com/b4n/geany/commit/540e6b28d8ce461b44f6fd4dce32c38167bca99b

Having a modal dialog also has the advantage of blocking user
interaction on the main window, addressing a part of Lex's worries.

Just as a funny note, implementing all this required some more hackery
because GVfsDaemon (bridge of all remote FS) doesn't actually honor
cancellation even though the API is supposed to provide it.


So, here it is with a progress dialog  cancellation support.  I tested
it a bit, particularly the opening a second URI from the CLI while
waiting to mount a first one, and it looked like it worked fine: mounted
the stuff and/or asked for details, each after the other, no weird
concurrency.
Though, if anyone wants to test it a bit more, it can't be wrong.

Comments still welcome of course :)


Cheers,
Colomban

 
 
 Regards,
 Enrico
___
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-02 Thread Colomban Wendling

Le 31/01/2012 02:04, Lex Trotman a écrit :
 On Tue, Jan 31, 2012 at 11:30 AM, Colomban Wendling
 lists@herbesfolles.org wrote:
 Hey Nick, Matthew, Lex, Frank, Enrico, whoever cares,

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

 I wrote this patch that adds automatic mounting of volumes needed to
 open a GIO URI, so one don't have to first mount the corresponding
 volume in Nautilus/whatever.  This make opening arbitrary URIs from the
 CLI easier, though it's probably not needed when using a file manager
 (who would've already mounted the volume to browse it).

 I'm quite confident mounting the volume is a good idea in theory, but
 there is a small thing making it a bit tricky: GIO doesn't seem to
 provide a synchronous API to do that.
 
 My only problem with making uri operations easier is that the
 incidence of remote data loss or performance complaints will increase.

Hum, while I don't like the reason why it is a good point (remote
support not being perfect), it still IS a good point.  Though, I don't
think that we shouldn't mount the volume to make things harder, if we
really want to stop getting boring reports of users messing with their
data remotely, we should probably simply drop the remote support and let
the user do the mounts AND opens manually.  But do we want that?

 So, it either requires the calling code to be asynchronous (which we
 don't have yet and that don't fit well with current code), or to hack
 around to make the asynchronous code look synchronous.

 I did the latter, and that's basically the reason why I post this mail:
  do you think it's too ugly, too useless, too something?
 
 Well, shrug, what else can you do?
 
 But if the mainloop is still running while waiting, does that mean the
 UI is still available and the user can trigger another open? Will that
 work since AFAIK none of Geany is intended to be re-entrant.

Good point.  Just two things to note:

1) It's not actually any worst than gtk_dialog_run() which does the
same, now I added a modal progress dialog [1].  We use gtk_dialog_run()
in many places and don't worry much, so maybe it's enough.

2) The only (easy) way to trigger the volume mounting code is currently
to open an URI pointing to an unmounted volume from the CLI.  All other
ways of of opening remote files (File-Open, URI list DnD, ..) almost
surely needs the volume to be already mounted.  OK, this only makes a
buggy behavior less likely, it doesn't prevent it completely.


The sad story is that GLib/GIO actually HAS the API needed to make this
work completely fine (g_main_context_push/pop_thread_default(),
g_file_supports_thread_contexts()), but GVfsDaemon doesn't support it.
BTW, GVfsDaemon seems to lack plenty of things, see the other mail...

 Its a pity our old friend g_replace_contents doesn't work safely,
 otherwise we could g_file_new_from_uri, g_file_read to read it and
 g_file_replace_contents to write it, and let GIO do what it is meant
 to, sigh.

I think you're a bit too optimistic/naive.  AFAIK, GIO won't ever mount
you a volume implicitly just because you want to read from it.  Actually
it's unlikely it can, because it might require user interaction, like
asking an username or a password.  And GEdit itself does call
g_file_mount_enclosing_volume().

 Basically, points I see in a pros/cons:

 + allows to open URIs on unmounted volumes;
 + as a cause, makes Geany handle URIs more naturally;
 + mount is tried only as a last resort, so doesn't impact already
 working situations;

 - code is a bit hackish (the loop thing), though it works fine [1];
 - may be slow if mounting the volume is slow (since it is synchronous);
 - may not be really useful in practice (since people probably open URI
 through the file manager, who will mount the volume).

 
 Well I can't comment on its utility since I never edit anything
 remotely anyway. (but I guess that was a comment anyway).

I don't edit much remote files myself and prefer either local edit +
upload or simply Git :)  -- but yes, was a useful comment, thanks :)


Cheers,
Colomban


[1]
https://github.com/b4n/geany/commit/540e6b28d8ce461b44f6fd4dce32c38167bca99b

 
 
 Cheers
 Lex
 

 So... thoughts?


 Cheers,
 Colomban


 [1] only problem might be that idle/timeout callbacks (e.g. main loop
 sources) can still run during the mount -- though, I don't see why it'd
 be an actual problem for us
 
 See question above
 
 ___
 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

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

Re: [Geany-devel] get build command from a plugin

2012-01-30 Thread Colomban Wendling

Le 30/01/2012 23:22, Lex Trotman a écrit :
 On Tue, Jan 31, 2012 at 5:13 AM, Dimitar Zhekov
 dimitar.zhe...@gmail.com wrote:
 On Mon, 30 Jan 2012 14:08:59 +1100
 Lex Trotman ele...@gmail.com wrote:

 How can I $subject?

 At the moment you can't officially access any of the build system from
 a plugin.

 [::surprise::]

 Initially I exposed some of the build system (see comments starting /*
 * in build.h/c) but concerns were raised that this exposed the
 implementation so it was removed.

 I don't see anything starting with /**, and there are lots of /* *...
 
 Thats because none of them are officially exposed, the space
 prevents doxygen from picking them up so they are not in the plugin
 doc.
 

 My attempts to proactively define an interface that does not expose
 any implementation structures was also rejected, so there is
 officially no way.

 Hmmm... Have you tried something simple, like:

 const gchar *build_get_command(ft, index, part)

 Where:

 ft = filetype | independent | exec
 
 existing enum GeanyBuildGroup, we shouldn't add an extra enum that can
 get out of step
 
 index = 0, 1, ...
 part = label | command | workdir
 
 existing enum GeanyBuildCmdEntries, as above
 

 rval = NULL if index is too big or some other argument is invalid.
 
 Yeah, if all you need is read-only access, I'll just change
 build_get_current_menu_item() to return only one field, means that you
 have to make three calls though.  It does all the checks to return
 NULL already.  build_get_current_menu_item() is not officially in the
 API and it isn't used internally so it can be changed.
 
 Now do I return the gchar * and trust you not to write to it, or copy
 the string and trust you to free it?  Maybe return const gchar* so you
 you are warned not to change it or free it.

Yes, return const gchar *.  Returning internal data as gchar * is
neither a great idea nor a common idiom in Geany/GLib/GTK; and
duplicating just for the fun is less handy to use for the caller and
only has the real advantage that a future implementation could drop that
internal representation and simply compute it.  But const gchar * should
be enough to tell the caller not to touch the data, if somebody actually
modifies it and it cause problems, I'd say you deserved it.


Cheers,
Colomban

 

 Of course, it's not much different than the current build_get_*()
 functions, but doesn't expose any build structures. And I guess
 people will need the effective value, not some particular source.

 
 Yeah, see above, build_get_current_menu_item gets what you call the
 effective value (it returns the source, but if you don't want it I
 won't return it).
 
 I guess you need to request the parts you need, and those will be
 exposed in the usual ad-hoc way.

 Some home_ft/project specific commands. They're not hard to get, but
 re-reading the key files is hardly the right thing.

 
 And reading the files wouldn't get any changes the user has made this
 session since they are not saved until Geany closes.
 Does above suit you?
 
 Cheers
 Lex
 
 --
 E-gards: Jimmy
 ___
 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

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

[Geany-devel] Opening unmounted GIO URIs

2012-01-30 Thread Colomban Wendling

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

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

I wrote this patch that adds automatic mounting of volumes needed to
open a GIO URI, so one don't have to first mount the corresponding
volume in Nautilus/whatever.  This make opening arbitrary URIs from the
CLI easier, though it's probably not needed when using a file manager
(who would've already mounted the volume to browse it).

I'm quite confident mounting the volume is a good idea in theory, but
there is a small thing making it a bit tricky: GIO doesn't seem to
provide a synchronous API to do that.

So, it either requires the calling code to be asynchronous (which we
don't have yet and that don't fit well with current code), or to hack
around to make the asynchronous code look synchronous.

I did the latter, and that's basically the reason why I post this mail:
 do you think it's too ugly, too useless, too something?

Basically, points I see in a pros/cons:

+ allows to open URIs on unmounted volumes;
+ as a cause, makes Geany handle URIs more naturally;
+ mount is tried only as a last resort, so doesn't impact already
working situations;

- code is a bit hackish (the loop thing), though it works fine [1];
- may be slow if mounting the volume is slow (since it is synchronous);
- may not be really useful in practice (since people probably open URI
through the file manager, who will mount the volume).


So... thoughts?


Cheers,
Colomban


[1] only problem might be that idle/timeout callbacks (e.g. main loop
sources) can still run during the mount -- though, I don't see why it'd
be an actual problem for us
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] encoding combo boxes bug

2012-01-20 Thread Colomban Wendling


Le 20/01/2012 00:07, Lex Trotman a écrit :

On Fri, Jan 20, 2012 at 9:58 AM, Lex Trotmanele...@gmail.com  wrote:

On Thu, Jan 19, 2012 at 11:53 PM, Nick Treleaven
nick.trelea...@btinternet.com  wrote:

Hi,
I'm seeing wrong encoding names in the encoding combo boxes on the Files tab
of the Prefs dialog. E.g. where it should say UTF-8 I see Hebrew. Another
Glade-related bug?


Sort of, according to glade combo_new_encoding, combo_open_encoding
and combo_eol all share the same underlying list model.

So when we initialise them, all the entries go in the same list, so
all three show the encodings twice and the end of line entries at the
bottom.

Two of these need to be pointed to different list models.


PS the two encodings combos could probably share the same list, so
long as we only initialise it once in prefs.c, but eol needs its own
list


Thanks for the catch  analysis, it's now fixed -- actually I did broke 
it in ca922e0ddc8022283ec3c1f49aaa15ab7c5ba213, stupid me.


@All: I added ui_builder_get_object() to be able to fetch a non-widget 
(list store here) from prefs.c, but I'm not completely sure it's the 
prefect fix.  If you have any idea on how to improve this, spread them! :)


@Nick: how did you generate the Glade file for 
21cd7bb2139fd67644e5777bb8e6387d34473d09 Add Project overrides for 
'Saving files' checkbox options?  When I do use Glade 3.8.1 do modify 
the file it keeps reordering prefs/project dialogs...  Just wondering, 
actually committing the move isn't really harmful -- apart that it 
renders the diff unreadable, stupid Glade.



Regards,
Colomban



Cheers
Lex



I don't have Glade 3.8.1 (need 3.10 for another project) so I
shouldn't do it, someone with the right Glade care to create two new
list models.

Cheers
Lex



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


___
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

2012-01-20 Thread Colomban Wendling


Le 15/01/2012 23:53, Enrico Tröger a écrit :

On Sun, 15 Jan 2012 13:35:35 -0800, Matthew wrote:


On 01/15/2012 12:03 PM, Lex Trotman wrote:

[...]

What do you think?

If we agree to change the commit mails to this format, I'd deploy
the script soon.



I'd very much like it, and I'm fine with the format :)



Hi Enrico,

Actually I've become used to the standard github commit emails and
clicking on the link for the diff.

Especially for large changes like geany.html or geany.glade (despite
Matthew and Colomban promising the diffs will get smaller with
3.8.1) not being blasted by large diffs is good.  I can choose what I
want to see, and don't get the two line diff of geany.txt cut off
because the huge geany.html diff exceeds the size limit.

I don't suppose that you could let registration for the commit ML
allow a choice of which we want?


Nope.
The only option would be two separate mailing lists.

Though the general idea about the diffs was to limit the diff size to
something like 100kb (as it was before in the SF SVN commit mails) or
any other value which we consider reasonable.



Or make it so no diff is shown for autogenerated files like geany.html
and geany.glade ?

It'd be the best of both worlds then, IMO.


Yeah, a little hackish but would solve the problem probably well enough
together with a general max commit diff size limit.


Why not, until we finally understand how the $@!% Glade choose to output 
in one order or another.  But please keep the info the file got 
modified, don't drop it entirely :)


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

Re: [Geany-devel] Fixing Glade File (was Re: Whither goest CTRL-Q?)

2012-01-13 Thread Colomban Wendling


Le 14/01/2012 03:24, Matthew Brush a écrit :

Hi,

For whatever reason in commit c85b89afdd880b7a6aac42f953bab83d3938a4a3
(fixing the project dialog), Glade removed the accelerators (and
adjustments) from geany.glade.

I'm looking for a clever way to fix this without having to manually edit
the Glade XML, add the dropped stuff back manually, or revert and redo
all my changes from that commit.

Any hints/ideas?

P.S. I tried just copying the whole XML block for the project notebook
(where all my *intended* changes were) into the non-broken version just
before that commit, and it worked somewhat, but there's been changes to
this chunk of code in a later commit, so those don't work.


Well... I managed to get it done with sed + handwriting, that was a bit 
boring but not that hard.


Hope it's fixed now.

Cheers,
Colomban



Cheers,
Matthew Brush
___
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] Geany-Plugins: MAINTAINERS file

2012-01-07 Thread Colomban Wendling


Le 07/01/2012 16:00, Frank Lanitz a écrit :

On Fri, 6 Jan 2012 23:42:39 +0100
Frank Lanitzfr...@frank.uvena.de  wrote:


* What's the exact difference between Supported and Maintained?  The
only difference I see is that supported has the word paid in the
description, but I doubt that most of us get paid for this in
particular, and I also doubt it changes anything on how good is the
support (hobby vs. job).


My fault. I wanted to change this but missed it. I wanted to
s/supported/paid for ... (Even I don't know anybody at the moment who
is getting paid with Geany stuff ;) )


I suggest to use paid instead of supported and change current usage of
supported to maintained.


I'm still not sure what that fact someone is paid or not changes, but 
otherwise it looks fine and clearer to me.


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

Le 06/01/2012 10:29, Frank Lanitz a écrit :
 Hi folks,
 
 We have just added a MAINTAINERS into git to add a single point to find
 who is responsible for a plugin. Please be so kind and sending in
 patches or updating the file on your own for your plugins to show who is
 maintaining etc. File contains a little header with very brief
 instructions to do so.

Oops sorry, I completely forgot to do it myself.  Now done.

Just a few questions:

* What's the exact difference between P and M?  Do we really expect to
have a maintainer but somebody else that deals with the patches?

* What's the exact difference between Supported and Maintained?  The
only difference I see is that supported has the word paid in the
description, but I doubt that most of us get paid for this in
particular, and I also doubt it changes anything on how good is the
support (hobby vs. job).

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

Re: [Geany-devel] Weird Segfault Crash

2012-01-03 Thread Colomban Wendling

Le 03/01/2012 14:36, Nick Treleaven a écrit :
 On 02/01/2012 15:54, Nick Treleaven wrote:
 On 02/01/2012 14:33, Colomban Wendling wrote:
 encodings_convert_to_utf8_from_charset(utf8_name, (gsize) -1, ...)
 
  Is it OK the cast a negative number to `gsize` and will it have the
  desired effect for that function? The `-1` here is supposed to tell
 the
  encoding function that the string is nul terminated and is to be
  measured with `strlen()` IIUC.
 It's ugly, but AFAIK it'll work fine everywhere since it's casted back
 to gssize in that function. But you're right, it should definitely be a
 gssize parameter. Unfortunately this function is in the plugin API, and
 I'm not sure of the implications of changing that parameter's type...

 That should be fixed. I'm not sure whether it needs an ABI break or not
 (guess not), but if the parameter can be -1 then make it gssize.
 
 Now fixed in Git. I decided an ABI break wasn't needed.

OK, cool.  Let's just hope it don't lead to weird behavior, I'm still
not 100% sure of what would happen even though I'm quite confident it'll
work at least on x86 (and actually a test of mine shows it does on my
x86_64 box :) ).

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

Re: [Geany-devel] vergeany :)

2011-12-27 Thread Colomban Wendling

Le 27/12/2011 10:14, Enrico Tröger a écrit :
 On Mon, 26 Dec 2011 19:17:33 +0100, Colomban wrote:
 
 Le 26/12/2011 19:01, Dimitar Zhekov a écrit :
 geanyentryaction.c:9: *  the Free Software Foundation; either
 vergeany 2 of the License, or

 geanyentryaction.c:10: *  (at your option) any later vergeany.

 geanymenubuttonaction.c:9: *  the Free Software Foundation;
 either vergeany 2 of the License, or

 geanymenubuttonaction.c:10: *  (at your option) any later
 vergeany.


 Ouch.  Thanks, now fixed.  Though, I can't understand WTF happened? :D
 
 This happens when people like me use the powerful SearchReplace
 feature but don't use it properly resp. carefully enough :).

Ohh, ok!  I guessed it must've been something like this, but couldn't
find what you wanted to replace ^^

 Sorry and thanks for finding, reporting and fixing.

That's not a big deal (though I don't understand how Dimitar could've
figured this out ^^), I found it quite funny actually :p


Cheers,
Colomban




PS: merry Christmas everybody!
___
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 Colomban Wendling

Le 20/12/2011 05:07, Matthew Brush a écrit :
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.

While I agree the recent list is not useful most of the time (probably
even annoying since I don't know that dir) for me either, I doubt $HOME
is really best.

I see 2 alternative, and I think better, choices:

1) use the basedir of the currently opened file;
2) use the current dir (e.g. dir from where Geany was started) [1].
AFAIK this will be $HOME for panel/shell-launched apps.

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

Cheers,
Colomban

[1] maybe not on Windows where I think the current dir is always the
binary location?

Cheers,
Matthew Brush

[1]
https://live.gnome.org/DocumentCentricGnome/Help%20the%20user%20choose%20a%20place%20to%20put%20a%20new%20file

[2] I think we can safely assume Geany users (ie. programmers) already
know how to manage files :)

___
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 Colomban Wendling

Le 20/12/2011 19:18, Colomban Wendling a écrit :
Le 20/12/2011 05:07, Matthew Brush a écrit :
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.

While I agree the recent list is not useful most of the time (probably
even annoying since I don't know that dir) for me either, I doubt $HOME
is really best.

I see 2 alternative, and I think better, choices:

1) use the basedir of the currently opened file;

Hum, forget this point, we of course already do so :-'

Maybe we could use the last used dir if we can't get the path from the
current file? (e;g. when unsaved)

2) use the current dir (e.g. dir from where Geany was started) [1].
AFAIK this will be $HOME for panel/shell-launched apps.

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

Cheers,
Colomban

[1] maybe not on Windows where I think the current dir is always the
binary location?

Cheers,
Matthew Brush

[1]
https://live.gnome.org/DocumentCentricGnome/Help%20the%20user%20choose%20a%20place%20to%20put%20a%20new%20file

[2] I think we can safely assume Geany users (ie. programmers) already
know how to manage files :)

___
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-18 Thread Colomban Wendling

Hi David,

Le 18/12/2011 16:06, David Gomes a écrit :
 Hey, I'm David, a programmer and I wanted to make Geany tabs detachable.
 So I went added and got the source (from Github), and added a few lines
 in the file notebook.c:
 
 Line 478
   /* enable tab drag and drop */
   gtk_notebook_set_tab_detachable(GTK_NOTEBOOK(main_widgets.notebook),
 page, TRUE);
   gtk_notebook_set_group_name(GTK_NOTEBOOK(main_widgets.notebook),
 geany_tabs);
   gtk_notebook_set_group_id(GTK_NOTEBOOK(main_widgets.notebook), 1);
 
 However, it didn't really work, the tabs were not detachable, I tried
 different IDs too.

I'm not sure what do you want to achieve, but have you read the GTK docs
on the subject [1] ?  It tells you that you have to set
gtk_notebook_set_tab_detachable(notebook, tab, TRUE) (as you did), and
set the notebook group name (as you did) on *both* source and dest
notebook.  Moreover, gtk_notebook_set_group_name() is a replacement for
gtk_notebook_set_group_id(), no need to use both -- though you should
use gtk_notebook_set_group_id() rather than
gtk_notebook_set_group_name() because the latter is only present in a
GTK version Geany doesn't depend on (2.24).


Regards,
Colomban

[1]
http://developer.gnome.org/gtk/stable/GtkNotebook.html#gtk-notebook-set-tab-detachable

 
 What do you think? Thanks.
 
 Also hello :) I feel like the mail isn't lovable enough.
 
 
 
 ___
 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] Moving MultiTerm plugin to Geany-Plugins

2011-12-18 Thread Colomban Wendling

Le 18/12/2011 06:07, Matthew Brush a écrit :
 Hi,
 
 I just added the MultiTerm plugin to Geany-Plugins master branch. Please
 let me know ASAP if it causes you any issues.

It breaks the build from Git when the user ain't got valac.

I committed a perfectable fix that simply checks whether AM_PROG_VALAC
actually found a Vala compiler.  At least people with no valac can now
build geany-plugins again.

Regards,
Colomban

 It still needs to be added to the Waf build system and there's lots of
 work to do on everything else.
 
 Note: there's some build warnings even without make check that are
 caused by the C code that is generated by valac.  There's not much I can
 do about it, the fixes will come with newer valac versions, I'm sure.
 
 Cheers,
 Matthew Brush
 
 On 12/15/2011 08:35 PM, Matthew Brush wrote:
 Hi,

 I wanted to move my geany-multiterm[1] plugin into the Geany-Plugins
 repository and continue development there, but I need help with some
 things. It's written in Vala[2] using the Geany binding[3] Colomban
 wrote.

 My questions are:

 Is there a maintainer mode or something that can be use to only activate
 Vala support in Autotools if this plugin is selected to build? Should
 this go into `build/multiterm.m4`?

 Should the .c/.h files that valac compiles be checked into the VCS so
 that people without valac compiler can still compile the plugin?

 How to make it work with Waf?

 (Mostly for Colomban) How should the geany.vapi/.deps be distributed? If
 I make it install into the normal location I guess it will conflict with
 the official binding, but then again AFAIK the official one isn't
 really distributed, it just lives in a Gitorious repo[3], so I can't
 really depend on it (or can I?). Could we move the official Vala
 binding to Geany-Plugins project as well so that it is released with GP
 and other plugins can depend on it being there?

 Cheers,
 Matthew Brush

 [1] https://github.com/codebrainz/geany-multiterm
 [2] https://live.gnome.org/Vala
 [3] http://gitorious.org/geany-vala-binding
 ___
 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

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

Re: [Geany-devel] Moving MultiTerm plugin to Geany-Plugins

2011-12-18 Thread Colomban Wendling

Le 18/12/2011 16:52, Colomban Wendling a écrit :
 Le 18/12/2011 06:07, Matthew Brush a écrit :
 Hi,

 I just added the MultiTerm plugin to Geany-Plugins master branch. Please
 let me know ASAP if it causes you any issues.
 
 It breaks the build from Git when the user ain't got valac.
 
 I committed a perfectable fix that simply checks whether AM_PROG_VALAC
 actually found a Vala compiler.  At least people with no valac can now
 build geany-plugins again.

...but it still breaks make dist that tries to distribute the compiled
.c, and that's probably way harder to fix.  Or we accept that creating
a dist tarball now requires valac.

 Regards,
 Colomban
 
 It still needs to be added to the Waf build system and there's lots of
 work to do on everything else.

 Note: there's some build warnings even without make check that are
 caused by the C code that is generated by valac.  There's not much I can
 do about it, the fixes will come with newer valac versions, I'm sure.

 Cheers,
 Matthew Brush

 On 12/15/2011 08:35 PM, Matthew Brush wrote:
 Hi,

 I wanted to move my geany-multiterm[1] plugin into the Geany-Plugins
 repository and continue development there, but I need help with some
 things. It's written in Vala[2] using the Geany binding[3] Colomban
 wrote.

 My questions are:

 Is there a maintainer mode or something that can be use to only activate
 Vala support in Autotools if this plugin is selected to build? Should
 this go into `build/multiterm.m4`?

 Should the .c/.h files that valac compiles be checked into the VCS so
 that people without valac compiler can still compile the plugin?

 How to make it work with Waf?

 (Mostly for Colomban) How should the geany.vapi/.deps be distributed? If
 I make it install into the normal location I guess it will conflict with
 the official binding, but then again AFAIK the official one isn't
 really distributed, it just lives in a Gitorious repo[3], so I can't
 really depend on it (or can I?). Could we move the official Vala
 binding to Geany-Plugins project as well so that it is released with GP
 and other plugins can depend on it being there?

 Cheers,
 Matthew Brush

 [1] https://github.com/codebrainz/geany-multiterm
 [2] https://live.gnome.org/Vala
 [3] http://gitorious.org/geany-vala-binding
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] GP HACKING changes

Le 16/12/2011 02:56, Matthew Brush a écrit :
 Hi,
 
 I made some changes[1] to the HACKING file for Geany-Plugins, mostly
 trivial plus I copied and pasted Colomban's committing information from
 Geany's HACKING file.
 
 I made one addition here, and wanted to see if it's cool with everyone:
 
 +* If you're working on a specific plugin, prefix the summary line
 +  with the lower case name of the plugin (same as the directory name)
 +  to make it easier to know which commit affected which plugin without
 +  having to thoroughly examine the commit diff itself.  No prefix is
 +  needed if the commit is non-plugin specific or affects only files
 +  outside of the plugins' directories.
 
 If it's stupid, I can just remove it, but it seems like it might make it
 a little easier, especially for IRC and email commit messages.
 
 Let me know.

I think it's good :)  We used to have such a prefix, and even though
it's easy with Git to get the history of a single directory, it makes
obvious what part is affected at first glance; so I think it's good.

 P.S. Are commit mails working for Geany-Plugins?  I didn't get one for
 this commit.

I did receive the commit mail for the GP HACKING change so I guess it
works :)

Cheers,
Colomban

 Cheers,
 Matthew Brush
 
 [1]
 https://github.com/geany/geany-plugins/commit/5afe76c356e96c847556236cdb169878d4d64b9b

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

Re: [Geany-devel] Geany Color Schemes and Extras Page

Le 08/12/2011 03:08, Matthew Brush a écrit :
 Hi Guys,
 
 I'm thinking about updating the Extras page (geany.org/Download/Extras)
 and I was wondering what to do with the current listing of colour schemes.
 
 One of the colour scheme links (dark color scheme) doesn't work, it just
 points to a domain placeholder page.  I'll remove this for sure though I
 can't notify Amir Saffari since there's no contact info[1].  This has
 been asked about in the user mailing list[2] though I didn't see it at
 the time.
 
 The other other themes (dark color scheme, vibrant ink, dark tango, and
 oblivion2) seem to be great for the versions of Geany and languages they
 support, but since all of the recent changes to the filedefs and color
 schemes, they will probably do a disservice to the users if used with
 newer versions.  What's more, since I've ported them over to the
 geany-themes/named styles/color schemes stuff, they no longer even need
 to be maintained separately.  With porting to geany-themes, they all got
 updated to work with recent Geany versions and support for every
 language starting with Geany 0.20.
 
 So what I propose is to move these links (and also the online color
 scheme generator) to a sub-page or sub-section for legacy color
 schemes, with a description about when to use which colour schemes with
 which versions. This way people who use older Geany versions can still
 access them but they won't be the default schemes users will find. I'd
 also like to put descriptions, screenshots and links to the geany-themes
 color schemes on the Extras page. If time allows I plan to also  extend
 the wiki page[4] to include information about the older colour schemes
 and the transition/version stuff.
 
 To Jason, Bernhard and Duncan (and anyone else), if you would like to
 contribute to the geany-themes project, send me an email for commit
 access or send pull requests through Github. It would even be great if
 you could check out your respective themes to make sure I didn't
 brutalize too much while porting them.
 
 Any thoughts, objections, comments, or otherwise?

Nope, plan sounds good to me.

Cheers,
Colomban


 
 Cheers,
 Matthew Brush
 
 [1] Also no contact info for Oblivion2 and Tango Dark maintainer but the
 links still work on the Extras page
 [2] http://lists.uvena.de/geany/2011-April/006820.html
 [3] https://github.com/codebrainz/geany-themes
 [4] http://wiki.geany.org/themes/start
 ___
 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] junior C developer, interested in learning and helping out with time

Hi and welcome, Sean!

Le 06/12/2011 15:07, Sean Wolfe a écrit :
 Hey there, I'm new to the list, my name is Sean Wolfe and I'm
 interested in learning more about development for Geany. I've got a
 Python background, enjoy coding projects in Django and the python game
 framework Pygame, and also have some C/C++ experience (yay!) and some
 Java as well (ugh...)
 
 I'm really enthusiastic about Geany's small footprint and simplistic
 design. I personally like to run my Geany completely stripped out, no
 scrollbars, no line numbers, like a text editor.
 
 I'm working on some projects on Python and Android, and I want to
 improve my C skills. I am thinking learning more about the guts of
 Geany is a good project. Also there are little bits and tweaks I'd
 personally like to change just for my own user experience, so I
 thought I'd hack a bit and see what's what. My longer term goal is to
 really climb the mountain and help out with the SDL project as well,
 which if you're not familiar is a game framework in C which is the
 basis for a lot of interesting games and stuff out there.
 
 Some of the tweaks I'm interested in personally for Geany include --
 - adding multiple window support with a drag and drop interface ala Eclipse,
 - learning more about how Geany handles projects
 - for laptop screens where vertical pixels are at a premium, stripping
 out the top menu bar and replacing it with a right-click context
 - again for laptop screens, reducing the size of the title bar (maybe
 this is an OS issue, but Google Chrome seems to be able to do it
 well).
 - color scheme editor ala Code::Blocks or Python's IDLE tool.
 
 So! I'm in the process of downloading sources, configuring my build
 environment (Windows XP and 7, maybe linux one day) and reading
 documentation like the HACKING file.

That's a great start!  Don't hesitate to ask if you have any question :)

 Just thought I'd say hi ... Thanks!


Cheers,
Colomban

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

Re: [Geany-devel] Default Snippets