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

Re: Diff mode only mappings

Expand Messages
  • Benji Fisher
    ... I have not tried it. Does it work well? ... Ouch. That should be wincmd K . Vim hangs with wincmd J . I guess it gets into an infinite loop. ... I
    Message 1 of 9 , Mar 1, 2006
    • 0 Attachment
      On Tue, Feb 28, 2006 at 10:50:57AM -0800, Gary Johnson wrote:
      > On 2006-02-28, Benji Fisher <benji@...> wrote:
      > >
      > > Why FilterWritePre ? Is that triggered when starting as vimdiff or
      > > using :diffsplit , for example?
      >
      > Because ":help FilterWritePre" says:
      >
      > FilterWritePre Before writing a file for a filter
      > command or making a diff.
      >
      > so I assumed that it would be a robust means of detecting entry into
      > diff mode.

      I have not tried it. Does it work well?

      > > I do not think that &diff is set after reading the vimrc file.
      > > From my vimrc file:
      > >
      > > " Get vimdiff to open with horizontal splits.
      > > if &diff
      > > au VimEnter * windo wincmd J
      > > if has("gui_running")
      > > let &columns = &columns + &foldcolumn
      > > endif
      > > endif

      Ouch. That should be "wincmd K". Vim hangs with "wincmd J". I
      guess it gets into an infinite loop.

      > I just did some experiments and verified that you and the others are
      > correct: vimdiff does set &diff before ~/.vimrc is sourced.
      >
      > However, I was bothered by my previous conclusion that &diff was set
      > later. I came to that conclusion some time ago after trying to
      > detect diff mode in my ~/.vim/after/ftplugin/mail.vim plugin; I was
      > sure that &diff was not set when that plugin was executed when
      > running vimdiff on a pair of mail files. So I just tried another
      > experiment. I added these lines to that mail.vim plugin:
      >
      > if !exists("mail_diff_flags")
      > let mail_diff_flags = ""
      > endif
      > if &diff
      > let mail_diff_flags = mail_diff_flags . "T"
      > else
      > let mail_diff_flags = mail_diff_flags . "F"
      > endif
      >
      > executed vimdiff on two mail files, then executed ":echo
      > mail_diff_flags". The result was
      >
      > TF
      >
      > So, &diff was set when the first mail file was read, but was unset
      > when the second mail file was read. That explains my previous
      > conclusion--I had focused on the plugin's behavior in the second
      > window. The &diff option is "local to window", so I'm sure there is
      > some logical reason why it is unset when the second buffer is read,
      > but it does cause a problem when testing for &diff in a filetype
      > plugin.

      I got a similar result by adding

      " When is 'diff' set?
      let diff_flags = ""
      au BufWinEnter * let diff_flags = diff_flags . (&diff ? 'T' : 'F')

      to my vimrc file. (Same result with BufRead instead of BufWinEnter.) I
      do not like this behavior. Maybe we can change it?

      HTH --Benji Fisher
    • Gary Johnson
      ... It seems to. I have this in my ~/.vimrc, au FilterWritePre * if &diff | set virtualedit=all | endif so that I can horizontally scroll from any line in
      Message 2 of 9 , Mar 1, 2006
      • 0 Attachment
        On 2006-03-01, Benji Fisher <benji@...> wrote:
        > On Tue, Feb 28, 2006 at 10:50:57AM -0800, Gary Johnson wrote:
        > > On 2006-02-28, Benji Fisher <benji@...> wrote:
        > > >
        > > > Why FilterWritePre ? Is that triggered when starting as vimdiff or
        > > > using :diffsplit , for example?
        > >
        > > Because ":help FilterWritePre" says:
        > >
        > > FilterWritePre Before writing a file for a filter
        > > command or making a diff.
        > >
        > > so I assumed that it would be a robust means of detecting entry into
        > > diff mode.
        >
        > I have not tried it. Does it work well?

        It seems to. I have this in my ~/.vimrc,

        au FilterWritePre * if &diff | set virtualedit=all | endif

        so that I can horizontally scroll from any line in either window,
        and this in a plugin that gets sourced at startup when I'm in
        certain project directories,

        au BufNewFile,BufRead * match
        au BufNewFile,BufRead *.c,*.h exec 'match RightMargin /^\s\+$\|\%>' . &textwidth . 'v.\+/'
        au FilterWritePre *.c,*.h if &diff | match | endif

        so that code lines that are either too long or blank lines
        containing only spaces are highlighted, but not when diff'ing files.
        I added both of these autocommands to get rid of annoyances and
        since I haven't been annoyed (by them) for a while, they must work!

        > > I just did some experiments and verified that you and the others are
        > > correct: vimdiff does set &diff before ~/.vimrc is sourced.
        > >
        > > However, I was bothered by my previous conclusion that &diff was set
        > > later. I came to that conclusion some time ago after trying to
        > > detect diff mode in my ~/.vim/after/ftplugin/mail.vim plugin; I was
        > > sure that &diff was not set when that plugin was executed when
        > > running vimdiff on a pair of mail files. So I just tried another
        > > experiment. I added these lines to that mail.vim plugin:
        > >
        > > if !exists("mail_diff_flags")
        > > let mail_diff_flags = ""
        > > endif
        > > if &diff
        > > let mail_diff_flags = mail_diff_flags . "T"
        > > else
        > > let mail_diff_flags = mail_diff_flags . "F"
        > > endif
        > >
        > > executed vimdiff on two mail files, then executed ":echo
        > > mail_diff_flags". The result was
        > >
        > > TF
        > >
        > > So, &diff was set when the first mail file was read, but was unset
        > > when the second mail file was read. That explains my previous
        > > conclusion--I had focused on the plugin's behavior in the second
        > > window. The &diff option is "local to window", so I'm sure there is
        > > some logical reason why it is unset when the second buffer is
        > > read, but it does cause a problem when testing for &diff in a
        > > filetype plugin.
        >
        > I got a similar result by adding
        >
        > " When is 'diff' set?
        > let diff_flags = ""
        > au BufWinEnter * let diff_flags = diff_flags . (&diff ? 'T' : 'F')
        >
        > to my vimrc file. (Same result with BufRead instead of BufWinEnter.) I
        > do not like this behavior. Maybe we can change it?

        That would be nice.

        Regards,
        Gary

        --
        Gary Johnson | Agilent Technologies
        garyjohn@... | Wireless Division
        | Spokane, Washington, USA
      Your message has been successfully submitted and would be delivered to recipients shortly.