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

Re: :match and 'hlsearch'

Expand Messages
  • 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 1 of 21 , Mar 1, 2006
    • 0 Attachment
      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 2 of 21 , Mar 1, 2006
      • 0 Attachment
        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 3 of 21 , Mar 1, 2006
        • 0 Attachment
          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 4 of 21 , Mar 1, 2006
          • 0 Attachment
            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 5 of 21 , Mar 1, 2006
            • 0 Attachment
              > 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 6 of 21 , Mar 1, 2006
              • 0 Attachment
                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 7 of 21 , Mar 1, 2006
                • 0 Attachment
                  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 8 of 21 , Mar 1, 2006
                  • 0 Attachment
                    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 9 of 21 , Mar 1, 2006
                    • 0 Attachment
                      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 10 of 21 , Mar 2, 2006
                      • 0 Attachment
                        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 11 of 21 , Mar 2, 2006
                        • 0 Attachment
                          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.