37

I have some concealed characters in the buffer and horizontal scrolling kills the alignment big time.

Is there any way how to disable it? I could not find any relevant options.

bad horizontal scrolling demo

Edit: Demo added. You can see vim bases the scrolling offset on the unconcealed portion of the file, therefore the aligment breaks.

  • 6
    You can't disable it, but you can :set wrap – EvergreenTree Apr 10 '15 at 16:19
  • 8
    @Enuy, what I mean is that the lines are actually longer than the window width, but some text (the bash-like color codes) are concealed. So, Vim thinks it's already reached the edge of the window, but visually it has not. I'd say this qualifies as a bug. – tommcdo Apr 10 '15 at 22:21
  • 8
    @tommcdo Yes, I understand what you mean. There is a similiar issue with wrapping lines when only concealed parts at the end of the line are the cause of wrapping and it got WONTFIX from Bram: code.google.com/p/vim/issues/detail?id=260 – Enuy Apr 10 '15 at 22:24
  • 3
    That's why I am searching for an alternative solution - to disable horizontal scrolling altogether. – Enuy Apr 10 '15 at 22:25
  • 3
    The closest I can think of is if you're in a terminal, you could use <c-s> to suspend the terminal so that the screen does not update. You could then blindly make changes and go back to the beginning of the line and hit <c-q> to resume. Other perhaps-not-helpful options: ensure that the same number of concealed characters are between every visible character or widen the window. – Matt Boehm Apr 10 '15 at 23:03
1

How to disable horizontal scrolling

I've written a solution that disables horizontal scrolling, (by riffing off of @ЯрославРахматуллин's suggestion), but I don't think you're going to like it:

augroup NoScrollPlease
  autocmd!
  autocmd CursorMoved * norm!99zH
augroup END

This prevents scrolling to the right by the incredibly precise method of just scrolling back again.*

* Because I don't know how far you've scrolled to the right or how long your lines are, I'm scrolling the arbitrarily "far" amount of 99 half screen widths. Note also that I'm not bothering to check whether or not you've actually scrolled to the right before scrolling "back" to the left. If you actually intend to use this solution you might want to knock something up by comparing the values of getcurpos(), 'sidescroll' and 'columns'.

Why you're not going to want to do so

The reason that you're not going to use this is that underlying the scrolling problem is another issue: Vim won't let you move the cursor "off screen". Therefore, if you scroll to the left in a way such that the cursor would be off screen after the scroll, Vim helpfully brings the cursor along with it and moves it to the left.

But because the calculation it's using for whether the cursor is on screen is the same as the one it's using for deciding whether to scroll in the original problem, the net effect is that with this "solution" in place, if you attempt to move the cursor to the right in a situation that would normally cause a sideways scroll, now the cursor refuses to move at all.**

**To be slightly more precise, depending on the current position and the movement, the cursor may move rightwards; it just won't move past the position where a scroll would normally occur.

Other options?

So I'm afraid your planned workaround isn't going to pan out. If you want a workable solution to the general problem, it's going to need to be implemented in the Vim source code.

As you've already noted, this is unlikely to arrive any time soon, so I'm afraid your best bet for a workaround to the specific instance of the issue shown in your gif is to petition the plugin author to stop using conceal entirely and instead remove the hidden text from the buffer entirely.

Based on the unconcealed output and the mention of vim-plugin-AnsiEsc in the documentation this might be something it's possible for them to implement, but it's hard to say for sure without knowledge of how the plugin functions.

0

If you have a way to edit the file, you might want to wrap the colors setup with \[ and \], as per explained here:

[...] What's been done is to enclose the '\033[1;33m' that starts the yellow colour in '[' and ']' which tells the shell "everything between these escaped square brackets, including the brackets themselves, is a non-printing character [...]

Otherwise, the whole color codes are considered as characters, and therefore might be taken in account for the horizontal scroll.

I am not sure this is the issue, but seeing the source of the calendar (with syntax off) and the current behaviour, it made me think of that.

  • The problem isn't the colours, but instead the characters hidden by the conceal feature (see the discussion in the comments). – Rich Oct 2 at 12:59
  • Yes, I understand. Maybe there is something I did not grasp well, but I had a similar issue in bash with a PS1 using color characters (the fact that they are colors does not matter), and the terminal was not correctly returning in a new line at the good place, as it was counting the characters for the colors as effective characters, whereas they had to be ignored, as they are invisible. The animation reminded me of this issue (where the horizontal pagination is done "too soon", as if it does it based on the number of chars in the line, which is what is mentioned in the link in my answer). – padawin Oct 2 at 14:14
  • The two problems are similar, I agree. But the behaviour described in this question occurs because of the way Vim counts characters (not the terminal) and so the suggestion you make in your first paragraph won't help here, I'm afraid. – Rich Oct 2 at 15:35
0

EDIT: This is a known bug, closed "won't fix": https://github.com/vim/vim/issues/260

Original answer:

My vim doesn't scroll horizontally until the cursor hits the edge of the screen.

Are you using sidescrolloff?

I don't know about disabling horizontal scrolling entirely, but this setting should make it wait until the cursor goes off the edge:

:set sidescrolloff=0
  • The problem exists even with 'sidescrolloff=0' because Vim believes the cursor has gone off the edge: it bases its calculation on the unconcealed text, not the visible text. – Rich Oct 2 at 12:58
  • Oh, that's really buggy. I found a bug report about this and added it to my answer. The vim maintainer doesn't want to fix it. – JasonWoof Oct 4 at 3:15
  • Not a fix to this bug... but maybe you could implement your calendar coloring with plain text in the buffer and prop_type_add() and prop_add() for colors/etc. – JasonWoof Oct 4 at 3:19
  • Yup, it's a bummer, but that bug report is the reason the OP wrote this question looking for a workaround! – Rich Oct 4 at 8:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.