RFE: enable gvim to open a buffer or tab in a new window

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
23 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RFE: enable gvim to open a buffer or tab in a new window

Ben Fritz
On Friday, April 7, 2017 at 6:50:25 PM UTC-5, L. A. Walsh wrote:
> Ben Fritz wrote:
> >
> > Is maximizing for the split view and then restoring the application window an option? If not is there a reason you need specifically 80-character application windows? Or do you just like that size?
> >  
> ----
>     I never use full screen unless I'm not doing work (movies/games).

OK, so that makes things somewhat more difficult, but still it might be possible to work with.

>     80-chars -- many projects require lines to fit in an 80-char
> width.  It's a standard in the software world (not so much in the web
> world).
>

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.

>     And there's the final 'rub'... I'll try the other commands
> you mention -- but I gave 1 example (that can't even be
> handled w/80 column widths).  When I'm working on a project
> with >50 file-pairs, working to resize any of them manually is a
> pain -- thus my comment that it was easier to quite and restart both
> files in separate 80 column windows (FYI -- my window columns are
> adjusted for the line numbers, automatically, so if a file has
> line numbers turned on in the header, a vim-function takes care of
> resizing the windows wider to handle the extra columns needed for
> the numbering).
It sounds like you could benefit from a mapping to quickly do ":wincmd o" or "<C-W>O" (that's CTRL+W followed by O) to close all but one window, leaving "only" the current window open, and then call your function to resize as you like. With that mapping it would be only one keystroke to restore your window to the size and layout you like.

>
>     Also, side-by-side is one of the simplest to describe, but
> many times, I'll have windows staggered so a quick click can
> switch me to a different file.  <<THAT is a major reason why
> I don't use full screen.  When I want to take a break or do
> something else, I'll minimize my 13-vim edit buffs(6-w/2 tabs, +1),

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. See :help clientserver, it might be worth experimenting with and making some mappings to get what you want via mappings instead of mouse dragging. Also see the standard "editexisting" plugin shipped with Vim in the "pack/dist/opt" folder for an example of multiple application window shenanigans.

> or if it's a vid or game, just leave them for later.  Also if
> full screen I often won't see other application messages hidden
> by the full screen window.
>
>     In your case (and Jacky's), using vim full-screen eliminates
> even the thought of staggered windows or using the mouse to
> arrange them.  Full-screen narrows your view -- both in terms
> of limiting it to only the files you've brought up, but also
> to not seeing the usefulness of vim having multiple independent
> windows as an option.
>
I 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. Unfortunately 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.

>     Do you use vimperator as well? (a vim-like extension that
> used to be maintained for the FF web-browser.  I tried it too,
> BTW, but couldn't get used to using the keyboard to navigate
> web pages.

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.

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RFE: enable gvim to open a buffer or tab in a new window

Christian Brabandt
In reply to this post by L. A. Walsh
On Fr, 07 Apr 2017, L. A. Walsh wrote:

>    I never use full screen unless I'm not doing work (movies/games).
>    80-chars -- many projects require lines to fit in an 80-char
> width.  It's a standard in the software world (not so much in the web
> world).
>
>    And there's the final 'rub'... I'll try the other commands
> you mention -- but I gave 1 example (that can't even be
> handled w/80 column widths).  When I'm working on a project
> with >50 file-pairs, working to resize any of them manually is a
> pain -- thus my comment that it was easier to quite and restart both
> files in separate 80 column windows (FYI -- my window columns are
> adjusted for the line numbers, automatically, so if a file has
> line numbers turned on in the header, a vim-function takes care of
> resizing the windows wider to handle the extra columns needed for
> the numbering).
>
>    Also, side-by-side is one of the simplest to describe, but
> many times, I'll have windows staggered so a quick click can
> switch me to a different file.  <<THAT is a major reason why
> I don't use full screen.  When I want to take a break or do
> something else, I'll minimize my 13-vim edit buffs(6-w/2 tabs, +1),
> or if it's a vid or game, just leave them for later.  Also if
> full screen I often won't see other application messages hidden
> by the full screen window.

You could do something like this, if you really want a new top level vim
for the file being edited currently:

:let opts=['columns=80', 'tw=80'] " put more options here
:let additional_flags=has("gui_running") ? '-g' : ''

:exe "!".v:progpath additional_flags '-c ":set '.join(opts).'"' expand("%:p")

Stick in there an additional '-R' if you don't want to modify the buffer
(and skip the swap file exists dialogue).

But note, that once you do that, you can't share registers/variables
anymore, just in case it matters.

Best,
Christian
--
Gib deine Ideale nicht auf! Ohne sie bist du wohl noch, aber du lebst
nicht mehr.

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RFE: enable gvim to open a buffer or tab in a new window

L. A. Walsh
In reply to this post by Ben Fritz



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.
--------------------------


I 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.
In the picture I posted of my desktop, all of those vim windows were from
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.


 Unfortunately 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.
  
  If it was something easily doable "in vim", I wouldn't be
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.





--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
12
Loading...