On 2012-07-18, JC Jackson wrote:
> GVIM has a menu item for opening a session, as they call it, and
> that session is saved or read from in a dot vim file, and all
> files one saved as a session open together, screen settings
> restored and all. To open the sessions one must first browse
> through the tree to the directory in which the dot vim file and
> program files are stored, so the directory should not be the
> problem as the files are all right there with the dot vim file. A
> double check shows that GVIM does read an individual file
> correctly with File Open, but the Windows Session Open will Not
> read an Ubuntu Session Save with an opening of the correct files.
> Sounds like you are all saying no such crossover read was ever
> planned?
I think I see the problem. It has to do with Vim's working
directory when the session file was saved on Ubuntu, Vim's working
directory when it is started on Windows, the location of the opened
files relative to those directories, and whether 'sessionoptions'
contains "curdir" (the default) or "sesdir".
If any of those directories or files are saved in the session file
on Ubuntu with full path names, then Vim is not likely to find them
on Windows because the directory structures of Ubuntu and Windows
are very different.
You may have to fiddle with the contents of 'sessionoptions' and
with the working directory of Vim when the session file is saved in
order to get the results you want.
I was able to create a set of text files and a session file on
Ubuntu, copy them to Windows and restore the session there. Instead
of using the "Choose a session to load" button, however, I first
cd'd to the directory of the session file, then sourced it from the
command line.
As I was experimenting with this, I observed two potential problems
with the way Vim saves and restores sessions. One is that Vim saves
and restores the value of 'runtimepath', which is very different
between Ubuntu and Windows. You might be able to fix that with
something like this in your vimrc:
au SessionLoadPost * set rtp&
The other problem is the way that Vim saves the names of the files
being edited. I started a session like this:
$ cd ~/tmp
$ vim -N -u NONE -o file1 file2
When I left 'sessionoptions' at its default, which included
"curdir", and saved that session, the session file included the line
args file1 file2
which works fine as long as Vim can set its working directory on
Windows to what it was on Ubuntu. If you try to get around that
problem by using "sesdir", i.e.,
:set sessionoptions-=curdir
:set sessionoptions+=sesdir
then Vim automatically sets its current directory to that of the
session file, but it saved its arguments as
args ~/tmp/file1 ~/tmp/file2
so it didn't look for the files in the current directory. I think
that's a bug in Vim, but I don't have time to look at it more
carefully at the moment. (Version 7.3.584)
It's difficult to say exactly what happened in your case without
knowing more details such as the names of the directories involved,
but I think what happened is that Vim saved the names of your
program files as just the file names with their paths and saved its
working directory. When you started Vim on Windows, its working
directory was different from what it was on Ubuntu and different
from the directory containing the session file. When you sourced
the session file, Vim couldn't cd to the working directory of the
session file because that directory didn't exist on Windows. When
Vim attempted to open your program files, it couldn't find them
because they weren't in its working directory.
> As to expecting GVIM to open a session alike between Linux and
> Windows, the icon is the same and the name is the same, and they
> download from the same web page, and I know that this is GNU
> stuff, but that makes a brand; and a brand editor or IDE should be
> able to read its own saved crossover files, sessions or not. All
> the other crossover IDEs I use Do read crossover files. If GVIM
> is planned to Not cross read, then the logo and icon really need
> to be different?
> :-))
I think it would be wise to understand the problem before making
comments like that.
Regards,
Gary
--
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
Locked
