Thanks for suggesting the alternative.
Perhaps, we should consider fixing Geanyctags to work with "vanilla" `ctags`,
as this one is likely more commonly installed by default.
I don't mind submitting the patch to restrict the `find` to `-type f`. This
should not cause any issues, so far as I
Exuberant ctags is very old and unmaintained, maybe try [Universal
ctags](https://github.com/universal-ctags/ctags) which is maintained and is the
source of most of Geany's real time parsers. It should be in Ubuntu's
repository.
--
You are receiving this because you are subscribed to this
Digging more into this... Obviously, this appears to be a known issue in
[geanyctags.c](../blob/bc4dc07e4deb694b647977791a23af6776db4644/geanyctags/src/geanyctags.c#L234-L250)
(albeit conditionally handled for Windows only).
Looks like the issue is tied to the output from the `find` command
That looks like a problem with ctags, not Geany. Geany-ctags is just running
ctags. Whats your version of ctags?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Using Geanyctags 1.38 on Ubuntu 20.04.
On first use the 'Project > Generate tags' menu command completes correctly and
generates a new .tags file for the project. After that, trying to re-generate
the tags (repeat 'Generate tags') fails with the following error in the
Messages pane:
```
find
thanks but I'm not a C developer, so I will wait if someone can solve this (in
my opinion) bug.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/2679#issuecomment-736367044
Not without somebody changing the code to pass the wordchars value from the
filetype file. Pull requests are welcome.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
ok, I'm sorry for mistake. so, no solution for that, right?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/2679#issuecomment-736362201
I think they mean `newline` ie the LF character, thats what the C standard says
and MS claims compatibility.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/2677#issuecomment-736362217
Yeah, but the curious thing is that they explicitly mention the first newline
character and don't say something like until newline like in the unix
documentation of the function. But yeah, we'll know more when we get the output
from Enrico.
--
You are receiving this because you are subscribed
Thats a calltip, not autocompletion. Calltips require searching backward from
the `(` to find a name to lookup, and thats one of the places I alluded to
where only looking for C names is hard coded see the NULL at the end
I really can't imagine Microsoft would have done that, as not only it's not
conformant (newline character is `LF`) but it would also be super annoying on
users (reading 2 "lines" for each one ending in `CRLF`). But well, who knows,
maybe in binary mode they do just that…? Again, looking at
I have a suspect. I haven't checked exactly how we read the files for unit
tests but it could be that we use MIO_FILE so the underlying OS implementation
is taken. Microsoft documentation for fgets()
https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/fgets-fgetws?view=msvc-160
autocomplete works for me too but not for possible values. take a look on
screenshots
