Loading ...
Sorry, an error occurred while loading the content.

Re: The arbitrariness of vim

Expand Messages
  • Mathias Michaelis
    Bram sorry for replying so late ... I was in a hurry for the last few weeks. ... Wow -- a special version of vim for my purposes only :-) Alas, I am not able
    Message 1 of 3 , Mar 31, 2005
    • 0 Attachment
      Bram

      sorry for replying so late ... I was in a hurry for the last few weeks.

      >> 1b) If I however reopened the text file by
      >>
      >> vim -u cfg.vim -S script.vim text.txt
      >>
      >> then only the column of the cursor was restored. The line was
      >> not. Work around: I had to repeat the "normal g`\"" command
      >> within script.vim.
      >>
      > I think this patch avoids the problem without causing too much trouble:
      >
      > *** main.c~ Fri Feb 25 14:48:17 2005
      > --- main.c Thu Mar 17 14:59:45 2005
      > ***************
      > etc ...
      >
      Wow -- a special version of vim for my purposes only :-) Alas, I am
      not able to compile my own vim yet, because yet I lack the time to
      find and study the appropriate tools for that :-\

      >> 2) I opened an instance of vim by
      >>
      >> vim -u cfg.vim --servername TEST text.txt
      >>
      >> in one cmd/xterm window. The cursor was placed correctly. Now I
      >> did the following:
      >>
      >> a) vim -u cfg.vim --servername TEST --remote \
      >> +"source script.vim" text.txt
      >>
      >> b) vim -u cfg.vim --servername TEST --remote \
      >> +"source script.vim | source script.vim" text.txt
      >>
      >> ...
      >>
      >> The command a) worked correctly. The command b) however worked
      >> only on Knoppix Linux correctly. On Windows XP I was asked by
      >> the TEST instance of vim to press the ENTER key.
      >>
      > That is not unusual, it's probably caused by a difference in the
      > 'shortmess' option. Or a difference in window size.
      >
      Yeah, it seems to be the latter. The 'shortmess' option is the same
      (filnxtToO) on both systems since I call vim with the same -u
      cfg.vim switch.

      On Linux, the window width must be at least 74 chars. On Windows
      within cmd.exe the width can't be changed: When vim is called, it
      switches always back to a 80 char width console. And this seems to
      be to narrow to prevent the "Press ENTER key" message (whereas in
      Linux this seems to be enough).

      But why must vims window exceed some minimal width in order to avoid
      the "Press ENTER key" message when started with +"source script1.vim
      | source script2.vim", whereas +"source script1.vim" is always silent?

      Anyway, my simple work around is to call vim twice, first with the
      command to source script1.vim, then with the command to source
      script2.vim.

      >> I made a further trial:
      >>
      >> d) vim -u cfg.vim --servername TEST --remote \
      >> +"start<cr>" text.txt
      >>
      >> With astonishment I remarked that the text
      >>
      >> "|cal foreground()|if &im|star|en|ec"
      >>
      >> (without quotes) and an ending carriage return was inserted in
      >> my text before the current cursor position (in Windows as well
      >> as in Linux).
      >>
      > Yep, that's because you start insert mode while the client is still
      > sending commands to edit the file ...
      >
      Thanks for your replies!

      Best regards

      Mathias
    Your message has been successfully submitted and would be delivered to recipients shortly.