Skip to content

Fix completion-at-point functions #74

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

Merged
merged 1 commit into from
Dec 29, 2021
Merged

Fix completion-at-point functions #74

merged 1 commit into from
Dec 29, 2021

Conversation

minad
Copy link
Member

@minad minad commented Dec 29, 2021

According to the Emacs documentation the completion functions should not
prefilter the candidates themselves. It is up to the completion UI to perform
the filtering. By deferring the filtering to the completion UI various
completion styles like substring, flex or orderless can be used. In contrast,
the old implementation enforced prefix matching.

According to the Emacs documentation the completion functions should not
prefilter the candidates themselves. It is up to the completion UI to perform
the filtering. By deferring the filtering to the completion UI various
completion styles like substring, flex or orderless can be used. In contrast,
the old implementation enforced prefix matching.
@mtreca
Copy link
Collaborator

mtreca commented Dec 29, 2021

Hi minad, great to see you are contributing to gnuplot.el
Anything simplifying the code and adding more flexibility is more than welcome.

@mtreca mtreca merged commit cc547ce into emacs-gnuplot:master Dec 29, 2021
@minad
Copy link
Member Author

minad commented Dec 29, 2021

Hey Maxime, thank you for the quick merge! If you are interested I can prepare a few commits which simplify/cleanup the current code base here and there. But I would avoid intrusive changes since the current system does not seem to bad. In particular what are your plans regarding #66? I think the semantic/cedet subsystem is mostly obsolete nowadays or will be superseded by treesitter+lsp. Therefore I would not move to that and the gnuplot package already seems to have its own elaborate parsing infrastructure. Can this be extended gracefully or do you see large issues with it?

@mtreca
Copy link
Collaborator

mtreca commented Dec 29, 2021

I would most definitely merge these commits, I think there are a few areas where the package could be simplified without loss of functionality. Issue #66 is really wishful thinking at this point, the idea being to externalise the parsing tasks outside of the package. But since it seems to be working pretty well at the moment I don't think it would be wise to move it at the moment. I should have more time starting January, looking at some ways this package could be improved is on the agenda. You are more than welcome to participate, your experience would be greatly appreciated.

@minad
Copy link
Member Author

minad commented Dec 29, 2021

@mtreca I don't have big plans with gnuplot but I will see if I can help out a bit. Feel free to ping me if questions arise. I think we should avoid huge changes instead try to gradually modernize the packages, fixing bugs and updating the package to new gnuplot features. Ideally without breaking anything of the existing functionality. We can probably still carefully deprecate or remove certain things. :)

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.

2 participants