Re: vanishing syntax highlighting problem (debugged)

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: vanishing syntax highlighting problem (debugged)

Hari Krishna Dara

On Tue, 2 Aug 2005 at 1:46pm, Charles E. Campbell, Jr. wrote:

> Hari Krishna Dara wrote:
>
> >For the last few days, I have been having a weird problem with syntax
> >highlighting...
> >
> Hello, Hari!
>
> May I throw another suggestion or two into the hat?
>
> * have you made any recent changes to your <.vimrc>?
> * have you recently added/upgraded any plugins/ftplugins/etc?
>
> Do you have any backups of, say, a month ago when you weren't having
> problems.
> I suggest restoring from your backups (assuming you have any): .vimrc
> and the .vim/
> directory tree.  Move your current .vimrc and .vim to something safe
> first, like
> DOTVIMRC and DOTVIM.
>
> Do your usual editing and see if your problem recurs.  If it doesn't,
> then look for
> changes (use vimdiff, diff, cmp, etc).
>
> If it does, then use an even older backup :) .  I would also suggest
> that you upgrade
> your vim, just in case some patch has already fixed whatever is ailing you.
>
> Regards, and good luck!
> Chip Campbell
>

This happened again today, so I did more diagnosis this time and I
did find the cause of the problem, though not the reason or solution.
- If I set syntax manually it worked, though it went away as soon as I
  reloaded the file, so it appeared like a problem with the syntax
  detection mechansim. So I did the following;
- Ran ":syntax on" with :debug and stepped through the vim code and
  compared it with the same on a working vim session and found the
  problem as being that the ":doautoall syntaxset FileType", did
  nothing. Here are the sessions for the two (which you can skip away):

Non working case:
>>>>
c:/apps/vim/syntax/syntax.vim
line 23: let s:did_ft = 1
>
c:/apps/vim/syntax/syntax.vim
line 24: else
>n
c:/apps/vim/syntax/syntax.vim
line 31: augroup syntaxset
>
c:/apps/vim/syntax/syntax.vim
line 32: au! FileType *^Iexe "set syntax=" . expand("<amatch>")
>
c:/apps/vim/syntax/syntax.vim
line 33: augroup END
>
c:/apps/vim/syntax/syntax.vim
line 40: doautoall syntaxset FileType
>s
c:/apps/vim/syntax/syntax.vim
line 41: if !s:did_ft
>au syntaxset
--- Auto-Commands ---
syntaxset  FileType
    *         exe "set syntax=" . expand("<amatch>")
<<<<

Working case:
>>>>
line 24: else
>
c:/apps/vim/syntax/syntax.vim
line 31: augroup syntaxset
>
c:/apps/vim/syntax/syntax.vim
line 32: au! FileType *^Iexe "set syntax=" . expand("<amatch>")
>
c:/apps/vim/syntax/syntax.vim
line 33: augroup END
>
c:/apps/vim/syntax/syntax.vim
line 40: doautoall syntaxset FileType
>s
FileType Auto commands for "*"
cmd: exe "set syntax=" . expand("<amatch>")
>s
>au syntaxset
--- Auto-Commands ---
syntaxset  FileType
    *         exe "set syntax=" . expand("<amatch>")
<<<<

I confirmed this again by just running this command alone with the
:debug prefix. So I first thought that Vim is entering into some invalid
state, then it occurred to me what the problem could be, and it was
right. The 'eventignore' had a value set to "FileType", so it was
ignoring it. When I rant ":verbose set eventignore?" it pointed me to my
own plugin genutils.vim.

Now for the solution, I can't understand how the 'eventignore' gets set
to this value. No where in the plugin I am setting this value, though
there are a few places that temporarily set 'eventignore' to "all", but
I take care to restore the value, something like this:

  let _eventignore = &eventignore
  try
    set eventignore=all

    " do something.
  finally
    let &eventignore = _eventignore
  endtry


How can it ever be left with a value as "FileType" ? I don't have a
reproducible case so it is hard to debug this, but does anyone have any
idea how this could have happened? At least now I don't have to restart
my vim session (just resetting 'eventignore' seemed to get me on track),
but I believe genutils is used by several people, so I want to make sure
others don't get into the same trouble (though this might be due to a
unique combination of my plugin set and settings).

--
Thanks a lot,
Hari

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com 
Reply | Threaded
Open this post in threaded view
|

Re: vanishing syntax highlighting problem (debugged)

Tim Chase-2
> How can it ever be left with a value as "FileType" ? I don't
> have a reproducible case so it is hard to debug this, but does
> anyone have any idea how this could have happened?

Well, I don't know if this is a red herring/wild-goose-chase, but
I know if you do any argdo/windo/bufdo statement, vim will
disable event processing of at least the Syntax event for each of
those via 'eventignore'.

Alternatively, you could grep through all the files you source
for "filetype" or "eventignore"

        grep -ir 'eventignore' ~/vim/* /usr/share/vim/*

or something of the sort for all the vim resource files on your
machine.  It may throw up loads of chaff, but it should help in
tracking down which file is being referenced.  There's likely
fewer hits regarding "eventignore" than for "filetype"

Alternatively, on starting up vim, you could trace through by
hand, making sure that anything that gets pulled in via a
":source"/":so" statement, or any defined in an autocmd, and
track down anything it's doing.  Other candidate places to look
would be in your syntax/ directory to see if it's causing trouble.

-t




Reply | Threaded
Open this post in threaded view
|

Re: vanishing syntax highlighting problem (debugged)

Hari Krishna Dara
In reply to this post by Hari Krishna Dara

On Fri, 26 Aug 2005 at 2:47pm, Tim Chase wrote:

> > How can it ever be left with a value as "FileType" ? I don't
> > have a reproducible case so it is hard to debug this, but does
> > anyone have any idea how this could have happened?
>
> Well, I don't know if this is a red herring/wild-goose-chase, but
> I know if you do any argdo/windo/bufdo statement, vim will
> disable event processing of at least the Syntax event for each of
> those via 'eventignore'.
>
> Alternatively, you could grep through all the files you source
> for "filetype" or "eventignore"
>
> grep -ir 'eventignore' ~/vim/* /usr/share/vim/*
>
> or something of the sort for all the vim resource files on your
> machine.  It may throw up loads of chaff, but it should help in
> tracking down which file is being referenced.  There's likely
> fewer hits regarding "eventignore" than for "filetype"
>
> Alternatively, on starting up vim, you could trace through by
> hand, making sure that anything that gets pulled in via a
> ":source"/":so" statement, or any defined in an autocmd, and
> track down anything it's doing.  Other candidate places to look
> would be in your syntax/ directory to see if it's causing trouble.
>
> -t

I meanwhile found the place causing the problem. Incidentally, your
suggestion to grep through all the files would have worked well too. As
I said before, I reset the 'eventignore' and continued working, and it
happened again very soon. So I checked again who changed it with a hope
to find a more appropriate answer, and Vim did give me the right
location this time (this doesn't probably indicate that the location
given by vim the last time is wrong. Since I do save and restore this
value in genutils, the original culprit got hidden).  The problem was
caused by an autocommand set in my vimrc to make large files load faster.
Here is the code:


" Based on a post by Chip Campbell
" Augroup LargeFile: for large files: turn undo off, etc (based on vim tip
#611)
" {{{2
let g:LargeFileThreshold = 10*1024*1024 " in megabytes
augroup LargeFile
  au BufReadPre * call <SID>SetLargeFileSettings()
augroup END

function! s:SetLargeFileSettings()
  let f = expand('<afile>')
  if getfsize(f) < g:LargeFileThreshold
    return
  endif

  let b:eikeep= &ei
  let b:ulkeep= &ul
  set ei=FileType
  setlocal noswf bh=unload
  let f=escape(substitute(f,'','/','g'),' ')
  exe "au LargeFile BufEnter ".f." set ul=-1"
  exe "au LargeFile BufLeave ".f." let &ul=".b:ulkeep."|set ei=".b:eikeep
  exe "au LargeFile BufUnload ".f." au! LargeFile * ". f
  echomsg "***note*** handling a large file"
endfunction
" }}}2

As you can see, the 'ei' was set to FileType, and there was no code to
restore it (I don't know if Dr. Chip forgot about it, or if I missed it
while copy pasting his solution). Now I will work on a solving the
problem, may be something that doesn't involve setting 'eventtype'.
Thanks a lot for all who read my long emails and attempted to provide
help for such a wague problem.

--
Thanks,
Hari


               
____________________________________________________
Start your day with Yahoo! - make it your home page
http://www.yahoo.com/r/hs 
 
Reply | Threaded
Open this post in threaded view
|

Re: vanishing syntax highlighting problem (debugged)

Charles E Campbell Jr
Quoting Hari Krishna Dara <[hidden email]>:

> " Based on a post by Chip Campbell
> " Augroup LargeFile: for large files: turn undo off, etc (based on vim tip
> #611)
> " {{{2
> let g:LargeFileThreshold = 10*1024*1024 " in megabytes
> augroup LargeFile
>   au BufReadPre * call <SID>SetLargeFileSettings()
> augroup END
>
> function! s:SetLargeFileSettings()
>   let f = expand('<afile>')
>   if getfsize(f) < g:LargeFileThreshold
>     return
>   endif
>
>   let b:eikeep= &ei
>   let b:ulkeep= &ul
>   set ei=FileType
>   setlocal noswf bh=unload
>   let f=escape(substitute(f,'','/','g'),' ')
>   exe "au LargeFile BufEnter ".f." set ul=-1"
>   exe "au LargeFile BufLeave ".f." let &ul=".b:ulkeep."|set ei=".b:eikeep
>   exe "au LargeFile BufUnload ".f." au! LargeFile * ". f
>   echomsg "***note*** handling a large file"
> endfunction
> " }}}2
>
> As you can see, the 'ei' was set to FileType, and there was no code to
> restore it (I don't know if Dr. Chip forgot about it, or if I missed it
> while copy pasting his solution). Now I will work on a solving the
> problem, may be something that doesn't involve setting 'eventtype'.
> Thanks a lot for all who read my long emails and attempted to provide
> help for such a wague problem.

When one leaves the LargeFile buffer the BufLeave event is supposed to
fire, which should restore the 'ei'.  Syntax highlighting is one of those
things that its best to turn off for large files as synchronization in
particular can make editing such files full of long fruitless waiting spells.

Regards,
Chip Campbell
Reply | Threaded
Open this post in threaded view
|

Re: vanishing syntax highlighting problem (debugged)

Hari Krishna Dara
In reply to this post by Hari Krishna Dara

On Sat, 27 Aug 2005 at 9:26am, [hidden email] wrote:

> Quoting Hari Krishna Dara <[hidden email]>:
>
> > " Based on a post by Chip Campbell
> > " Augroup LargeFile: for large files: turn undo off, etc (based on vim tip
> > #611)
> > " {{{2
> > let g:LargeFileThreshold = 10*1024*1024 " in megabytes
> > augroup LargeFile
> >   au BufReadPre * call <SID>SetLargeFileSettings()
> > augroup END
> >
> > function! s:SetLargeFileSettings()
> >   let f = expand('<afile>')
> >   if getfsize(f) < g:LargeFileThreshold
> >     return
> >   endif
> >
> >   let b:eikeep= &ei
> >   let b:ulkeep= &ul
> >   set ei=FileType
> >   setlocal noswf bh=unload
> >   let f=escape(substitute(f,'','/','g'),' ')
> >   exe "au LargeFile BufEnter ".f." set ul=-1"
> >   exe "au LargeFile BufLeave ".f." let &ul=".b:ulkeep."|set ei=".b:eikeep
> >   exe "au LargeFile BufUnload ".f." au! LargeFile * ". f
> >   echomsg "***note*** handling a large file"
> > endfunction
> > " }}}2
> >
> > As you can see, the 'ei' was set to FileType, and there was no code to
> > restore it (I don't know if Dr. Chip forgot about it, or if I missed it
> > while copy pasting his solution). Now I will work on a solving the
> > problem, may be something that doesn't involve setting 'eventtype'.
> > Thanks a lot for all who read my long emails and attempted to provide
> > help for such a wague problem.
>
> When one leaves the LargeFile buffer the BufLeave event is supposed to
> fire, which should restore the 'ei'.  Syntax highlighting is one of those
> things that its best to turn off for large files as synchronization in
> particular can make editing such files full of long fruitless waiting spells.
>
> Regards,
> Chip Campbell
>

Right, and the BufLeave event was missing here. Rather than adding the
BufLeave event, I think there should be an alternative to setting the
global 'eventignore' setting. May be setting the filetype to some
non-existent value manually would avoid triggering detection? If it is a
non-existent type, there shouldn't be any overhead.

Hari

--
Thanks,
Hari


               
____________________________________________________
Start your day with Yahoo! - make it your home page
http://www.yahoo.com/r/hs