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

refactor: implement lexing and multi-mode parsing engine #21

Open
wants to merge 13 commits into
base: master
Choose a base branch
from

Conversation

polvalente
Copy link
Contributor

@polvalente polvalente commented Oct 8, 2019

The core idea here is that we'll be able to parse list comprehensions differently than normal code, and comments are now dealt with as they should be. In both cases, I relied on the concept of parsing modes, which ultimately change the way certain tokens are parsed. For example, in default mode, an ìftoken would expect anendtoken to close its block, while incomprehensionmode, it wouldn't, and while incomment` mode, it would be ignored altogether.

@julien-duponchelle
Copy link
Owner

julien-duponchelle commented Oct 8, 2019 via email

@polvalente
Copy link
Contributor Author

@noplay I'm gonna need some help with the language definitions. I think that maybe the inlineOpenToken category is not needed anymore, but I reckon you know more of the languages that use it than me.

Other than that, I'm opening the PR to review!

@polvalente polvalente marked this pull request as ready for review October 15, 2019 07:46
@polvalente polvalente changed the title [WIP] refactor: implement lexing and multi-mode parsing engine refactor: implement lexing and multi-mode parsing engine Oct 15, 2019
@polvalente
Copy link
Contributor Author

One improvement that needs addressing before merging is that the nesting for comprehensions is not implemented properly (only counting instead of using stacks).

@singularitti
Copy link
Contributor

Any update? :)

@polvalente
Copy link
Contributor Author

Any update? :)

I've been kinda busy (and sick) these last weeks, but I intend to get back to this as soon as possible!

@polvalente
Copy link
Contributor Author

Sorry it took so long, guys. I got sick, and then was busy with other things. Code is now ready for review (and possible merging).

@julien-duponchelle
Copy link
Owner

Finally got time to test sorry for the long time .

I found two issue. One for ruby. if and unless are not highlited correctly . It's normal because they where implemented in a special list ignoreInDelimiters to support:

        puts "Hello" if a == 3
def test
    if a == 9000 || b < 3
        if c > 5
            if b == 7
            elsif x == 3
            end
        end

        todo.each do |dd|
        end

        puts "Hello" if a == 3
        puts "World" if a == 3
    end
end

The second issue is after changing multiple time to different tab the extension stop working. I'm not sure why. My demo env use a lot of different language (verilog, vhdl...). I'm still trying to figure what is wrong.

@julien-duponchelle
Copy link
Owner

Awesome work !

@polvalente
Copy link
Contributor Author

Finally got time to test sorry for the long time .

I found two issue. One for ruby. if and unless are not highlited correctly . It's normal because they where implemented in a special list ignoreInDelimiters to support:

        puts "Hello" if a == 3
def test
    if a == 9000 || b < 3
        if c > 5
            if b == 7
            elsif x == 3
            end
        end

        todo.each do |dd|
        end

        puts "Hello" if a == 3
        puts "World" if a == 3
    end
end

The second issue is after changing multiple time to different tab the extension stop working. I'm not sure why. My demo env use a lot of different language (verilog, vhdl...). I'm still trying to figure what is wrong.

  • When in ignoreInDelimiters, the words are ignored by our extension (but should be picked up by another syntax highlighter normally).

  • Could you provide some test code for those multiple languages? Maybe there is some memory leaking happening (I don't know exactly how vscode handles extensions with multiple tabs).

In other news, I was thinking of looking into LSP. This should solve most of our problems, if we are able to fetch code block starters and such -- however, I'd still need to look if LSP provides all needed info.

@polvalente polvalente closed this Jan 14, 2020
@polvalente polvalente reopened this Jan 14, 2020
@singularitti
Copy link
Contributor

Any news?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants