Syntax dying

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

Syntax dying

Eric Arnold

I've narrowed down a problem where when I have a window with a custom syntax
set, and I "new" another window from it, jump back to the first window, then
when I "bwipeout! newbuf", the syntax in the first window dies, and I have to
clear and reload it.  Opening and leaving the command window from the
first window also breaks it.

This doesn't happen for the "good" syntax sets (i.e. not mine, but .vim .c
etc.), so I suspect there's something I can do to make it robust.

I'm having the problem in a couple areas, so if it's my bug, then
it's something I'm doing systematically.  The following simple
definitions break for no reason I can find, I just move around in
the file a little bit, and zap the syntax for everything *but*
"whole_line" dies, randomly.

" for highlighting:   /home/Owner/vimfiles/plugin $ cd plug/old

  syn clear
  syn region whole_line start=/^[^$]*$ / end=/$/
  syn region prompt_region  start=/^[^$]*$ / end=/./me=e-1 contained
containedin=whole_line
  syn match prompt /^[^$]*$ / contained containedin=whole_line
  syn match misc_chars /[^$ {}/\\]*/ contained containedin=prompt
  hi link prompt PreProc
  hi link misc_chars Special " LineNr
  hi link whole_line specialkey " LineNr
  syn sync match syncstart groupthere prompt_region /^[^$]*$ /

Reply | Threaded
Open this post in threaded view
|

Re: Syntax dying

Bram Moolenaar

Eric Arnold wrote:

> I've narrowed down a problem where when I have a window with a custom
> syntax set, and I "new" another window from it, jump back to the first
> window, then when I "bwipeout! newbuf", the syntax in the first window
> dies, and I have to clear and reload it.  Opening and leaving the
> command window from the first window also breaks it.

What do you mean with "syntax dies"?

How do you load your syntax file?  Actually, you should give the
sequence of commands you use, starting with "vim -u NONE -U NONE", so
that we can see what exactly happens.  The method you use to load your
syntax file may also matter (using autocommands?).

> This doesn't happen for the "good" syntax sets (i.e. not mine, but
> .vim .c etc.), so I suspect there's something I can do to make it
> robust.
>
> I'm having the problem in a couple areas, so if it's my bug, then
> it's something I'm doing systematically.  The following simple
> definitions break for no reason I can find, I just move around in
> the file a little bit, and zap the syntax for everything *but*
> "whole_line" dies, randomly.

What do you mean with "zap"?

--
Clothes make the man.  Naked people have little or no influence on society.
                               -- Mark Twain (Samuel Clemens) (1835-1910)

 /// Bram Moolenaar -- [hidden email] -- http://www.Moolenaar.net   \\\
///        Sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\              Project leader for A-A-P -- http://www.A-A-P.org        ///
 \\\     Buy LOTR 3 and help AIDS victims -- http://ICCF.nl/lotr.html   ///
Reply | Threaded
Open this post in threaded view
|

Re: Syntax dying

Eric Arnold
In reply to this post by Eric Arnold

--- Bram Moolenaar <[hidden email]> wrote:

>
> Eric Arnold wrote:
>
> > I've narrowed down a problem where when I have a window with a custom
> > syntax set, and I "new" another window from it, jump back to the first
> > window, then when I "bwipeout! newbuf", the syntax in the first window
> > dies, and I have to clear and reload it.  Opening and leaving the
> > command window from the first window also breaks it.
>
> What do you mean with "syntax dies"?

Sorry, I thought "syntax" was synonymous with "highlighting", but I guess
that's not so.  By "dies" I mean that highlighting quits throughout the buffer.
Subsequent "match" commands work.  I just realized that any subsequent "syntax
match" command will bring all the highlighting back to life.


> How do you load your syntax file?  Actually, you should give the
> sequence of commands you use, starting with "vim -u NONE -U NONE", so
> that we can see what exactly happens.  The method you use to load your
> syntax file may also matter (using autocommands?).

The syntax commands are loaded from a function called after the creation of a
new window in a script.  The script is rather long, so I'm not sure what to
post here.  Sometimes the creation of the window is triggered by autocommand
ona filetype, sometimes it is the base key mapping, depending on what the user
does, much like the shorter script, below.

> > This doesn't happen for the "good" syntax sets (i.e. not mine, but
> > .vim .c etc.), so I suspect there's something I can do to make it
> > robust.
> >
> > I'm having the problem in a couple areas, so if it's my bug, then
> > it's something I'm doing systematically.  The following simple
> > definitions break for no reason I can find, I just move around in
> > the file a little bit, and zap the syntax for everything *but*
> > "whole_line" dies, randomly.
>
> What do you mean with "zap"?

Again, the whole buffer loses the syntax highlighting.  The colors go away
although the definitions are still there to look at with ":syn".

Actually, this second case is caused by the same as the first.  The other
script was running, and sneaking in a subwindow creation/wipewout.

In the shorter script the syntax highlighting commands are loaded thus
(there's more to the script, but these are the functions in the load
pathway).


nmap <Leader>s :call InitShell()<cr>
if !exists(':Vishell')
        command -n=? Vishell :call InitShell()
endif

function! InitShell ()

        let g:VSH_insert = 1

        if (expand("%:p:t")=="_vimshell.tmp")
                echo "Already there"
        else
                if ( bufexists ("_vimshell.tmp") )
                        let a = bufwinnr("_vimshell.tmp")
                        if ( a == -1 )
                                sbuffer _vimshell.tmp
                        else
                                execute "normal ".a."\<C-w>w"
                        endif
                else
                        split _vimshell.tmp
                endif
        endif

        call ShellInitSyntax()
        call PrintPrompt()

        call VimShellMaps()
        call VimShellAutoCommands()

endfunction


function! ShellInitSyntax()

        syn clear
        syn region whole_line start=/^[^$]*$ / end=/$/
        syn region prompt_region  start=/^[^$]*$ / end=/./me=e-1
                                \ contained containedin=whole_line
        syn match prompt /^[^$]*$ / contained containedin=whole_line
        syn match misc_chars /[^$ {}/\\]*/ contained containedin=prompt
        hi link prompt PreProc
        hi link misc_chars Special " LineNr
        hi link whole_line specialkey " LineNr
        "syn sync match syncstart groupthere prompt_region /^[^$]*$ /
        syn sync match syncstart groupthere whole_line /^[^$]*$ /
        "syn sync minlines=10
endfunction

au BufNew,BufAdd _vimshell.tmp call VimShellBufEnter()


function! VimShellBufEnter()
        "echomsg "bufenter"
        let s:save_autoindent = &autoindent
        let s:save_tabstop = &tabstop
        setlocal noai
        setlocal tabstop=8 " seems to be the norm for shells
        call ShellInitSyntax()
endfunction


function! VimShellAutoCommands()

        augroup VimShellStuff
                au!
                au BufEnter _vimshell.tmp let &swapfile=0
                au BufEnter _vimshell.tmp call VimShellBufEnter()
                au BufLeave _vimshell.tmp call VimShellBufLeave()
        augroup end

endfunction


function! VimShellBufLeave()
        "echomsg "bufleave"
        let &autoindent = s:save_autoindent
        let &tabstop = s:save_tabstop
endfunction

Reply | Threaded
Open this post in threaded view
|

Re: Syntax dying

Bram Moolenaar

Eric Arnold wrote:

> > > I've narrowed down a problem where when I have a window with a custom
> > > syntax set, and I "new" another window from it, jump back to the first
> > > window, then when I "bwipeout! newbuf", the syntax in the first window
> > > dies, and I have to clear and reload it.  Opening and leaving the
> > > command window from the first window also breaks it.
> >
> > What do you mean with "syntax dies"?
>
> Sorry, I thought "syntax" was synonymous with "highlighting", but I
> guess that's not so.  By "dies" I mean that highlighting quits
> throughout the buffer.  Subsequent "match" commands work.  I just
> realized that any subsequent "syntax match" command will bring all the
> highlighting back to life.

And what about CTRL-L?

> > How do you load your syntax file?  Actually, you should give the
> > sequence of commands you use, starting with "vim -u NONE -U NONE", so
> > that we can see what exactly happens.  The method you use to load your
> > syntax file may also matter (using autocommands?).
>
> The syntax commands are loaded from a function called after the
> creation of a new window in a script.  The script is rather long, so
> I'm not sure what to post here.  Sometimes the creation of the window
> is triggered by autocommand ona filetype, sometimes it is the base key
> mapping, depending on what the user does, much like the shorter
> script, below.

Hmm, this is different from normal syntax highlighting.  Thus this is
the first suspect for the cause of the problem.  Perhaps invoking a
":redraw" command in your script helps?

--
OLD WOMAN: Well, how did you become king, then?
ARTHUR: The Lady of the Lake, her arm clad in the purest shimmering samite,
        held Excalibur aloft from the bosom of the water to signify by Divine
        Providence ...  that I, Arthur, was to carry Excalibur ...  That is
        why I am your king!
                 "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

 /// Bram Moolenaar -- [hidden email] -- http://www.Moolenaar.net   \\\
///        Sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\              Project leader for A-A-P -- http://www.A-A-P.org        ///
 \\\     Buy LOTR 3 and help AIDS victims -- http://ICCF.nl/lotr.html   ///