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

Re: Diff mode only mappings

Expand Messages
  • Gary Johnson
    ... Because :help FilterWritePre says: FilterWritePre Before writing a file for a filter command or making a diff. so I assumed that it would be
    Message 1 of 9 , Feb 28 10:50 AM
    • 0 Attachment
      On 2006-02-28, Benji Fisher <benji@...> wrote:
      > On Mon, Feb 27, 2006 at 07:09:27PM -0800, Gary Johnson wrote:
      > > On 2006-02-27, Ernest Obusek <eobusek@...> wrote:
      > > > My company uses Perforce for version control and I configured it to
      > > > use vim for diffing files.
      > >
      > > I do the same with ClearCase.
      > >
      > > > I'd like to have certain mappings that only are active when in
      > > > diff mode. How would I accomplish this?
      > >
      > > One way is to detect that vim has entered diff mode with the aid of
      > > the FilterWritePre event, e.g.,:
      > >
      > > au FilterWritePre * if &diff | map <C-N> ]c| endif
      > >
      > > Note that the | immediately follows the map command. Otherwise any
      > > intervening space would be included in rhs of the mapping.
      >
      > 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 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

      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.

      Regards,
      Gary

      --
      Gary Johnson | Agilent Technologies
      garyjohn@... | Wireless Division
      | Spokane, Washington, USA
    • 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 2 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 3 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.