I have built Geany from commit 4508f77a1150b37d5e16c3e7fc9c7223bc591e88. I am very happy to have a list of members & methods in the symbols pane. And I appreciate the work going into Geany.
I have come across a bug in my build's TypeScript parser (ctags?). The parsing sometimes is incomplete. The following screenshot is of a class with methods `onEnterZone`, `autoWalkEnabled`, & `canInviteToGroup` which do not show up in the symbols panel:
In another class file there are methods `say` & `getCursor` which *do* show up in the symbols panel:
I am not sure what the difference is, but it appears there is something in the first file that is causing the parser to hiccup. I have not tried building from the latest commit to master branch, but browsing through the commits I don't see any changes referencing TypeScript.
@techee (sorry to ping you again, but you are __the__ expert in tags and parsers and symbols etc)
There is a ctags typescript parser being built into Geany.
But the Typescript filetype is a custom filetype that references a [typescript](https://github.com/geany/geany/blob/2509e21526d36034f5251381a76555e7300fbfc0...) parser.
Typescript is not a [built-in filetypes](https://github.com/geany/geany/blob/2509e21526d36034f5251381a76555e7300fbfc0...) so how does it get called, I thought the lexer and parser names in a custom filetype had to be existing built-in names?
@AntumDeluge Hum, could you share your problematic file(s)? Or even better, see whether [universal-ctags](/universal-ctags/ctags) has the same issue, and report it there, as we're basically bundling those. Anyway it's hard to tell what the issue could be, it probably comes from something above the method that confuses the parser, so more info is needed.
@elextr
Typescript is not a [built-in filetypes](https://github.com/geany/geany/blob/2509e21526d36034f5251381a76555e7300fbfc0...) so how does it get called, I thought the lexer and parser names in a custom filetype had to be existing built-in names?
No, it's using the ctags parser language name (at least that's what it currently does), see [src/filetypes.c LL 937-344](/geany/geany/blob/master/src/filetypes.c#L937).
No, it's using the ctags parser language name
Oh ok, but having added a parser I wonder why the creator of the Typescript filetype didn't go the whole hog and make a built-in filetype. Then they could customise all the language dependent code scattered throughout Geany.
@AntumDeluge to expand on what @b4n says, if the parser thinks you have mismatched `{}`s the parser will skip the rest of the file looking for the `}`, so suspect the function __before__ the first one missing.
If you can paste the suspect code please put it in a gist and only put the link here, thanks.
Oh ok, but having added a parser I wonder why the creator of the Typescript filetype didn't go the whole hog and make a built-in filetype.
This is because there was no typescript parser originally and I added it in the final "ctags sync" PRs but I did it in a lazy way only.
Oh ok, but having added a parser I wonder why the creator of the Typescript filetype didn't go the whole hog and make a built-in filetype. Then they could customise all the language dependent code scattered throughout Geany.
I don't see this as a particularly bad, actually if we could get most, if not all, filetypes uses a declarative style and only have the few specifics hard-coded for the languages we have to, I wouldn't find that too bad. And with the shift towards Scintilla's named-only lexer API, things will shift towards named stuff. If course, we'll probably need magic constants still to optimize several checks for the hard-coded bits, but that could be a bonus a few VIP names get.
We're surely not here yet, but I'm not sure it's a bad slope to lean on. And if there's nothing specific this filetype would need hard-coded, I don't see no harm -- actually, just less code, and you know I love less code :wink:
I don't see this as a particularly bad
No, its not ...
few specifics hard-coded for the languages we have to
... just that you can't do that ATM without a hard coded filetype. Which is why I asked the question, not knowing that the parser was a freebie thrown in by @techee, not added by the filetype creator.
And if there's nothing specific this filetype would need hard-coded, I don't see no harm
I don't know TS, but if you say its C ... [ducks]
but that could be a bonus a few VIP names get.
C for example???? [ducks]
Of course the "small" issue of making `highlightingmappings.h` be read from filetype files is a minor issue in the path to fully loadable filetypes, lexers and parsers. :stuck_out_tongue_winking_eye:
But in general totally agree that moving towards names and dynamic configuration is better.
Sorry, I didn't answer sooner. The two files that I used as examples are located here: - [User.ts](https://github.com/arianne/stendhal/blob/master/srcjs/stendhal/entity/User.t...) - [Player.ts](https://github.com/arianne/stendhal/blob/master/srcjs/stendhal/entity/Player...)
...see whether [universal-ctags](https://github.com/universal-ctags/ctags) has the same issue, and report it there...
When I get done with something I am currently working on, I'll check out Universal Ctags & see if the problem is there.
Playing a tad with it, I see it's the `()`s in the members initialization (e.g. `singletons.getSoundManager()`): if you remove the `()`s it keeps on parsing. Now somebody will have to fix it… :slightly_smiling_face:
This seems to fix it, not sure it's perfect though: ```diff diff --git a/ctags/parsers/typescript.c b/ctags/parsers/typescript.c index 7dcc338ef..3fcd956a8 100644 --- a/ctags/parsers/typescript.c +++ b/ctags/parsers/typescript.c @@ -1820,8 +1820,11 @@ static void parseClassBody (const int scope, tokenInfo *const token) parsingValue = false; break; case TOKEN_OPEN_PAREN: - if (! member) break; uwiUngetC ('('); + if (! member) { + parsed = tryParser (parseParens, token, false); + break; + }
const int nscope = emitTag (member, isGenerator ? TSTAG_GENERATOR : TSTAG_METHOD);
```
github-comments@lists.geany.org