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

Persistent abbreviations #721

Open
2 tasks done
wroyca opened this issue Feb 29, 2024 · 3 comments
Open
2 tasks done

Persistent abbreviations #721

wroyca opened this issue Feb 29, 2024 · 3 comments
Labels
new-module Request for the new module

Comments

@wroyca
Copy link
Contributor

wroyca commented Feb 29, 2024

Contributing guidelines

Module(s)

mini.abbrev

Description

Hello /

Often, while working in Vim, we make accidental typos. In such cases, we may create abbreviations to prevent future mistakes. This involves opening our configuration and creating said abbreviation by manually changing the text before and after, which can be really distracting:

vim.keymap.set([[!a]], [[flase]], [[false]])

The proposal would be the ability to create on-the-fly persistent abbreviations and (optionally) provide a way to manage them (remove, modify, and so on). The basic operation would be to select the word we wish to correct and then press <leader>... to prompt the user for corrections (by which an abbreviation is created and persisted on confirmation). Mini.pick can take over from there by listing our abbreviations while mapping some key to (delete, add, change).

e.g.

image

Let me know what you think!

@wroyca wroyca added the feature-request Request for a feature to existing module label Feb 29, 2024
@echasnovski
Copy link
Owner

Thanks for the suggestion!

I have thought about writing abbreviation related module, but did not find any reasonably distinctive way they can be useful beyond snippets. So I decided to wait until after 'mini.snippets' is a thing and reconsider.

As for the idea of making an "interactive abbreviations manager", I don't think that creating abbreviations is such a frequent task that opening config is a big deal for it. Initially my idea was to provide an already created abbreviations for common typos, but that would require maintaining a data base of those, which is not very appealing.

All in all, I'll have this in mind, thanks!

@wroyca
Copy link
Contributor Author

wroyca commented Mar 1, 2024

Thanks for the feedback!

I don't think that creating abbreviations is such a frequent task...

Haha, I wish on so dearly. (:

...that opening config is a big deal for it.

I was looking at it through a writer's perspective - that is, writing multiple large documents and papers where it becomes more interesting to be able to manage abbrev on the fly. I'm interested to hear more on this from other users' perspective!

Initially my idea was to provide an already created abbreviations for common typos, but that would require maintaining a data base of those, which is not very appealing.

Agree, this is also not very flexible - typo tend to be very sporadic and to some extend, personal. It's simply not possible to handle each and every possibility - It's more convenient for users to individually build their own by adding mistakes as they make them.

All in all, I'll have this in mind, thanks!

🥳

@IndianBoy42
Copy link

I actually use luasnip autosnippets rather than abbreviations but similar principle. It has a command to open any snippet file for editing and it registers BufWritePost autocmds so that when I save it reloads all the snippets. You could extend that principle to anything else in your config. Have a file of abbreviations/keymaps/etc, add a user command to open that with a BufWritePost autocommand that sources it and voila. No need to use pickers and vim.ui.input or any other UI, just editing files so you can use all the power of your editor. and its code so you can add helper functions and loops and all. Maybe some helpful buffer local keymaps like getting the word you cursor was on in the original buffer so you can make an abbrev for it quickly

@echasnovski echasnovski added new-module Request for the new module and removed feature-request Request for a feature to existing module labels Oct 7, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
new-module Request for the new module
Projects
None yet
Development

No branches or pull requests

3 participants