Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add new upstream candidate Flex parser #2134

Merged
merged 1 commit into from Apr 28, 2019

Conversation

3 participants
@b4n
Copy link
Member

commented Apr 27, 2019

See: universal-ctags/ctags#2084

This import has 3 difference with upstream:

  • don't use newer API than current Geany has (will be fixed by a later sync, maybe #2132 already);
  • workaround a current limitation of our ctags use to emit tags for a kind disabled by default (should be fixed in #2132);
  • workaround a current limitation of our ctags use to emit reference tags.

They are fairly small differences, and they should alight with further sync.


reviewers, won't wait too long, I'll merge soon ;)

Add new upstream candidate Flex parser
See: universal-ctags/ctags#2084

This import has 3 difference with upstream, not to use newer API than
current Geany has, and to workaround current limitations of Geany ctags
calls: imports are enabled by default and don't have a specific role.

@b4n b4n added this to the 1.35 milestone Apr 27, 2019

@b4n b4n requested review from techee and elextr Apr 27, 2019

@b4n b4n self-assigned this Apr 27, 2019

@b4n b4n referenced this pull request Apr 27, 2019

Open

Upstream or alternative solution for ctags regex parsers #2119

2 of 2 tasks complete
@techee

techee approved these changes Apr 27, 2019

Copy link
Member

left a comment

After looking at the 3000 LOC parser, I decided to approve the pull request. Disapproving it would mean I'd have to explain "why" which would mean I'd have to understand what the parser does and what it does wrong :-)

I'll enable reference tag generation in #2132.

@b4n

This comment has been minimized.

Copy link
Member Author

commented Apr 27, 2019

Disapproving it would mean I'd have to explain "why" which would mean I'd have to understand what the parser does and what it does wrong :-)

Oh you wouldn't have to go very far to find something wrong with that parser. First thing, it's a fork of the jscript parser, which is wrong on its own. Secondly, support for an XML dialect was thrown in there, well, let's say, quickly. And if you're still standing and keep digging, you'll see that what's left is not so bad (well, not worse than jscript), but doesn't extract much info (no signature, no inheritance, no type, etc.).

This said, it still should work OK, and give somewhat better results than the previous one.

@elextr

elextr approved these changes Apr 27, 2019

Copy link
Member

left a comment

Not knowing a flex/actionscript from a moviescript I tried a few bits off the internet and got symbols, so I quickly approve before I find something wrong :)

@b4n b4n merged commit ec6e232 into geany:master Apr 28, 2019

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details

b4n added a commit that referenced this pull request Apr 28, 2019

Merge pull request #2134 from b4n/ctags/new-flex-parser
Add new upstream candidate Flex parser

@b4n b4n added this to Parsers in U-CTags sync Jun 18, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.