[Github-comments] [geany/geany] Enable local variables for C/C++ and improve autocompletion (PR #3185)

[elextr]

@techee now you have upset me, and I am the one helping you, not the person who comes in at the last minute and demands changes for what appear to be purely procedural reasons.  I have instead explained why I do not support reducing the capability but been ignored.  If you are going to make wholesale changes please consult others involved, yes my time zone often means some delay (1/2 - 1 day), but its better than just making wholesale changes without consulting. [end gripe]

Anyway it appears that there is more improvement to be had, even before the latest changes reduced it, which I havn't tested. Some of this didn't happen to be visible in previous testing because I was (un)lucky and alphabetic sorting appeared to be "doing the right thing". 

# Background

Most of the functionality of a C++ application is packaged in classes, so most declarations are members, even many objects that would be a `static` in C are static members in C++.

And since most data is now members, autocompletion of member names is now more important, its likely as common as autocompletion of local variables.

But in the code of member functions, member names are not qualified, so they are non-scope autocompletion.  This is unlike C where struct members are always scope autocompletion of a variable `.` or a pointer `->`, or Python where members are qualified by `self` in member functions.  

So the quality of non-scope autocompletion is a significant determinant of the user experience.

Also for C++, more is declared in the header files and referenced in the body files than with C, particularly all those members as outlined above. 

Geany and ctags do not do include file tracing because they do not know the build options that usually define where those files are found.  So the heuristic that tags from files of the same name but different extension are headers is a reasonable compromise.

# Autocompletion

IIUC this PR uses heuristics to identify the likely type of the base for scope autocompletion, including prioritising local variables by position in the current file, members of the class inside a member function of the class and not outside one, then (before the last changes) symbols in header files determined using the above heuristic, then globals from all open files and loaded tags (IIUC).

As said [here](https://github.com/geany/geany/pull/3175#issuecomment-1107831415) non-scope autocompletion sorts local variables to the start of the list, but lumps the rest alphabetically, including all those members that are so important.  But this is the case that presents the user with a list which now includes members that are invalid, and valid members mixed into globals.

So in one case a reasonable heuristic based on prioritisation is used, and in the other case its not, and that is the case that is visible to the user.  Since the autocomplete list generation already includes multi-level sorting for locals, why not use the same prioritisation as used for the scope autocomplete to order the list.  Or at least separate members like locals.

If important functionality is removed from this PR either Geany will still give a bad user experience for C++ autocomplete, or another PR must be immediately applied to scrape off some of the warts, so whats the point in separating it?



-- 
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/3185#issuecomment-1118036978
You are receiving this because you are subscribed to this thread.

Message ID: <geany/geany/pull/3185/c1118036978 at github.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.geany.org/pipermail/github-comments/attachments/20220504/4be98b74/attachment-0001.htm>