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

FR: Start in visual mode #174

Closed
MarcelRobitaille opened this issue Oct 21, 2024 · 4 comments
Closed

FR: Start in visual mode #174

MarcelRobitaille opened this issue Oct 21, 2024 · 4 comments
Assignees
Labels
enhancement New feature or request P2 Not a priority. PRs welcome

Comments

@MarcelRobitaille
Copy link
Contributor

MarcelRobitaille commented Oct 21, 2024

The way I understand #163 is that people want to perform normal mode operations on the input. I would like to propose that in this case it's better to start in visual mode (a visual selection over the initial value).

Let's take vim.lsp.buf.rename as an example:

Desired action Start in insert (default) Start in normal (config.input.start_in_insert = false) Start in visual (proposal)
Completely change name Backspace, Backspace.... or escciw ciw c
Uppercase name esc Uiw Uiw U
Prepend to name esc I i I
Append to name Just type A A
Vim-abolish coersion esc crs crs esc crs

Starting in insert only wins for "Append to name".

The only case I considered where starting in visual is worse is using vim-abolish coersion. Even then, you only have to press esc one time.

I propose to add a configuration option like:

require("dressing").setup({
  input = {
    start_in_insert = false,
    start_in_visual = true,
  }
})

This should obviously only apply if the input has some initial value, like vim.lsp.buf.rename. I guess this would mean that it's valid to set both start_in_insert and start_in_visual to both be true: If there is an initial value, start in visual. Otherwise, start in insert.

It would be cool to make this more configurable on a case by case basis. There is already override, but that's only for winopt. It would be cool to have a function that takes as inputs for example { action = "vim.lsp.buf.rename", initial_value = "old_name" } and you can return start_in_insert, start_in_visual (or anything else in the config). I'm not sure exactly how to encode it, but you get the idea.

I'd argue that the default should be insert mode if there is no initial value, and visual if there is an initial value.

If you think it's a good idea, I'm happy to try to make a PR.

@MarcelRobitaille MarcelRobitaille added the bug Something isn't working label Oct 21, 2024
@stevearc
Copy link
Owner

#163 was actually mostly unrelated. It was about removing insert_only, which caused the modal to be closed if the user escaped into normal mode. That was a terrible idea from the start and never should have existed.

I'm fine with a refactor that replaces the start_in_insert boolean with something more flexible, like start_mode = "normal"|"insert"|"visual"|"select".

This is already configurable on a case-by-case basis, see :help dressing_get_config

@stevearc stevearc added enhancement New feature or request P2 Not a priority. PRs welcome and removed bug Something isn't working labels Oct 22, 2024
@MarcelRobitaille
Copy link
Contributor Author

I only meant it was similar idealogically in that people want to be able to perform normal mode operations. Sorry, I should have been more clear.

Sounds good. I will look into it. Do you care about backwards compatibility to start_in_insert? Did I manage to convince you that it should be the default if there is an initial value?

Thanks for dressing_get_config. I didn't know about that.

@stevearc
Copy link
Owner

Let's make sure it's backwards compatible, but I'm not yet convinced it should be the default. We should add it first, wait to see how it goes, and later we can evaluate changing the defaults.

@MarcelRobitaille
Copy link
Contributor Author

This is fixed in #175

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request P2 Not a priority. PRs welcome
Projects
None yet
Development

No branches or pull requests

2 participants