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.
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.
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.
No comments:
Post a Comment