Skip to content

fix: explicitly set the sql filetype on new notes #207

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
May 8, 2025

Conversation

toh995
Copy link
Contributor

@toh995 toh995 commented Apr 27, 2025

This fixes #154.

For some reason, when creating a new note (local or global), the filetype for the new buffer was being set to sql, but treesitter wasn't picking up the filetype for syntax highlighting.

This is a bit of a hack, but I found that explicitly setting the filetype to sql on the buffer seems to resolve the issue 🤷

Comment on lines 47 to 51
buffer_options = vim.tbl_extend("force", {
buflisted = false,
swapfile = false,
filetype = "sql",
}, opts.buffer_options or {}),
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This shouldn't affect users who set their own filetype in their configs, because the user configs should override the default config.

Copy link
Contributor

@phdah phdah left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this makes sense as the default setting here. There are some other adapters that are not SQL file types, but that can as you said be handled by the user overwriting.

Maybe as a future improvement, the editor buffer could be handler aware, to set the proper one directly. But I think that would require some refactoring to enable.

Thoughts @MattiasMTS ?

Copy link
Contributor

@phdah phdah left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this makes sense as the default setting here. There are some other adapters that are not SQL file types, but that can as you said be handled by the user overwriting.

Maybe as a future improvement, the editor buffer could be handler aware, to set the proper one directly. But I think that would require some refactoring to enable.

Thoughts @MattiasMTS ?

Copy link
Collaborator

@MattiasMTS MattiasMTS left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

2cents. I'm ok merging this given, as raised in the PR, this plugin is mainly SQL focused but we also have noSQL drivers.  However, I expect that noSQL users already have some overwritten logic themselves already, so this PR doesn't break that.

Although, final words, I'd want to see this as part of the source in relation with the connection struct. For example, in each source/driver one would declare what filetype should be set - and then that is set dynamically as such. This is more future PR refactoring and no within the scope of this PR

@toh995
Copy link
Contributor Author

toh995 commented May 2, 2025

Thanks for the feedback @phdah @MattiasMTS!

What else do I need to do, to get this merged?

@phdah
Copy link
Contributor

phdah commented May 5, 2025

Thanks for the feedback @phdah @MattiasMTS!

What else do I need to do, to get this merged?

It's @MattiasMTS that has the power to merge. I think he can just go ahead an do it?

@MattiasMTS
Copy link
Collaborator

Sorry late reply - lots of thing at work. Yes I can merge, but the CI/CD will fail. Could we potentially merge #204 first with the proposed changes and then merge this. Sounds ok?

@MattiasMTS MattiasMTS merged commit 3984bb0 into kndndrj:master May 8, 2025
22 of 23 checks passed
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.

No hightlight in newly created scratch pad
3 participants