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

:match and 'hlsearch'

Expand Messages
  • A. J. Mechelynck
    Am I dreaming, or does use of the :match command no more inhibit hlsearch highlighting? If I m right, then line 1195 of doc/pattern.txt isn t needed
    Message 1 of 21 , Mar 1, 2006
      Am I dreaming, or does use of the ":match" command no more inhibit
      'hlsearch' highlighting? If I'm right, then line 1195 of doc/pattern.txt
      isn't needed anymore.

      Test case:
      :set hlsearch
      /e
      :match TODO /i/

      All occurrences of the letter e are still highlighted in Search
      highlighting. Toggling 'hlsearch' and using the ":match" command, with
      or without argument, now act on one kind of highlight without touching
      the other.


      And BTW, IMHO there should be a link to the new |pi_paren.txt| help
      file, not only under 'showmatch' and/or 'matchpairs' (where Bram will
      soon insert it, probably tonight) but also under :match (since, if the
      plugin is active, moving the cursor onto or off from a bracket will now
      kill ":match" highlighting).


      (Vimmers: Go read that help file ;-) the corresponding plugin was only
      added this week.)



      Best regards,
      Tony.
    • Benji Fisher
      ... I think that line in pattern.txt should be clarified, not removed. The idea is that if some character is part of the search text and also matches the
      Message 2 of 21 , Mar 1, 2006
        On Wed, Mar 01, 2006 at 12:28:42PM +0100, A. J. Mechelynck wrote:
        > Am I dreaming, or does use of the ":match" command no more inhibit
        > 'hlsearch' highlighting? If I'm right, then line 1195 of doc/pattern.txt
        > isn't needed anymore.
        >
        > Test case:
        > :set hlsearch
        > /e
        > :match TODO /i/
        >
        > All occurrences of the letter e are still highlighted in Search
        > highlighting. Toggling 'hlsearch' and using the ":match" command, with
        > or without argument, now act on one kind of highlight without touching
        > the other.

        I think that line in pattern.txt should be clarified, not removed.
        The idea is that if some character is part of the search text and also
        matches the :match pattern, then the :match highlighting applies, not
        the Search highlighting. for example, search for vowels and match the
        letter i:

        :set hls
        /[aeiou]
        :match WarningMsg /i/

        and all "i"s will have the WarningMsg highlight. Perhaps change

        The match overrides the 'hlsearch' highlighting.

        to

        The highlighting for {group} applies to matching text even if
        that text also matches a |syntax| group (or the current search
        pattern when 'hlsearch' is set).

        It is not easy to be clear and concise here. Maybe someone else can do
        better.

        > And BTW, IMHO there should be a link to the new |pi_paren.txt| help
        > file, not only under 'showmatch' and/or 'matchpairs' (where Bram will
        > soon insert it, probably tonight) but also under :match (since, if the
        > plugin is active, moving the cursor onto or off from a bracket will now
        > kill ":match" highlighting).

        There should also be a link from doc/tips.txt .

        I would rather change the behavior than add a note under :help
        :match . I think that :match is something I might use on my own, and if
        I do then I would be annoyed if my :match highlighting were canceled by
        matching parentheses. Is there any reason not to do

        :syn match MatchParen /.../ containedin=ALL

        instead of

        :match MatchParen /.../

        and

        :syn clear MatchParen

        instead of

        :match none

        I think the simpler one should be used in doc/tips.txt ; besides, part
        of the idea there is to illustrate techniques, including :match . In
        the plugin, I would rather use the syntax group.

        One difference is that Search highlighting overrides syntax
        highlighting, but :match overrides both. I do not see this as a
        disadvantage. I just tried, and :syn off seems to clear syntax
        definitions but it allows a new one, so that is not a problem. Does
        :match work if vim is compiled with -syntax ? (If so, that is one
        difference between my suggestion and the current one. If not, I think a
        note dhould be added to :help :match .)

        HTH --Benji Fisher
      • Bram Moolenaar
        ... That has been like this for a long time. The remark that the match highlighting overrules search highlighting is that when you have both at one character
        Message 3 of 21 , Mar 1, 2006
          Tony Mechelynck wrote:

          > Am I dreaming, or does use of the ":match" command no more inhibit
          > 'hlsearch' highlighting? If I'm right, then line 1195 of doc/pattern.txt
          > isn't needed anymore.
          >
          > Test case:
          > :set hlsearch
          > /e
          > :match TODO /i/
          >
          > All occurrences of the letter e are still highlighted in Search
          > highlighting. Toggling 'hlsearch' and using the ":match" command, with
          > or without argument, now act on one kind of highlight without touching
          > the other.

          That has been like this for a long time. The remark that the match
          highlighting overrules search highlighting is that when you have both at
          one character then match highlighting is used.

          > And BTW, IMHO there should be a link to the new |pi_paren.txt| help
          > file, not only under 'showmatch' and/or 'matchpairs' (where Bram will
          > soon insert it, probably tonight) but also under :match (since, if the
          > plugin is active, moving the cursor onto or off from a bracket will now
          > kill ":match" highlighting).

          Right, the matchparen plugin uses ":match" and thus clears any previous
          match pattern.

          Perhaps we should use a separate match for the matchparen plugin?
          It's not too difficult, just requires more memory and a bit more time.

          How often would one use both the matchparen plugin and another kind of
          ":match" highlighting?

          I was also wondering if anyone has a problem with the matchparen plugin
          being a standard plugin. Does it interfere with anything? Is the delay
          noticable?

          --
          Q: What is the difference betwee open-source and commercial software?
          A: If you have a problem with commercial software you can call a phone
          number and they will tell you it might be solved in a future version.
          For open-source software there isn't a phone number to call, but you
          get the solution within a day.

          /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
          /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
          \\\ download, build and distribute -- http://www.A-A-P.org ///
          \\\ help me help AIDS victims -- http://www.ICCF.nl ///
        • Bram Moolenaar
          ... One difference that is less obvious: If you add a syntax item then syntax syncing may be come invalid, this may cause a noticable slowdown. :match
          Message 4 of 21 , Mar 1, 2006
            Benji Fisher wrote:

            > I would rather change the behavior than add a note under :help
            > :match . I think that :match is something I might use on my own, and if
            > I do then I would be annoyed if my :match highlighting were canceled by
            > matching parentheses. Is there any reason not to do
            >
            > :syn match MatchParen /.../ containedin=ALL
            >
            > instead of
            >
            > :match MatchParen /.../
            >
            > and
            >
            > :syn clear MatchParen
            >
            > instead of
            >
            > :match none
            >
            > I think the simpler one should be used in doc/tips.txt ; besides, part
            > of the idea there is to illustrate techniques, including :match . In
            > the plugin, I would rather use the syntax group.
            >
            > One difference is that Search highlighting overrides syntax
            > highlighting, but :match overrides both. I do not see this as a
            > disadvantage. I just tried, and :syn off seems to clear syntax
            > definitions but it allows a new one, so that is not a problem. Does
            > :match work if vim is compiled with -syntax ? (If so, that is one
            > difference between my suggestion and the current one. If not, I think a
            > note dhould be added to :help :match .)

            One difference that is less obvious: If you add a syntax item then
            syntax syncing may be come invalid, this may cause a noticable slowdown.
            ":match" highlighting only requires a redraw of the visible text,
            syncing may go back many more lines.

            Also, some syntax files are very tricky. Introducing a new syntax item
            may cause trouble. E.g., because a syntax item that matches parens will
            no longer work.

            More basic: this is not syntax highlighting.

            If it's a problem that other match highlighting disappears then a better
            solution would be to support two of them.

            --
            Bypasses are devices that allow some people to dash from point A to
            point B very fast while other people dash from point B to point A very
            fast. People living at point C, being a point directly in between, are
            often given to wonder what's so great about point A that so many people
            from point B are so keen to get there and what's so great about point B
            that so many people from point A are so keen to get there. They often
            wish that people would just once and for all work out where the hell
            they wanted to be.
            -- Douglas Adams, "The Hitchhiker's Guide to the Galaxy"

            /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
            /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
            \\\ download, build and distribute -- http://www.A-A-P.org ///
            \\\ help me help AIDS victims -- http://www.ICCF.nl ///
          • Mikolaj M.
            ... No problems, no delay. m. ... Interaktywna wystawa HI-TECH z Tokio ODKRYWANIE CZASU nauka, eksperyment, zabawa - Warszawa, Pa³ac Kultury i Nauki do
            Message 5 of 21 , Mar 1, 2006
              >
              > I was also wondering if anyone has a problem with the matchparen plugin
              > being a standard plugin. Does it interfere with anything? Is the delay
              > noticable?

              No problems, no delay.

              m.

              ----------------------------------------------------
              Interaktywna wystawa HI-TECH z Tokio ODKRYWANIE CZASU
              nauka, eksperyment, zabawa -> Warszawa, Pałac Kultury i Nauki
              do 29.11.2006 wspaniała rozrywka dla całej rodziny!
              http://klik.wp.pl/?adr=http%3A%2F%2Fadv.reklama.wp.pl%2Fas%2Fczas.html&sid=677
            • Halim, Salman
              That s not all! The sign line highlight no longer clobbers search and match, either! Did my piddling request have something to do this with, I wonder? :)
              Message 6 of 21 , Mar 1, 2006
                That's not all! The sign line highlight no longer clobbers search and
                match, either!

                Did my piddling request have something to do this with, I wonder? :)

                Thanks a bunch,

                Salman.

                > Am I dreaming, or does use of the ":match" command no more
                > inhibit 'hlsearch' highlighting? If I'm right, then line 1195
                > of doc/pattern.txt isn't needed anymore.
                >
                > Test case:
                > :set hlsearch
                > /e
                > :match TODO /i/
                >
                > All occurrences of the letter e are still highlighted in
                > Search highlighting. Toggling 'hlsearch' and using the
                > ":match" command, with or without argument, now act on one
                > kind of highlight without touching the other.

                ...

                > Best regards,
                > Tony.
              • A. J. Mechelynck
                Bram Moolenaar wrote: [...] ... Ah, a misunderstanding on my part then. ... I think that could vary quite a lot from user to user. Personally I almost never
                Message 7 of 21 , Mar 1, 2006
                  Bram Moolenaar wrote:
                  [...]
                  > That has been like this for a long time. The remark that the match
                  > highlighting overrules search highlighting is that when you have both at
                  > one character then match highlighting is used.

                  Ah, a misunderstanding on my part then.

                  >
                  >> And BTW, IMHO there should be a link to the new |pi_paren.txt| help
                  >> file, not only under 'showmatch' and/or 'matchpairs' (where Bram will
                  >> soon insert it, probably tonight) but also under :match (since, if the
                  >> plugin is active, moving the cursor onto or off from a bracket will now
                  >> kill ":match" highlighting).
                  >
                  > Right, the matchparen plugin uses ":match" and thus clears any previous
                  > match pattern.
                  >
                  > Perhaps we should use a separate match for the matchparen plugin?
                  > It's not too difficult, just requires more memory and a bit more time.
                  >
                  > How often would one use both the matchparen plugin and another kind of
                  > ":match" highlighting?

                  I think that could vary quite a lot from user to user. Personally I
                  almost never use ":match", and at first the plugin seemed mildly
                  annoying to me; but I guess I would use it more if my programming
                  language of choice was LISP ;-) or even C, rather than HTML. (But if it
                  were LISP, wouldn't I be editing in Emacs? ;-) )

                  >
                  > I was also wondering if anyone has a problem with the matchparen plugin
                  > being a standard plugin. Does it interfere with anything? Is the delay
                  > noticable?
                  >

                  The few times that I saw that highlight, I never noticed any delay.
                  IIUC, it won't even try to look farther away than the limits of the
                  current window, so the size of the editfile oughtn't to matter. And
                  after your mail of this morning I made the following mappings:

                  :map <F5> :DoMatchParen()<CR>
                  :map <C-F5> :NoMatchParen()<CR>
                  :imap <F5> <C-O>:DoMatchParen()<CR>
                  :imap <C-F5> <C-O>:NoMatchParen()<CR>

                  so I have it available at the press of a key if ever I want it.

                  BTW, what would you think of an additional command, ":ToggleMatchParen"?
                  And/or letting user scripts know whether match-paren highlighting is
                  currently on or off? Either replace s:paren_hl_on by b:paren_hl_on or,
                  maybe more secure,

                  function paren_hl_status()
                  return s:paren_hl_on
                  endfunction

                  affording read-only access to the variable (write access is by means of
                  the *MatchParen commands).

                  I have given some thought to the implications of making paren_hl_on
                  buffer-local; I suppose it would be possible but would require a global
                  companion variable so the user could set the default for future buffers.
                  I'm not sure it's worth the trouble.


                  Best regards,
                  Tony.
                • Halim, Salman
                  ... I second that, though I would like to add that I would prefer to have the enable/disable be on a per-buffer basis: I would set it in the ftplugin for
                  Message 8 of 21 , Mar 1, 2006
                    > I was also wondering if anyone has a problem with the matchparen
                    > plugin being a standard plugin. Does it interfere with
                    > anything? Is the delay noticable?

                    I second that, though I would like to add that I would prefer to have
                    the enable/disable be on a per-buffer basis: I would set it in the
                    ftplugin for java, HTML/XML and Vim, for example, but leave it disabled
                    for when I'm typing up an email message or something like that.

                    I do occasionally use :match to highlight lines that are too long
                    (beyond my current &tw) and this would clobber that, but I could choose
                    to disable it if I really wanted.

                    If it is extended to also highlight surrounding brackets (please!) or
                    the area within with a special background (as was suggested in the
                    todo), then speed might become an issue. I get around that by faking
                    things like this:

                    autocmd! CursorMoved,CursorMovedI <buffer> if LongEnough(
                    "b:matchparen_timer", 2, 5 ) | call s:Highlight_Matching_Pair() | endif
                    autocmd! CursorHold,CursorHoldI <buffer> call
                    s:Highlight_Matching_Pair()

                    (Of course, in the global version, you'd replace the <buffer> with * and
                    b:matchparen_timer with g:...)

                    LongEnough is a function I wrote specifically for CursorMoved-related
                    autocommands to ameliorate the slow-down effect (based on a discussion
                    with Tony two weeks or so ago) -- calling it with the name of a variable
                    in which to store the time of the last access (it will create a variable
                    called b:matchparen_timer_callCount also) and "2, 5" means to return 1
                    (true) no more than once every 2 seconds OR every 5 calls. In other
                    words, it would match the surrounding parentheses if either 2 seconds
                    have elapsed since it last returned true or the cursor has moved 5 times
                    (the motion key was held down) -- it's not the immediate response one
                    would like, but it's a tradeoff between immediate response and things
                    sloing down too much. The CursorHold version further helps if I just
                    sit still for a while without moving anything:

                    " Returns true if at least delay seconds have elapsed since the last
                    time this function was called, based on the time
                    " contained in the variable "timer". The first time it is called, the
                    variable is defined and the function returns
                    " true.
                    "
                    " True means not zero.
                    "
                    " For example, to execute something no more than once every two seconds
                    using a variable named "b:myTimer", do this:
                    "
                    " if LongEnough( "b:myTimer", 2 )
                    " <do the thing>
                    " endif
                    "
                    " The optional 3rd parameter is the number of times to suppress the
                    operation within the specified time and then let it
                    " happen even though the required delay hasn't happened. For example:
                    "
                    " if LongEnough( "b:myTimer", 2, 5 )
                    " <do the thing>
                    " endif
                    "
                    " Means to execute either every 2 seconds or every 5 calls, whichever
                    happens first.
                    function! LongEnough( timer, delay, ... )
                    let result = 0

                    let suppressionCount = 0
                    if ( exists( 'a:1' ) )
                    let suppressionCount = a:1
                    endif

                    " This is the first time we're being called.
                    if ( !exists( a:timer ) )
                    let result = 1
                    else
                    let timeElapsed = localtime() - {a:timer}

                    " If it's been a while...
                    if ( timeElapsed >= a:delay )
                    let result = 1
                    elseif ( suppressionCount > 0 )
                    let {a:timer}_callCount += 1

                    " It hasn't been a while, but the number of times we have been
                    called has hit the suppression limit, so we activate
                    " anyway.
                    if ( {a:timer}_callCount >= suppressionCount )
                    let result = 1
                    endif
                    endif
                    endif

                    " Reset both the timer and the number of times we've been called since
                    the last update.
                    if ( result )
                    let {a:timer} = localtime()
                    let {a:timer}_callCount = 0
                    endif

                    return result
                    endfunction
                  • Bram Moolenaar
                    ... No, no, I completely ignore user requests! :-) Watch out for problems with highlighting though, the priority stuff is tricky. -- Making it up? Why
                    Message 9 of 21 , Mar 1, 2006
                      Halim Salman wrote:

                      > That's not all! The sign line highlight no longer clobbers search and
                      > match, either!
                      >
                      > Did my piddling request have something to do this with, I wonder? :)

                      No, no, I completely ignore user requests! :-)


                      Watch out for problems with highlighting though, the priority stuff is
                      tricky.

                      --
                      "Making it up? Why should I want to make anything up? Life's bad enough
                      as it is without wanting to invent any more of it."
                      -- Marvin, the Paranoid Android in Douglas Adams'
                      "The Hitchhiker's Guide to the Galaxy"

                      /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
                      /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
                      \\\ download, build and distribute -- http://www.A-A-P.org ///
                      \\\ help me help AIDS victims -- http://www.ICCF.nl ///
                    • Yakov Lerner
                      ... Why not allow N separate match es, identified by user-supplied name ? For example, then match Column80 Error / %80c.*/ would peacefully coexist with
                      Message 10 of 21 , Mar 1, 2006
                        "Bram Moolenaar" <Bram@...> wrote:
                        > Right, the matchparen plugin uses ":match" and thus clears any previous
                        > match pattern.
                        >
                        > Perhaps we should use a separate match for the matchparen plugin?

                        Why not allow N separate match'es, identified by user-supplied name ?

                        For example, then 'match Column80 Error /\%80c.*/' would peacefully
                        coexist with paren-match and with 'unnamed' match set manually by the
                        user.

                        I use match sometimes. I think there might be uses for named matches.

                        Yakov
                        --

                        iler_ml@...

                        --
                        http://www.fastmail.fm - Does exactly what it says on the tin
                      • Bram Moolenaar
                        ... That s getting very complicated. It would require additional commands to list the matches defined, clear matches by name or all of them, etc.
                        Message 11 of 21 , Mar 1, 2006
                          Yakov Lerner wrote:

                          > "Bram Moolenaar" <Bram@...> wrote:
                          > > Right, the matchparen plugin uses ":match" and thus clears any previous
                          > > match pattern.
                          > >
                          > > Perhaps we should use a separate match for the matchparen plugin?
                          >
                          > Why not allow N separate match'es, identified by user-supplied name ?
                          >
                          > For example, then 'match Column80 Error /\%80c.*/' would peacefully
                          > coexist with paren-match and with 'unnamed' match set manually by the
                          > user.
                          >
                          > I use match sometimes. I think there might be uses for named matches.

                          That's getting very complicated. It would require additional commands
                          to list the matches defined, clear matches by name or all of them, etc.
                          Implementation isn't simple either.

                          I tend to think that two or three matches will be sufficient. One for
                          the matchparen plugin, one for manual matching and one for another
                          plugin.

                          --
                          How To Keep A Healthy Level Of Insanity:
                          1. At lunch time, sit in your parked car with sunglasses on and point
                          a hair dryer at passing cars. See if they slow down.

                          /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
                          /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
                          \\\ download, build and distribute -- http://www.A-A-P.org ///
                          \\\ help me help AIDS victims -- http://www.ICCF.nl ///
                        • Halim, Salman
                          This gets my vote. Salman.
                          Message 12 of 21 , Mar 1, 2006
                            This gets my vote.

                            Salman.

                            > Why not allow N separate match'es, identified by user-supplied name ?
                            >
                            > For example, then 'match Column80 Error /\%80c.*/' would
                            > peacefully coexist with paren-match and with 'unnamed' match
                            > set manually by the user.
                            >
                            > I use match sometimes. I think there might be uses for named matches.
                            >
                            > Yakov
                            > --
                          • Nikolai Weibull
                            ... I realize that it would be additional work, but I think it would be worth it. There are quite a few things the :match command could be used for that can t
                            Message 13 of 21 , Mar 1, 2006
                              On 3/1/06, Bram Moolenaar <Bram@...> wrote:
                              >
                              > Yakov Lerner wrote:
                              > > Why not allow N separate match'es, identified by user-supplied name ?
                              > >
                              > > For example, then 'match Column80 Error /\%80c.*/' would peacefully
                              > > coexist with paren-match and with 'unnamed' match set manually by the
                              > > user.
                              > >
                              > > I use match sometimes. I think there might be uses for named matches.
                              >
                              > That's getting very complicated. It would require additional commands
                              > to list the matches defined, clear matches by name or all of them, etc.
                              > Implementation isn't simple either.
                              >
                              > I tend to think that two or three matches will be sufficient. One for
                              > the matchparen plugin, one for manual matching and one for another
                              > plugin.

                              I realize that it would be additional work, but I think it would be
                              worth it. There are quite a few things the :match command could be
                              used for that can't be done with syntax highlighting. I suppose
                              Tony's database-record lister is one plugin that could use it. Then
                              there's the column-X-type plugin that highlights too-long lines. I
                              was considering it for doing interactive-applications in Vim, but then
                              saw that it only supported one match at a time and forgot about it.

                              If we're going to go for two or three, then N is probably just as easy
                              to implement anyway, as a more general solution is generally (see)
                              easier to do.

                              nikolai

                              P.S.
                              Even further: it would be quite cool to be able to modify the
                              syntax-tree, i.e., being able to do something like

                              :call highlightline(5, Comment)

                              and even more fine-grained control, i.e., per-character highlighting.
                              But I guess that might be getting a bit too close to an operating
                              system.
                              D.S.
                            • mzyzik@gmail.com
                              wow this gets my vote also I always just thought I was misusing :match somehow when I tried to match several things --Matt
                              Message 14 of 21 , Mar 1, 2006
                                wow this gets my vote also

                                I always just thought I was misusing :match somehow when I tried to
                                match several things

                                --Matt

                                On Wed, Mar 01, 2006 at 01:58:23PM -0500, Halim, Salman wrote:
                                > This gets my vote.
                                >
                                > Salman.
                                >
                                > > Why not allow N separate match'es, identified by user-supplied name ?
                                > >
                                > > For example, then 'match Column80 Error /\%80c.*/' would
                                > > peacefully coexist with paren-match and with 'unnamed' match
                                > > set manually by the user.
                                > >
                                > > I use match sometimes. I think there might be uses for named matches.
                                > >
                                > > Yakov
                                > > --
                              • mzyzik@gmail.com
                                ... Ok I m confused. What can :match do that :syn match cannot? And for reference, I always use this in all my buffers: highlight WhiteSpaceEOL
                                Message 15 of 21 , Mar 1, 2006
                                  > I realize that it would be additional work, but I think it would be
                                  > worth it. There are quite a few things the :match command could be
                                  > used for that can't be done with syntax highlighting.

                                  Ok I'm confused. What can ":match" do that ":syn match" cannot?

                                  And for reference, I always use this in all my buffers:
                                  highlight WhiteSpaceEOL ctermbg=darkgreen guibg=lightgreen
                                  match WhiteSpaceEOL /\(^\s*\)\@<=\ \|\s\+$/
                                  It matches all trailing whitespace and also any spaces in leading
                                  whitespace.

                                  If I do another match it clears the first. I noticed that I can do
                                  multiple ":syn match" though. Can someone explain the difference.

                                  --Matt
                                • Charles E. Campbell, Jr.
                                  ... Priority. Example: assume one has a syn match for strings: this is a string that stretches out past 40 characters Assume one has a match: match Error
                                  Message 16 of 21 , Mar 1, 2006
                                    mzyzik@... wrote:

                                    >Ok I'm confused. What can ":match" do that ":syn match" cannot?
                                    >
                                    >

                                    Priority.

                                    Example: assume one has a syn match for strings:

                                    "this is a string that stretches out past 40 characters"

                                    Assume one has a match:

                                    match Error "/\%>40c"

                                    With this setup, anything past column 40 will be Error highlighted.
                                    However, changing that match to a syn match:

                                    syn match Error '/\%>40c'

                                    and you won't see any Error highlighting. Why? Because the string
                                    highlighting began in column 2 *and continues*
                                    until its match is over. Note that the string highlighting does not
                                    contain the syn-match-Error. This problem is typical
                                    of trying to shove a syn-match-Error of the sort shown into the
                                    highlighting mix -- it doesn't have priority, isn't contained,
                                    etc.

                                    Furthermore, assume that you modify the string handling to contain your
                                    new syn-match-error, but note that the string's
                                    ending is inside the syn-match-Error, *not* inside the string match.
                                    Now your strings won't terminate correctly.

                                    Regards,
                                    Chip Campbell
                                  • A. J. Mechelynck
                                    ... Possibility 1: We already have named autocommand groups. Couldn t we have similar (and similarly optional) match groups, thus allowing an unlimited number
                                    Message 17 of 21 , Mar 1, 2006
                                      Bram Moolenaar wrote:
                                      > Yakov Lerner wrote:
                                      >
                                      >> "Bram Moolenaar" <Bram@...> wrote:
                                      >>> Right, the matchparen plugin uses ":match" and thus clears any previous
                                      >>> match pattern.
                                      >>>
                                      >>> Perhaps we should use a separate match for the matchparen plugin?
                                      >> Why not allow N separate match'es, identified by user-supplied name ?
                                      >>
                                      >> For example, then 'match Column80 Error /\%80c.*/' would peacefully
                                      >> coexist with paren-match and with 'unnamed' match set manually by the
                                      >> user.
                                      >>
                                      >> I use match sometimes. I think there might be uses for named matches.
                                      >
                                      > That's getting very complicated. It would require additional commands
                                      > to list the matches defined, clear matches by name or all of them, etc.
                                      > Implementation isn't simple either.
                                      >
                                      > I tend to think that two or three matches will be sufficient. One for
                                      > the matchparen plugin, one for manual matching and one for another
                                      > plugin.
                                      >

                                      Possibility 1: We already have named autocommand groups. Couldn't we
                                      have similar (and similarly optional) match groups, thus allowing an
                                      unlimited number of parallel (named) matches but keeping the present
                                      behaviour by default (if no matchgroups are used)?

                                      Possibility 2: Alternately, why stay at a meagre two or three? Let's
                                      foresee ten of them (:match or :0match, :1match, .. :9match). As my old
                                      chemistry teacher used to say: "If you want to have enough, make sure
                                      you have too much."


                                      Best regards,
                                      Tony.
                                    • Benji Fisher
                                      ... I like the first suggestion. Perhaps search highlighting could be made part of the :match hierarchy (matchgroup Search). One issue to consider is
                                      Message 18 of 21 , Mar 1, 2006
                                        On Thu, Mar 02, 2006 at 12:24:17AM +0100, A. J. Mechelynck wrote:
                                        >
                                        > Possibility 1: We already have named autocommand groups. Couldn't we
                                        > have similar (and similarly optional) match groups, thus allowing an
                                        > unlimited number of parallel (named) matches but keeping the present
                                        > behaviour by default (if no matchgroups are used)?
                                        >
                                        > Possibility 2: Alternately, why stay at a meagre two or three? Let's
                                        > foresee ten of them (:match or :0match, :1match, .. :9match). As my old
                                        > chemistry teacher used to say: "If you want to have enough, make sure
                                        > you have too much."

                                        I like the first suggestion. Perhaps search highlighting could be
                                        made part of the :match hierarchy (matchgroup Search). One issue to
                                        consider is priority. If I have

                                        matchgroup Foo
                                        match Search /[aeiou]/

                                        matchgroup Bar
                                        match WarningMsg /[abcde]/

                                        matchgroup END

                                        then how does "a" get highlighted? I suggest letting the last-defined
                                        match win. I suspect it is easy to implement; it means that whatever
                                        match I define right now shows its effect immediately; and if
                                        "matchgroup Search" is defined internally, then :match has priority over
                                        hlsearch, so it is backwards compatible.

                                        Bram, once again you have proven that the problem with adding new
                                        features is that we users just ask for more. It is like juggling:
                                        "Wow, you can juggle four! Can you do five?"

                                        HTH --Benji Fisher
                                      • A. J. Mechelynck
                                        ... To which group (if any) does the baz match belong? Hypothesis 1: stack : matchgroup END closes group bar and group foo reverts. Hypothesis 2:
                                        Message 19 of 21 , Mar 1, 2006
                                          Benji Fisher wrote:
                                          > On Thu, Mar 02, 2006 at 12:24:17AM +0100, A. J. Mechelynck wrote:
                                          >> Possibility 1: We already have named autocommand groups. Couldn't we
                                          >> have similar (and similarly optional) match groups, thus allowing an
                                          >> unlimited number of parallel (named) matches but keeping the present
                                          >> behaviour by default (if no matchgroups are used)?
                                          >>
                                          >> Possibility 2: Alternately, why stay at a meagre two or three? Let's
                                          >> foresee ten of them (:match or :0match, :1match, .. :9match). As my old
                                          >> chemistry teacher used to say: "If you want to have enough, make sure
                                          >> you have too much."
                                          >
                                          > I like the first suggestion. Perhaps search highlighting could be
                                          > made part of the :match hierarchy (matchgroup Search). One issue to
                                          > consider is priority. If I have
                                          >
                                          > matchgroup Foo
                                          > match Search /[aeiou]/
                                          >
                                          > matchgroup Bar
                                          > match WarningMsg /[abcde]/
                                          >
                                          > matchgroup END
                                          >
                                          > then how does "a" get highlighted? I suggest letting the last-defined
                                          > match win. I suspect it is easy to implement; it means that whatever
                                          > match I define right now shows its effect immediately; and if
                                          > "matchgroup Search" is defined internally, then :match has priority over
                                          > hlsearch, so it is backwards compatible.
                                          >
                                          > Bram, once again you have proven that the problem with adding new
                                          > features is that we users just ask for more. It is like juggling:
                                          > "Wow, you can juggle four! Can you do five?"
                                          >
                                          > HTH --Benji Fisher
                                          >
                                          >
                                          >

                                          :matchgroup foo
                                          :match User1 /foo/
                                          :matchgroup bar
                                          :match User2 /bar/
                                          :matchgroup END
                                          :match Todo /baz/

                                          To which group (if any) does the "baz" match belong?

                                          Hypothesis 1: "stack": "matchgroup END" closes group "bar" and group
                                          "foo" reverts.

                                          Hypothesis 2: "one-at-a-time": "matchgroup bar" closes group foo,
                                          "matchgroup END" closes group bar, "match /baz/" is in the default
                                          (unnamed) group.

                                          Hypothesis 2 seems more consistent with ":redir END" and ":augroup END".

                                          -----

                                          matchgroup foo
                                          match Title /[abcde]/
                                          matchgroup bar
                                          match Todo /[aeiou]/
                                          " the letter a is highlighted as Todo
                                          matchgroup foo
                                          match Title /[aáàâäå]/
                                          " I suppose the latter brings group foo "to the front" and
                                          " highlights a in Title?
                                          match
                                          " I suppose this undefines the "foo" match, so group "bar"
                                          " reverts and a is again in Todo?


                                          Best regards,
                                          Tony.
                                        • Bram Moolenaar
                                          ... Right. That s why I think three matches are enough. If you try to juggle four you ll get confused and drop one. You appear to underestimate the impact
                                          Message 20 of 21 , Mar 2, 2006
                                            Benji Fisher wrote:

                                            > On Thu, Mar 02, 2006 at 12:24:17AM +0100, A. J. Mechelynck wrote:
                                            > >
                                            > > Possibility 1: We already have named autocommand groups. Couldn't we
                                            > > have similar (and similarly optional) match groups, thus allowing an
                                            > > unlimited number of parallel (named) matches but keeping the present
                                            > > behaviour by default (if no matchgroups are used)?
                                            > >
                                            > > Possibility 2: Alternately, why stay at a meagre two or three? Let's
                                            > > foresee ten of them (:match or :0match, :1match, .. :9match). As my old
                                            > > chemistry teacher used to say: "If you want to have enough, make sure
                                            > > you have too much."
                                            >
                                            > I like the first suggestion. Perhaps search highlighting could be
                                            > made part of the :match hierarchy (matchgroup Search). One issue to
                                            > consider is priority. If I have
                                            >
                                            > matchgroup Foo
                                            > match Search /[aeiou]/
                                            >
                                            > matchgroup Bar
                                            > match WarningMsg /[abcde]/
                                            >
                                            > matchgroup END
                                            >
                                            > then how does "a" get highlighted? I suggest letting the last-defined
                                            > match win. I suspect it is easy to implement; it means that whatever
                                            > match I define right now shows its effect immediately; and if
                                            > "matchgroup Search" is defined internally, then :match has priority over
                                            > hlsearch, so it is backwards compatible.
                                            >
                                            > Bram, once again you have proven that the problem with adding new
                                            > features is that we users just ask for more. It is like juggling:
                                            > "Wow, you can juggle four! Can you do five?"

                                            Right. That's why I think three matches are enough. If you try to
                                            juggle four you'll get confused and drop one.

                                            You appear to underestimate the impact matches have on redrawing speed.
                                            There is a penatly for having to redraw more often and a penalty per
                                            character to check for highlighting. I rather have plugin developers
                                            stuggle with the small number of matches available than me having to
                                            struggle to keep redrawing speedy. Sometimes less is better.

                                            --
                                            How To Keep A Healthy Level Of Insanity:
                                            7. Finish all your sentences with "in accordance with the prophecy".

                                            /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
                                            /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
                                            \\\ download, build and distribute -- http://www.A-A-P.org ///
                                            \\\ help me help AIDS victims -- http://www.ICCF.nl ///
                                          • Nikolai Weibull
                                            ... Why not let plugin developers and the people that install them worry about redrawing speeds. If people install too many plugins and thus impair their
                                            Message 21 of 21 , Mar 2, 2006
                                              On 3/2/06, Bram Moolenaar <Bram@...> wrote:
                                              > You appear to underestimate the impact matches have on redrawing speed.
                                              > There is a penatly for having to redraw more often and a penalty per
                                              > character to check for highlighting. I rather have plugin developers
                                              > stuggle with the small number of matches available than me having to
                                              > struggle to keep redrawing speedy. Sometimes less is better.

                                              Why not let plugin developers and the people that install them worry
                                              about redrawing speeds. If people install too many plugins and thus
                                              impair their redrawing speeds then let them fix it by picking and
                                              choosing the set of plugins that they can't live without. Just make
                                              it clear in the documentation the reasons for too many matches being a
                                              performance hog.

                                              It's better to plan something that can grow with more CPU-speed
                                              further on than to be locked into something that worked 2006 on an
                                              MS-DOS system or whatever system we're worrying about today. Let's
                                              not forget the quote that pops up in your signature once every so
                                              often about people never needing more than 640 kilobyte of memory, as
                                              said by a certain rich fellow that has built an operating system that
                                              is basically collapsing over itself due to backwards-compatibility
                                              issues and just a horrendous amount of code that has been
                                              incrementally put together to deal with new word-sizes and new
                                              technologies subsuming old ones. And while that quote is probably not
                                              correctly attributed, see http://en.wikiquote.org/wiki/Talk:Bill_Gates44
                                              and http://en.wikiquote.org/wiki/Bill_Gates45, I still think it is a
                                              point to consider.

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