Ben Fritz wrote:
This part is easy: ":set textwidth=80" and make sure the 'formatoptions' setting contains 'c' or 't' or both. You also might be interested in the 'colorcolumn' option to draw a line at a specific column, for example column 80, to show when you're getting near to the 80-character boundary.----
I never use those, as "autowrap" always wraps at the wrong place.
Consider (code typed with tw=80+fo_ops c+t):
(numbers included to show 80-columns).
01234567890123456789012345678901234567890123456789012345678901234567890123456789
for ( int i_fld = 0, o_fld = 0; i_fld<select_fields.size() &&
o_fld<accumulator.size(); ++i_fld, ++o_fld) {
Vs.
for ( int i_fld = 0, o_fld = 0;
i_fld<select_fields.size() && o_fld<accumulator.size();
++i_fld, ++o_fld) {
The latter is a preferred code-style with the 3 clauses of a 'for'
loop all on 3 lines (when they don't fit on 1 or don't look right on 1).
Also, of note, though is that the window doesn't resize when I type
set tw=80 -- in order to have well-formed code, seeing the screen width
is needed.
As it is, vim comes up in an 80 char window (when launched from an 80-col
terminal). If my files have "gvim=:SetNumberAndWidth" in a comment
near the top, then my *gvimrc* (not vimrc) will resize the window
to allow for the numbers. The current code blindly adds an extra column
for 'fdc' whether it exists or not (need to fix that ;-) :
func! SetNumberAndWidth()
set number
if (! exists("g:added_numwth")) | let g:added_numwth=0 | endif
if (g:added_numwth < &numberwidth)
let g:added_numwth = &numberwidth
" adding 1 to allow for 'fdc' width;
let &columns = 1 + g:added_numwth + &columns
endif
endf
if !exists("g:autocommands_loaded")
let g:autocommands_loaded =1
au VimEnter,WinEnter * let ln = line("'\"") | if search("vim=:SetNumberAndWidth",'n') | call SetNumberAndWidth() | endif
endif
----
I'd suggest just keeping a bunch of tabs open in ONE Vim and switching between the tabs, here. If you need to reference more files at the same time you can even open them as additional windows in the same tab. I frequently have 4-6 windows or more open in my Vim as I edit. But I understand more now why you wanted to be able to quickly spawn a new application window! There is a --remote-tab flag you can use from the shell command line when launching Vim to open a tab in an existing Vim application window instead of launching a new Vim.
Looked into that hoping the server would open a new window
for each edit, but that doesn't seem to be the case (right?)?
----See :help clientserver, it might be worth experimenting with and making some mappings to get what you want via mappings instead of mouse dragging.
See note where I said using commands to navigate doesn't work well:
-------------------------------
On Sun Apr 09, 2017 @ about 8pm, Linda wrote:
Here's another rub -- and why I like the mouse for navigating. using the keyboard for navigating is too analytical and is more likely to interfere with the thinking about what I'm doing, which is rather analytical. Compared to mouse moving, which doesn't seem to use my analytical-verbal skills so much and feels more unconscious -- in so much as I don't have to think about it, so it doesn't cause much "crosstalk" in my analytical thinking. --------------------------
In the picture I posted of my desktop, all of those vim windows were fromI occasionally bring up multiple Vim application windows when I'm switching between multiple unrelated tasks. But I like to keep everything related to my current task in one application window. I can see you're using multiple unrelated application windows for that, and understandably want to link them together more efficiently.
the same application. Those were about half of the open vim-windows
with the others being minimized -- but ***all*** were from 1 application.
FWIW -- I was looking at a multi-desktop manager -- as for me, I tend
to want to keep everything related to my current task on my desk(top).
Then I could switch to another desktop to switch projects.
If it was something easily doable "in vim", I wouldn't beUnfortunately Vim was not designed for that and the underlying assumption that there is ONE application window to worry about is pretty deeply ingrained in Vim, so it will take a LOT of time and effort to add such a feature, and the benefit over using multiple "tab pages" instead may not be worth that effort.
wanting changes in for the GUI... ;-).
But hey, at one time, vim couldn't handle unicode or variable char-cell
spacing (was said to be too big of a change in vim to do). But that
works now. If no one makes clear what is desired, no one will know
it is wanted or why. Many people get used to doing things a specific
way and stop thinking about how their work-flow might be better.
I've tried using more tabs and splits, but found it more confusing --
a problem w/tabs -- when I only see the window header (especially
true when it is minimized), I don't know what files are in that
editor. The way I do it now, (file.cc+.h), I know which header I
need to click on to get that file. There'd be no way to just
look at the window-title and know what files were in its tabs.
---I don't use vimperator or other plugins for vim-like movements in the browser. I never really saw much of a point since in a browser I mostly only scroll, view specific links, and switch tabs. Vim's power to me is mostly in manipulating text, not viewing it.
Maybe that's another difference -- I spend alot of time viewing,
reading and scrolling through the code, jumping from file to file
as I follow execution flows and match up declarations with usage.
For me, understanding, modifying and writing code can involve
alot of the same actions as in a browser. I believe I mentioned
before wanting to have the gvim-syntax hilighting in a program
like 'less'. I might use the "to"-HTML script more often if
it was more convenient and faster. Problem is, when looking at the
code in a browser window, I would have a hard time counting the number
of times I've tried to enter vim commands into the browser window,
attempting to edit the file... *sigh*.
But often I don't remember the exact names of the files I want
to look at, but if I see them in the window-frame, I'll know
which ones I want, but with 80+ files that sometimes change names
as classes are updated, its hard to keep track of all of them.
At least I can reduce that to 40+ by always bringing up a
companion file when it exists (.h for .cc files and vice versa).
I guess I'm not used to code that isn't expandable...
like .. things that work in a window, would like be pointer
based. Can't a pointer also redirect to another window --
and this is, as I said in my opening note, something that is
likely specific to a gui (not a tty window).
When limited to tty's though, I'll usually bring up multiple tty
windows for different files.
Certainly I've worked on projects that don't need so many windows,
but this is complicated enough, that I'll regularly generate
call-graph diagrams using 'doxygen'. It doesn't help that I started
this project 2-3 years ago and was in the middle of a large rewrite
when I had to shelve it. The structure was alot clearer 2-3 years
ago, but now I need to figure out which files have been converted
and which not, and which still need fresh code.
No comments:
Post a Comment