Colomban,
Did some more research.
1. Doesn't happen with rest (I think I must have had the filetype set wrong when I found it before, hence geany.txt is now marked for filetype :)
2. in symbols_get_context_separator() rest returns something other than '.'
3. tried returning impossible rubbish "!@#$%^&*()_" for other markup languages and they now work like rest.
4. tried returning null string "" but got infinite loop, didn't dare return NULL :)
So what is the correct way of saying "no context separator for this filetype"?
Other than markup languages, are there any others that do not have context separators, or it is not '.' (other than ruby commented in symbols_get_context_separator)
Cheers Lex
On 11 May 2013 12:44, Lex Trotman elextr@gmail.com wrote:
Colomban,
Did some more research.
- Doesn't happen with rest (I think I must have had the filetype set
wrong when I found it before, hence geany.txt is now marked for filetype :)
in symbols_get_context_separator() rest returns something other than '.'
tried returning impossible rubbish "!@#$%^&*()_" for other markup
languages and they now work like rest.
- tried returning null string "" but got infinite loop, didn't dare
return NULL :)
So what is the correct way of saying "no context separator for this filetype"?
Other than markup languages, are there any others that do not have context separators, or it is not '.' (other than ruby commented in symbols_get_context_separator)
Cheers Lex
Colomban,
And while you are in symbols.c (or near there ?) in C++ symbols defined with "auto" do not show in the symbols pane, thats understandable (will raise bug report so we fix it and other c++11isms one day), but annoyingly those symbols still get rubbish autocompletions when you type symbol-> or symbol.
Where are those coming from if the symbol doesn't exist?
Cheers Lex
Le 14/05/2013 09:47, Lex Trotman a écrit :
[...]
Colomban,
And while you are in symbols.c (or near there ?)
Err, your request moves towards c.c… nice try ;)
in C++ symbols defined with "auto" do not show in the symbols pane, thats understandable
Probably prevents the parser form understanding the declaration. At least it would prevent me from understanding it :)
(will raise bug report so we fix it and other c++11isms one day), but annoyingly those symbols still get rubbish autocompletions when you type symbol-> or symbol.
Where are those coming from if the symbol doesn't exist?
That's probably because the (current) scope completion code is well, maybe "idiotic" is the word. But actually I don't know much since I don't get this code, maybe ask Nick (he was against me replacing it with a maybe slower version of this that I did understand, so maybe he did actually understand the current one).
But anyway, I think it tries very hard to show something, and then will show rubbish for unknown tags.
And don't forget we don't parse local variables, which means we have no idea what their type is.
On 15 May 2013 11:38, Colomban Wendling lists.ban@herbesfolles.org wrote:
Le 14/05/2013 09:47, Lex Trotman a écrit :
[...]
Colomban,
And while you are in symbols.c (or near there ?)
Err, your request moves towards c.c… nice try ;)
in C++ symbols defined with "auto" do not show in the symbols pane, thats understandable
Probably prevents the parser form understanding the declaration. At least it would prevent me from understanding it :)
(will raise bug report so we fix it and other c++11isms one day), but annoyingly those symbols still get rubbish autocompletions when you type symbol-> or symbol.
Where are those coming from if the symbol doesn't exist?
That's probably because the (current) scope completion code is well, maybe "idiotic" is the word. But actually I don't know much since I don't get this code, maybe ask Nick (he was against me replacing it with a maybe slower version of this that I did understand, so maybe he did actually understand the current one).
But anyway, I think it tries very hard to show something, and then will show rubbish for unknown tags.
And don't forget we don't parse local variables, which means we have no idea what their type is.
True, which does make it a little bit silly to try to return something for . and ->
Cheers Lex
Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Le 15/05/2013 03:45, Lex Trotman a écrit :
On 15 May 2013 11:38, Colomban Wendling <lists.ban@herbesfolles.org mailto:lists.ban@herbesfolles.org> wrote:
[...] And don't forget we don't parse local variables, which means we have no idea what their type is.True, which does make it a little bit silly to try to return something for . and ->
A little, but it would somewhat work for class members and alike.
Le 11/05/2013 04:44, Lex Trotman a écrit :
Colomban,
Did some more research.
- Doesn't happen with rest (I think I must have had the filetype set
wrong when I found it before, hence geany.txt is now marked for filetype :)
in symbols_get_context_separator() rest returns something other than '.'
tried returning impossible rubbish "!@#$%^&*()_" for other markup
languages and they now work like rest.
- tried returning null string "" but got infinite loop, didn't dare
return NULL :)
So what is the correct way of saying "no context separator for this filetype"?
There are currently none. Context separators are used to separate names in fully or partially qualified names, like in "Foo<sep>Bar". So this separator string should be one put in tags scope by ctags.
However, some language indeed don't put any, and generate unqualified scopes -- as does the ASCIIDoc one.
We don't currently have anything to specify "no separator", but we probably could go for some ASCII control sequence, like ETX (\x04, End of Text), EOT (\04, End of Transmission) or pretty much anything that's not printable or blank.
BTW as we discussed on IRC, we can't really return "" (empty string) or NULL because it would somewhat break the plugin API (and it would actually break plugin geanygendoc).
Other than markup languages, are there any others that do not have context separators, or it is not '.' (other than ruby commented in symbols_get_context_separator)
Do you expect me to know every language? :) Though, in real programming languages there generally are rules on what an identifier can be, so most languages will allow a context separator. And even, most languages will have one, as part of the syntax to access nested units, like "." and "->" in C, ".", "::" and "->" in C++, "::" and "->" in PHP, "." in Python, etc.
So, as we discussed on IRC I suggest we pick an ASCII control character (or sequence) and return this for languages that should allow anything in tag names.
Cheers, Colomban