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

Feature: Partial fallback #6

Closed
conartist6 opened this issue Jul 1, 2022 · 4 comments
Closed

Feature: Partial fallback #6

conartist6 opened this issue Jul 1, 2022 · 4 comments

Comments

@conartist6
Copy link
Member

conartist6 commented Jul 1, 2022

At the moment this project has no partial fallback and no pretty-printing. When it enters fallback for a node all existing concrete syntax associated with that node is lost and it will print the absolute minimum amount of spaces that are necessary for compilation, and of course no comments.

I'm generally not too concerned with the pretty-printing part of it because I fully expect prettier to handle fixing up those parts. However for prettier to do its work I still need to ensure that I preserve the difference between '{ ' and '{\n' and any other space-sensitive patterns.

Comments are even more important to preserve than the pretty printing. We need to ensure that small changes like insertion into a list or removal from a list don't accidentally erase all comments attached to the list itself (which will likely be all of them).

@conartist6 conartist6 changed the title Pretty printing Partial fallback Jul 1, 2022
@conartist6 conartist6 changed the title Partial fallback Feature: Partial fallback Jul 1, 2022
@conartist6
Copy link
Member Author

To get things working I had said up a NoSource but I think that will need to be eliminated, as we'll just have a TokensSource that is responsible for transitioning in and out of fallback.

@conartist6
Copy link
Member Author

The biggest question is: how will a source transition out of fallback?

A correct solution needs to consider the reasons the source could be in fallback. The most common will be an insertion, deletion, or change to the node's tokens. This creates difficulty because I don't see any incremental way to recover. Recovery may involve passing over a token which is no longer relevant, or it may involve generating a token that did not exist, but there will be no way of knowing which of those things it is that needs to happen, and how many tokens the difference consists of.

@conartist6
Copy link
Member Author

I also need to consider that items could be swapped

@conartist6
Copy link
Member Author

OK at this point I'm just rehashing #3. I've been thinking about other things, but now that I'm back thinking about these problems I'm remembering all the reasons that I decided that pushdown was the correct solution.

@conartist6 conartist6 closed this as not planned Won't fix, can't repro, duplicate, stale Jul 1, 2022
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

No branches or pull requests

1 participant