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

New commands shrink_line_above and shrink_line_below #3279

Closed
SoraTenshi opened this issue Jul 31, 2022 · 3 comments
Closed

New commands shrink_line_above and shrink_line_below #3279

SoraTenshi opened this issue Jul 31, 2022 · 3 comments
Labels
C-enhancement Category: Improvements

Comments

@SoraTenshi
Copy link
Contributor

I have checked whether such an issue already exists, however haven't found anything.
If it's a duplicate, i am sorry.

Describe your feature request

Basically the reversed behaviour of extend_line_above and extend_line_below.
The current behaviour seems rather inconsistent (having to go to visual mode and then manually unselecting. on extend_line_above this behaviour isn't even possible), so i that's why i have this proposal.

on shrink_line_above, the line of the topmost selection will be unselected.
on shrink_line_below the line of the bottommost selection wil be unselected.

@SoraTenshi SoraTenshi added the C-enhancement Category: Improvements label Jul 31, 2022
@the-mikedavis
Copy link
Member

Using these to undo extend_line_below and extend_line_above is better accomplished by #1596

On the one hand I could see myself using these commands (or a shrink_line version like #3046) but on the other it seems like a needless optimization on "hjkl in select-mode followed by X." With the addition of these commands we'd basically have the line-wise select-mode from vim.

on extend_line_above this behaviour isn't even possible

Flip the selection with A-; and then use hjkl in select mode

The current behaviour seems rather inconsistent

A bit of a nitpick: something cannot be inconsistent without differing from a baseline behavior. What is the current behavior inconsistent with respect to? IMO it would be inconsistent to have special handling for newlines.

@SoraTenshi
Copy link
Contributor Author

SoraTenshi commented Aug 1, 2022

Using these to undo extend_line_below and extend_line_above is better accomplished by #1596

On the one hand I could see myself using these commands (or a shrink_line version like #3046) but on the other it seems like a needless optimization on "hjkl in select-mode followed by X." With the addition of these commands we'd basically have the line-wise select-mode from vim.

Soft undo sounds like something, that'd help in this case.

A bit of a nitpick: something cannot be inconsistent without differing from a baseline behavior. What is the current behavior inconsistent with respect to? IMO it would be inconsistent to have special handling for newlines.

Well i see the inconsistency in e.g. that we have only one direction of doing something with newlines (namely: only extending), i see the incosistency as selections should IMO be bi-directional. But that's just my opinion.
I would be rather fine with just the soft-undo, i think this would already be a great addition.

@someone-aka-sum1
Copy link

This is not completed. Please reopen the issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-enhancement Category: Improvements
Projects
None yet
Development

No branches or pull requests

3 participants