See also https://sourceforge.net/p/ctags/bugs/194/
I didn't use the exact upstream patch only altering the C++ code path,
because as far as I know no c.c language recognize two consecutive
colons separated by whitespace as a single token, so there's no point
in carrying on mistakes from the past.
Both sorting by name and appearance makes sense for most languages. Some
users may prefer sorting by appearance so make it configurable in
preferences (the possibility to override the settings for specific
filetypes is preserved).
Thanks to Colomban Wendling for lots of improvements of this patch.
Fixes#313.
We just need to skip the (...) and perform autocompletion as before.
Shift pos by 1 in the whole function so we don't have to look 2 characters
back (makes the function easier to read).
Functions contain pointers in their return values - remove them before
searching for the type.
Also restrict the searched variable/function/type tags a bit only to
types which make sense for the search.
In principle this is very similar to the normal scope search. If the
provided name belongs to a type that can contain members (contrary to a
variable in scope search), perform the namespace search. With namespace
search show all possible members that are at the given scope.
Since we perform the scope search at file level, don't perform the
namespace search for tags that can span multiple files otherwise we get
incomplete results which could be confusing to users. This involves
namespaces and packages.
Rethink how to extract members from the struct types. Inspired by
the patch using the same file as the typedef to search for structs,
we can do the same to extract the members only from the file
containing the struct and not the whole workspace. This makes
this operation fast enough so we don't have to keep the extracted
members in a special array (this will become especially useful
for namespace search because for it we would have to extract
all tags and then the extracted array would have the same
size as the workspace so we'd lose the performance gain).
Since the above works only for tags having the file information,
that is, not the global tags, we'll lose some performance
when searching the global tags. I think people don't create
the tag files for complete projects but rather for header files
which contain less tags and still the performance should be
better than before this patch set because we go through the
global tag list only once (was twice before).
On the way, clean up the source a bit, add more comments and move
some code from find_scope_members() to find_scope_members_tags().
Even though enums contain members, their members are accessed in a
different way than members of classes and structs. E.g. consider:
typedef enum {A, B, C, D} MyEnum;
Variable of this type is declared as
MyEnum myVar;
myVar can be assigned a value from MyEnum; however, we don't access myVar
over the dot operator so we don't need the list of all members after
typing
myVar.
This patch eliminates some false positives after typing .
The implementation of this function is almost the same like the original
m_workspace_find_scoped_members() and there's nothing interesting here
we wouldn't be able to recreate trivially.
By comparing the file pointer in the loop we can speed it up a bit
because we can avoid the strcmp() (this function is the slowest part of
the scope completion based on profiling).
Also move the pointer array creation to this function and return it which
is a bit cleaner.
Disclaimer: I have absolutely no idea how the original function works.
After gazing into the code for one hour, I just gave up and wrote my own
version of it based on what I think the function should do
but maybe I'm just missing something what justifies the original
implementation's insanity.
The previous commit fixed the situation when e.g. anon_struct_0 was in the
current file by checking the current file first.
In the case the struct type definition isn't found in the current file,
at the moment we get all members from all anon_struct_0 which can be a
really long list. This list isn't very helpful to users because all the
members from all the structs are mixed. Moreover, not all possible members
are in the list because there are e.g. just members from anon_struct_0 but
not from anon_struct_1 etc. which from the point of view of this function
is a different type.
Instead, restrict the returned members to just a single file (anonymous
structs have unique name per file so it means there will be just one
from the file). Of course the picked file can be wrong and the returned
members might be from a different struct the user wanted but at least
the list will make more sense to users.
At the moment it can happen that even though a member is found in the
currently edited file, the search at the end of the function finds
the type inside another file. This typically happens for anonymous
structs so e.g. for anon_struct_0{...} from the current file we get
members from anon_struct_0{...} from all open documents plus gloabl tags.
Search in an increasing "circle" - start with current file only (trying
all possible types of the variable), continue with workspace array and
finally, if not found, search in the global tags.
The extension is used by both C and C++ and lexing/parsing C headers with
the C++ parser causes less problems (identifiers named like C++ keywords
get highlighted and tags aren't generated for them) than parsing C++
headers with the C parser (parsing and lexing completely broken).
Non-ascii characters in file/directory names caused:
1. build commands didn't succeed
2. characters in the message window weren't shown in correct encoding
3. clicking on a row with error in the message window didn't open the file
with error.
This patch fixes these three issues.
`GDK_space` is not guaranteed to have the value of an ASCII space
(although it does in practice), and using a GDK constant does not make
sense inside a text manipulation function.
Avoid splitting lines right before a whitespace when reflowing (e.g.
in case of several consecutive ones) not to move whitespaces at the
start of the next line, which, while they will be removed later on,
can lead to incorrect reflow width and even fully empty lines.
Prefer leave trailing spaces then, which is less of a problem.
Avoid triggering auto-indentation with consecutive whitespaces when
reflowing, as it can lead to infinite loop if auto-indent leads to
inserting full lines.
Fixes#848.
All of these typos were found by codespell, so credits go the
the authors of this incredibly useful tool.
I manually confirmed and adapted all changes, which includes
reflowing over-long lines or filling up with spaces for alignment.
Some of these typos may need forwarding to their original authors.
codespell reported a lot words where I am unsure; I have not
included those corrections.
Major changes are:
- Some types were accidentally documented, even though they couldn't be
accessed by any exported API functions. Those are removed (especially
from encodings.h).
- Some types were not documented where they should. Documentation is
added for them. Members are not necessarily documented separately if names
are self-explanatory.
- @a XXX refers to parameters of the function, it's inappropriate for
highlighting NULL (change to @c)
- As per consensus, build_info is removed from GeanyData (replaced by
pointer to avoid ABI break; added grep-able abi-todo tag so it doesn't get
forgotten)
encodings.h had a pretty large GEANY_PRIVATE part so it's worthwhile to
separate that into its own header (as per HACKING). What's left is used by the
plugin API.
Colorizing the whole document is rather expensive and unnecessary as
Scintilla colorizes the visible part of the document when scrolling
happens. Instead, colorize only the visible area when highlighting
typenames.
Simplify and optimize creation of the sorted menus by taking advantage
of the fact they might already be partially sorted, and that we can at
least add one entry to each group in each run.
This goes from 4032 runs to 882, which while definitely not optimal for
adding 126 items, is probably totally good enough and don't warrant
duplicating the encoding array and sort it.
Though, such optimization doesn't matter as it's not what takes time in
this function, which is probably rather the widgets creation.
Rewrite a part of `encodings_init()` to remove duplication and some
hard-coded values.
This gives us the item for UHC back, that was lost when adding CP932 in
9d9f40cd15ad121ff3e3fffd40073706c297f2dd, due to a missing update of
the hard-coded group elements count.
These appear under 64-bit Windows. Only the sciwrappers.c warning is
potentially dangerous. For win32.c, the "handle" provides some useful
information, while "lStdHandle" does not.
