How to make horizontal scrolling one character at a time - vim

Not sure if I'm wording the question right.
That's why I had a hard time finding the answer on google, like I usually do.
I have my vim set to never wrap lines. Keeps code cleaner.
But I don't like that if I'm moving the cursor across a line and get to the edge of the screen, the view jumps so that where I was at is now in the middle of the screen.
Is there a way to make it not do that? Like, so it just goes one character at a time
(or if I'm traveling by word, one word at a time, etc. Just so if I go the edge of the screen, the cursor stays at the edge of the screen, and the page moves inward under it)?

You could check out the 'sidescroll' setting:
'sidescroll' 'ss' number (default 0)
The minimal number of columns to scroll horizontally. Used only when
the 'wrap' option is off and the cursor is moved off of the screen.
When it is zero the cursor will be put in the middle of the screen.
When using a slow terminal set it to a large number or 0. When using
a fast terminal use a small number or 1. Not used for "zh" and "zl"
commands.

Related

Sublime Text 3 Sticky Split

Sometimes, when I use Sublime Text 3 for a while with split windows (using the Origami package), the border between splits gets "sticky", i.e. I cannot move it anymore. Which means, one of the panes all of a sudden has a fixed minimum size.
I can resolve that, back to normal, by using command+z, thus maximizing the current pane. But that's not exactly what I want, because it's annoying in cases when I wanted to have f.ex. equal size of two panes, but a minimized third pane. I have to manually resize all panes to what I wanted or had before, which breaks my workflow.
Has anyone experienced this before? Any known solutions around?
I have found out what the deal is.
It has to do with how the window was split, and under certain circumstances, f.ex. a split on the left side cannot be smaller than a split on the right side.
That's the case when the window has been split vertically first, and then the individual panes are being split horizontally. You split one of the panes, and the split can be pulled up and down to resizes the two panes, without any restriction.
Then you split the other pane, and, at first, the sizes look "free to resize", but then you start pulling on the frame to resize a pane, the frame will pop up beyond the height of the other pane's split pane.
The solution is, to resize both panes, if you want to have one of them smaller or bigger. I'd consider this a bug with a workaround.

Labview: increasing the capacity of a text indicator

I have a (multiline) text indicator in my program where I display everything that my program does. Every time after adding new string to the indicator, I move the vertical scroll bar to the end to make sure that the user will see the message instantaneously. It works fine.
However, when there is a lot of text in the indicator, the user is unable to move the scroll bar. Also, the scroll bar doesn't move to the bottom of the indicator after adding a new message.
How can I increase the capacity of my text indicator? Is it even possible or do I have to decrease the amount of text I display?
The rest of the program works well, the screen doesn't freeze. The only problem I have is that the vertical scroll bar doesn't work properly.
LabVIEW stores strings as a pointer to a structure containing a 4-byte length value followed by a 1D array of byte integers (8-bit characters). The 4-byte value is the same size as a U32, which has a 2^32 range (0 to 4,294,967,295). So, your string can have up to 4,294,967,295 characters.
About the second part of your question: http://digital.ni.com/public.nsf/allkb/E888D1D6A739A787862571F800586482
Put a gigantic amount of text in your indicator while the VI is in edit mode. Can you move the scrollbar then? If you can, then I suspect the problem is how you're adjusting the scrollbar at run time. Is it possible that you're continuously setting the scroll position to the bottom so your user tries to drag it and fails?

Emacs-like scrolling in Vim

For those unaware, AFAIK by default in Emacs scrolling works the following way.
It doesn't scroll until the user has reached the end of the visible buffer, when you reach the end of the visible buffer and you go one over the visible buffer it doesn't load one line, instead it loads an entire new page, basically. I imagine this is to reduce lag when re-rendering the screen.
What would be a way to achieve this in Vim? Is there a way to do this? If there isn't, what are some pointers to implement something like this? My idea was to maybe get the best of both worlds and scroll half a page or one page when scrolloff is reached.
Any help is appreciated. :)
I think this would do what you want:
set sj=-50
check :h 'sj' for details:
'scrolljump' 'sj' number (default 1)
global
{not in Vi}
Minimal number of lines to scroll when the cursor gets off the
screen (e.g., with "j"). Not used for scroll commands (e.g., CTRL-E,
CTRL-D). Useful if your terminal scrolls very slowly.
When set to a negative number from -1 to -100 this is used as the
percentage of the window height. Thus -50 scrolls half the window
height.
NOTE: This option is set to 1 when 'compatible' is set.

How does Google Docs position the cursor when up or down keys are pressed?

Unlike most rich text editors on the web, Google Docs doesn't use contenteditable and instead uses its kix-editor. While moving the cursor on left/right presses is simple, how do they position their cursor when a user presses up or down?
For example, when a paragraph is multiple lines, how does the cursor know what is "above" it?
Or going up or down across multiple paragraphs, in a situation where there is an empty line between them and the cursor manages to save its horizontal positioning, despite the fact that the empty line forces it to move all the way to the left?
Looking at the DOM in Google Docs, it appears they do their own laying out. That is to say, they measure paragraph lengths and split them into separate divs. Therefore, the idea of iterating through the different ranges in the div "above" the currently selected div is a finite problem, instead of potentially an infinite one (if the previous paragraph is immensely long).

I need to draw a line moving with the cursor, but I want to avoid redrawing the whole window every 100ms

I have a program which displays a ruler on the screen, and with Xlib it polls for the cursor position every 100ms and updates the display. The display consists of numbers/lines etc, in particular a line indicating the position of the cursor (which is why it updates).
The problem is that the old line needs to be erased and the content underneath restored, so I have to redraw the whole window to reflect a change in position. Doing this 10 times a second results in a very flickery program.
I could only redraw the ruler after I have confirmed that the cursor is in a position to change the indicator line (i.e. within the bounds of the ruler), but it would still flicker pretty bad when it was updating.
Sort of a noob to GTK and Xlib and all, any advice would be appreciated.
Code is at https://github.com/zjmichen/zRuler
Well you have arrived at one of the earliest problems faced when cursors were being implemented!! Cursor changes are so frequent that redrawing full window every time just doesn't make any sense! Coming to your problem, look at what is needed & what exactly you are doing. Do you need to update the full window when cursor moves? No. You need to update only a section of the window so don't update the whole window. Off the top, I can think of 2 ways of reducing flicker:
1. Simple way is to make use of GdkCursor. Create a new cursor from the pixmap (Sample provided on the developer page) with the shape of your need, a line in your case. Associate cursor with the GdkWindow of your application's main window. This way you don't have to track cursor & draw the line. The cursor itself will appear as the line (so you don't to bother about clearing & redrawing it). Now in the timer callback where you redraw the complete window, redraw only the component which has to be updated on cursor position change. This should hopefully reduce the flicker as you are not drawing all the components.
2. In case you don't want to use GdkCursor, you could create a separate transparent window on top of application window dedicated to cursor. In this approach you can update only the cursor window & the component in the application window which is to updated on change in cursor position. This way other components in the application window are not redrawn each time & this hopefully should also be able to reduce flicker.
Hope this helps!

Resources