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

Proposal: Validate Top-Level Objects #56

Open
1 task done
l-zeuch opened this issue Jun 29, 2022 · 1 comment
Open
1 task done

Proposal: Validate Top-Level Objects #56

l-zeuch opened this issue Jun 29, 2022 · 1 comment
Labels
area/syntax affecting syntax highlight status/triage default label before it is marked as bug or something else type/enhancement New feature or request
Milestone

Comments

@l-zeuch
Copy link
Owner

l-zeuch commented Jun 29, 2022

Description

This proposal asks to implement some sense of validation for top-level objects like .User, .Guild, etc.

Additionally, it'd be nice if we can find a way to also have auto-completion available for them.

Solution

Initial thoughts: Have some sort of dict lookup table from which we can determine:

  1. If it is a valid top-level object
  2. Validate its fields alongside

However, this might cause issues within range and other structures that manipulate the dot context. We'd have to parse the context around the object and then determine whether to launch validation, or not.

This also poses an issue with the auto-completion engine: My knowledge around the engine we provide sources for is heavily limited, and their documentation on such pretty "advanced" stuff is... lacking to say the least.

Perhaps we can consider implementing our own completion engine, entirely tailored to our needs. If possible, even in pure Vim Script, so that both Vim and Neovim can benefit from this feature.

The last point is, at least currently, not trivial -- here it is worth looking further into it and pushing Vim Script to its absolute limits.

As easy as it might seem to just look at other completion engines's code, I believe a clean-room implementation is both beneficial to us, as developers, as well as avoiding potential license / copyright claims. An active development branch should be considered.


Thinking further, the classic RegEx ways are quite excessive and inherently slow; though Vim's RegEx is powerful, it is still RegEx in the end and comes with its shortcomings, such as

  1. Hard to read
  2. Hard to maintain

There might be a third way, which I am missing, but I'll update this comment whenever I have a new idea.

With this feature implemented, we can also consider validating the syntax on some basic level -- though, at some point, we should consider implementing an LSP, which defines the grammar proper rather than admittedly hacks via Vim Script.

Code of Conduct

  • I agree to follow this project's Code of Conduct.
@l-zeuch l-zeuch added type/enhancement New feature or request area/syntax affecting syntax highlight status/triage default label before it is marked as bug or something else labels Jun 29, 2022
@l-zeuch l-zeuch added this to the Backlog milestone Jun 29, 2022
@l-zeuch
Copy link
Owner Author

l-zeuch commented Jun 30, 2022

On completion: It looks like we can quite easily hook into the user's omnifunc (see :h 'omnifunc') with our own completion scripts.

For inspiration on how to write these scripts, it is quite useful to look at Neovim's sourcetree, namely in runtime/autoload, and then any script that has complete in its filename.


Edit:
Also reading :h compl-omni delivers quite some information.

All in all, this doesn't seem too daunting and would get rid of an arguably unnecessary dependency. We then can also have the user quite easily decide if they want to have completion via omnifunc, or none at all.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/syntax affecting syntax highlight status/triage default label before it is marked as bug or something else type/enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant