2016-01-14 20:20 GMT+03:00 Salman Halim <salmanhalim@gmail.com>:
On Thu, Jan 14, 2016 at 10:41 AM, Nikolay Aleksandrovich Pavlov <zyx.vim@gmail.com> wrote:2016-01-14 18:05 GMT+03:00 Salman Halim <salmanhalim@gmail.com>:On Thu, Jan 14, 2016 at 8:44 AM, Nikolay Aleksandrovich Pavlov <zyx.vim@gmail.com> wrote:2016-01-14 8:23 GMT+03:00 kamaraju kusumanchi <raju.mailinglists@gmail.com>:Is it possible to detach the current tab in a gvim session into a
separate gvim window? Something akin to what firefox can do with tabs?
Once the tab is separated, can I dock it back into the original gvim
window session?
...if ( remote_expr( server, "bufloaded('" . filename . "')" ) )
This should be using `string()`, *not* `"'" . filename "'"`.Fair enough. However, if you look at the comment a few lines below, I last added a comment to it in 2011. I don't remember when I last made any actual code changes to this. (Probably soon after editexisting.vim came around.) If I'd had trouble with it, I would've probably addressed it sooner. (I also suggested modifying it to do what is needed in my original response; this includes improvements.)" SALMAN: If multiple files by the same name are found, they will all be closed. Sometimes, two files with the same name but in different directories are found;
" SALMAN: this should be addressed if it occurs too much.
"
" SALMAN: Last occurrence was on Tuesday, November 15, 2011.
call remote_send( server, ":Closematching " . fnamemodify( filename, ":t" ) . "\<cr>" )And this should use `fnameescape()` and, probably, unknown additional hacks to make file names with newline inside work. Though actually depends on :Closematching definition, maybe it is incorrect in first place and `fnameescape()` will not help.I haven't shared this function before, so the issues you raise haven't come up. I don't have any files that contain relatively uncommon filename characters such as newlines (spaces, yes: Windows, after all) so never had to address it.Why did not you simply use a function and remote_expr instead?I thought about it, but then figured it would offend you more this way. :) Also, I probably knew a bit less about the Vim API five (or more) years ago.This looks like there will be numerous problems than need solution:For various reasons, however, I have managed to avoid most of the pitfalls. Sadly, this good fortune did not extend to the US$1.5B lottery from yesterday.1. Mode: what if server current mode is not normal mode?In my workflow, I don't usually leave Vim sessions in 'not normal mode'. I'm sure it happens, but I don't really do the 'open already opened file' bit very often. Probably been lucky so far.2. Count: what if you have accidentally in server typed `2` before calling this command from remote?Hasn't happened yet. But it's Windows: I'd probably just reboot. :)3. Escaping: depends on the definition of the command.4. Escaping 2: examples like:echo remote_send("gvim", ":sleep 10 | echo ".\ 'server2client(expand("<client>"), "HELLO")<CR>')in help suggest that file named `<CR>` will be interpreted as carriage return and not as literal `<CR>`. So there needs to be additional level of escaping.Certainly, if you experience filenames with special characters in them, you may need to make this function significantly more robust than I have it here.
If you would care to fix the problems herein, I and Kamaraju would appreciate it. My only defense of sharing this feeble implementation is that all the other responses were around the lines of "can't be done" and "your workflow is wrong" (slightly paraphrasing your original response), which, while no doubt resulting in a long hard look at the life decisions by Kamaraju that led to his flawed workflow, don't really get him much closer to a solution that actually has a go at answering his question.
There is such a think as "XY problem": when one asks for a solution for a problem that is a result of encountering another problem which may have more optimal solution, so answering the original question may actually be worthless.
But specifically regarding tabs there is one big problem: almost in every other application that has tabs one tab is bound to one URI (file, page, whatever). In Vim tab has absolutely nothing to do with any URIs: it is a viewport that contains a collection of windows. There is *no* strict connection to buffers. (There is even no direct connection: tabs directly contain only windows and only windows show (not contain) buffers in turn.) So if a person is asking something strange about tabs then 90% he is trying to use them in a way they were not designed to be used.
// Based on your second (not first) message in this thread I even thought that you may have the same problem: code is not suspicious, but "That -- basically (it's a little more complicated) -- executes 'tabdo window' and checks to see if the current file is the same the one passed in and executes 'q!' (quit without saving -- you may want to do an x, instead)." is.
Basically in this case there are four major possibilities I see:
1. OP is trying to open some buffer in another Vim instance: it is better to examine workflow and, probably, change it. This is also invalid use of tabs.
2. OP is opening two projects in one Vim instance and wants to migrate them between WM windows: migrating this is far, far more complicated then your code, but probably one can use sessions with some hacks around them. Again it is better to inspect workflow, maybe plugins for working with projects will serve better. This is one of the use-cases tabs were developed for.
3. OP has one project in both tabs, but for some reason wants one of the tabs separate. Depending on the reason, most likely, solution may be found which keeps one Vim instance and still save the workflow. (Unlike second case tabs are used like "here I write the code and here I do debugging". I personally sometimes have "here I work on one part of the project and here on another" (tabs are preferred over plain buffer switching here because each tab contains two to four windows showing different places (possibly in different buffers) of these parts). This is also one of the intended use-cases.)
4. OP is just wondering or is implicitly suggesting new functionality. Nothing needs to be done in this case.
In any case original request *cannot* be solved with the current codebase. So to give OP anything more meaningful then the very first answer on this thread OP should tell us why does he need this.
Regards,Salman--
--
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 vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
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 vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
No comments:
Post a Comment