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  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:
>>>
>>> templateclass problem;
>>>
>>> template<> class problem {
>>> };
>>>
>>> template<> class problem {
>>>   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 problem
>>> b) at line 3 definition of problem
>>> c) at line 6 definition of problem
>>>
>>> Note that these are distinct classes as if the names include ,
>>>  and .
>>>
>>> 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 "problem"of 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

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

2012-03-18 Thread Lex Trotman 
Hi Colomban,

I used both patches all afternoon with no visible problems.  They seem
to work as advertised.  Will keep using, thanks.

Cheers
Lex

On 18 March 2012 08:36, Colomban Wendling  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:
>>
>> templateclass problem;
>>
>> template<> class problem {
>> };
>>
>> template<> class problem {
>>       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 problem
>> b) at line 3 definition of problem
>> c) at line 6 definition of problem
>>
>> Note that these are distinct classes as if the names include ,
>>  and .
>>
>> 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 "problem"of 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

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:
> 
> templateclass problem;
> 
> template<> class problem {
> };
> 
> template<> class problem {
>   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 problem
> b) at line 3 definition of problem
> c) at line 6 definition of problem
> 
> Note that these are distinct classes as if the names include ,
>  and .
> 
> 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 "problem"of 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: :GSList> */
+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

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

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-16 Thread Lex Trotman 
Hi All,

So that I don't look unreasonable for criticising just Geany I
investigated what many other IDEs do with the same source, basically
working my way through the wikipedia C++ IDEs list (at least the open
ones we might, erm, share code from, and that would run on my machine
without changes to its configuration).

The results are sumarised below:

Anjuta, symbols pane wrong - repeated members on both problems
and problems, autocomplete failed, none offered

Code::Blocks and Codelite both failed to install due to wxWidgets
dependency problems.

Eclipse CDT, symbols pane CORRECT, autocomplete works but ignores
private/public access restrictions (minor issue)

Emacs, no symbol pane, autocomplete saw second definition only, change
order and change the offered autocomplete.

Geany, symbols pane cycles members as previously described, autocomplete-ly crap

Gnat programming Studio, symbols pane didn't work, autocomplete didn't
work, program was so slow it was unusable so test was cut short

Kdevelop could not install because I wouldn't let it install most of
KDE as well :(

Monodevelop, symbols pane didn't work at all, autocomplete didn't work
at all (help didn't work so I couldn't figure out why)

Netbeans, symbols pane CORRECT, autocomplete CORRECT including
adhering to private/public access restrictions.

Qt creator installed and ran but would not create even a plain C++
project without full qt install >1GB which I won't do :(

And Matthew kindly tried xcode for me, symbols pane correct,
autocomplete did not work

Unfortunately that leaves Geany as the worst of those that worked at all :(

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

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

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

2012-03-12 Thread Lex Trotman 
> Cheers
> Lex

PS my mention on IRC of possible namespace problems as well just
turned out to be my typing a brace in the wrong place :-P
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

[Geany-devel] C++ Symbols problem

2012-03-12 Thread Lex Trotman 
Hi All,

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:

templateclass problem;

template<> class problem {
};

template<> class problem {
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 problem
b) at line 3 definition of problem
c) at line 6 definition of problem

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

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 "problem"of 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