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.
Related
i3wm offers 4 styles for orgnizing child contaniner:
Vertical split
Horizontal split
Stacked
Tabbed
Instead of having one key shortcut for each of them, I would like to rotate through them using only one key.
Reading the documentation I found it is now possible to cycle through all available layouts:
layout toggle all
But this cycles only in one direction.
I would like to be able to cycle in both directions. It is often the case I do it very fast and I pass by the layout I want. In this case I would be able to go back with just only one keystroke instead of having to rotate all over again.
It is possible to list all the layouts explicitely and have an other command with the same layouts but in reverse order:
Example:
bindsym $mod+e layout toggle splith tabbed stacked splitv
bindsym $mod+Shift+e layout toggle splitv stacked tabbed splith
This simulates the desired behaviour, as every time the command is executed, the layout specified after the currently active one will be applied.
Reference: https://i3wm.org/docs/userguide.html#manipulating_layout
Horizonal splitting is simple.
Is it possible to split vertically? Have wide screen so right hand side is empty anyways.
Edit: I would want to see basically a view of the SAME module on the left, and on the right side of the screen. I know I can put multiple windows next to each other about different modules.
A workaround could be to split the code into multiple modules and change variable scope, but I hope there is a simpler way.
Appears when a new window is inserted.
Think the only workaround is to:
insert an additional module
copy over your code there
arrange these 2 modules vertically, and use e.g. the right-hand side only for viewing, while modifying the left-hand one, to stay consistent.
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.
I have a CodenameOne application which has a TextArea that should display a multi-line text.
When I run the app in the simulator and click on the text-area, the spacing between the lines and possibly also between the characters change so that the area that the text occupies shrinks a bit.
Why is this?
What should I do to prevent it?
That is due to the switch from our drawing to the native editing which will always render things slightly differently. E.g. things like line spacing are really hard to get accurately for every native device.
TextArea has a setRowsGap method that allows you to specify the spacing between rows in pixels but since this differs between OS's its probably not ideal.
I've been using :bnext to jump to to the next buffer in the buffer list (among
all hidden buffers). However, whenever I issue the "buffer next" command, there
are two circumstances:
If I were in the :only mode, i.e. there is only one buffer per
window, that is fine. The previous buffer become hidden and :bnext will bring
me the next buffer up front.
If I were having two buffers up and had arranged them through :vsplit,
still, switching is fine. The new buffer will pop up at the left panel
(vertically spliced)
If I were having two buffers up and have arrange them through :split, i.e.
two buffers is laid out one on top of the other, I will have trouble. Issuing
:bnext will distort the buffer layout of the window by bringing the new buffer
to the left, and have the two buffers vertically split.
Is there a global setting that I can turn on to administrate the action taken by
the :bnext? I am looking for a way to switch to the next buffer without
distilling all my current buffer layout.
(Note that, this distortion gets worse when I have more than two buffers shown
on the screen/session. In that case, :bnext will squeeze all the previous
buffers to the right, and occupy a vertical panel alone.)
Does this look familiar to you? Hope you could help me with this.
All the best,
-Linfeng
To answer my own question.
dwm.vim
is the plug-in that causes the problem. It tries to make the buffer that it switches to the "main buffer", which is be default lying on the left of the screen, occupying the whole panel length.
Update on solution at the dwm.vim side:
Solution had been offered by TimoDritschler in the following thread:
https://github.com/spolu/dwm.vim/issues/62#issuecomment-73743583
A "ready-to-go" dwm distribution of mine could be found at:
https://github.com/llinfeng/dwm.vim/
With the update, the main "compartment" of the window will not be occupied by the buffer that we switch to. Moreover, pressing <C-#> will send the current active buffer (the one with flashing cursor) to the "main compartment". It seems that nothing had been lost and stability had been gained.
Many thanks to TimoDritschler on Github again!