Hi,
I notice the items in the symbol list disappear when you're inside a global "string literal" (or #include using quotes, but not <>) that isn't closed yet. Only the symbols below the unclosed quotes disappear.
This is probably not a new thing, just noticeable now that the symbol list is updated in real-time. My guess would be that the parser just refuses to handle the rest of the file in this case, but maybe it should skip to the next line and keep going or something, if this is even possible.
I just thought I'd point it out since I noticed (it's visually distracting). It's not a majour problem or anything.
Cheers, Matthew Brush (codebrainz)
On Tue, 15 Mar 2011 00:21:18 -0700 Matthew Brush mbrush@codebrainz.ca wrote:
Hi,
I notice the items in the symbol list disappear when you're inside a global "string literal" (or #include using quotes, but not <>) that isn't closed yet. Only the symbols below the unclosed quotes disappear.
This is probably not a new thing, just noticeable now that the symbol list is updated in real-time. My guess would be that the parser just refuses to handle the rest of the file in this case, but maybe it should skip to the next line and keep going or something, if this is even possible.
I just thought I'd point it out since I noticed (it's visually distracting). It's not a majour problem or anything.
It used to do the same thing when you saved a file with incomplete quotes (or braces, or brackets), at least for Java files. It can be a useful way of working out where you missed a brace since only functions before that will be successfully parsed.
Jon
Le 15/03/2011 08:21, Matthew Brush a écrit :
Hi,
I notice the items in the symbol list disappear when you're inside a global "string literal" (or #include using quotes, but not <>) that isn't closed yet. Only the symbols below the unclosed quotes disappear.
This is probably not a new thing, just noticeable now that the symbol list is updated in real-time. My guess would be that the parser just refuses to handle the rest of the file in this case, but maybe it should skip to the next line and keep going or something, if this is even possible.
That's it: the parser you use (C for example) don't do magic with some invalid content. Of course, now it's more noticeable, 'cause as Jon said, this haven't changed :) Dumb parsers like most regexp-based ones are probably not affected by this.
A proper solution would probably be to make the parsers handle this gracefully, but there is a limit to what we can do anyway. For example, it'd be really difficult, if not impossible, to find what to do with wrongly matched braces.
I just thought I'd point it out since I noticed (it's visually distracting). It's not a majour problem or anything.
I can suggest you to workaround this by increase the minimal time between to automatic updates (there is a pref in /Preferences -> Editor -> Completions/) if you often get annoyed by it when typing short strings or whatever.
Cheers, Colomban
On 16 March 2011 04:05, Colomban Wendling lists.ban@herbesfolles.org wrote:
Le 15/03/2011 08:21, Matthew Brush a écrit :
Hi,
I notice the items in the symbol list disappear when you're inside a global "string literal" (or #include using quotes, but not <>) that isn't closed yet. Only the symbols below the unclosed quotes disappear.
This is probably not a new thing, just noticeable now that the symbol list is updated in real-time. My guess would be that the parser just refuses to handle the rest of the file in this case, but maybe it should skip to the next line and keep going or something, if this is even possible.
That's it: the parser you use (C for example) don't do magic with some invalid content. Of course, now it's more noticeable, 'cause as Jon said, this haven't changed :) Dumb parsers like most regexp-based ones are probably not affected by this.
A proper solution would probably be to make the parsers handle this gracefully, but there is a limit to what we can do anyway. For example, it'd be really difficult, if not impossible, to find what to do with wrongly matched braces.
It would also be very hard to do something sensible with languages which allow multi-line strings, once the string is opened the rest of the file IS a string.
The only real solution is to not update any of the symbol list if the parser detects a syntax error like unclosed string or mismatched braces, and maybe it would be nice to inform the user in the status bar.
Cheers Lex