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

Right shifts move text to wrong columns when using 'vartabstop' and 'shiftwidth' is 0 #14891

Open
ghgary opened this issue Jun 1, 2024 · 2 comments
Labels

Comments

@ghgary
Copy link

ghgary commented Jun 1, 2024

Steps to reproduce

  1. $ vim -N -u NONE -i NONE
  2. :set vts=17,13,11,7,5 sw=0 ruler
  3. :normal aword
  4. Shifting right with >> a number of times moves the cursor to the following expected sequence of columns: 18, 31, 42, 49, 54, 59.
  5. Move word back to column 1.
  6. :set shiftround
  7. Shifting right with >> a number of times now moves the cursor to this sequence of columns: 18, 27, 40, 45, 50, 51.
  8. Move word back to column 1.
  9. Type I to insert at the start of the line.
  10. Type Ctrl-T a number of times to shift word to the right.
  11. Again, the sequence of column numbers is 18, 27, 40, 45, 50, 51.
  12. The state of 'shiftround' does not affect the behavior of Ctrl-T because it always rounds.
  13. Left shifts using << or Ctrl-D are not considered here because their movement is broken in other ways.

Right shifts are broken because of the way that rounding is calculated. The width between tab stops at the column of the first non-whitespace character in a line is divided into that column number to determine the indentation of the line in tab stops. That works fine if the tab stops are uniform, but not if they vary.

Expected behaviour

The line should be shifted so that the 'w' in 'word' falls one column to the right of the next tabstop column, as in the sequence of step 4 above.

Version of Vim

9.1.454

Environment

Operating system: Ubuntu 22.04
Terminal: XTerm(389)
Value of $TERM: xterm-256color
Shell: bash 5.1.16

Logs and stack traces

No response

@ghgary ghgary added the bug label Jun 1, 2024
@ghgary
Copy link
Author

ghgary commented Jun 2, 2024

I have a patch for this. I have more testing to do and I need to write a test for the issue. I'll create a PR probably this week.

@ghgary
Copy link
Author

ghgary commented Jun 13, 2024

Since it's been over a week, here's an update. I wrote tests to cover every shift command and option combination I could think of and discovered a number of additional issues, some with my code, some with existing code, mostly having to do with variable-width tabstops when 'shiftwidth' is 0. The fixes are coming along well--it's just taking time.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant