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

IDE and 'signs'

Expand Messages
  • Michael Geddes
    Without meaning to offend anyone too much, I wanted to have a whinge about the way the Sun Work* stuff was implemented... in particular, the way signs in
    Message 1 of 4 , Jan 1, 2001
    • 0 Attachment
      Without meaning to offend anyone too much, I wanted to have a whinge about
      the way the Sun Work* stuff was implemented... in particular, the way
      'signs' in the margin were done seemed particularly inelegant to me. (feel
      free to read this as "sucks badly")

      I like the idea of having marks in the margin, and I would have thought
      there was a way of doing this that allowed it used in a non-gui context as
      well.

      I also dispute the following paragraph from sign.txt

      > Creating and deleting signs are obvious functions. Why change sign type
      and
      > jump to sign? Some debuggers have different signs for a breakpoint and the
      > same breakpoint when the debugger is stopped at that breakpoint. Since the
      > debugger may stop at a breakpoint often, it makes sense to allow the sign
      > type to change rather than to have to remove the sign and create a new one
      > at the same location with a different sign type (index).

      I think we should, instead, make it easier to change the sign at the cursor
      and be able to change it back!

      My proposal would be that you could set a character in the margin of a
      particular line of a particular file using the :sign command eg:

      :sign * 40 test.txt
      :sign + 40 test.txt

      or

      :sign test.txt:40=*
      :sign test.txt:40=+


      Then you have 'highlight' mode that maps a particular character to a glyph
      of some kind. This does stop you from having multiple glyphs at a single
      point, but that could be solved by allowing a string of glyphs that get
      overlayed. ie

      :sign test.txt:40=+*
      or
      :sign test.txt:40+=+


      If we consider debug_point as some sort of internal glyph name, and
      $ICONLIB\current.ico as an externally defined glyph name (could be an xpm or
      whatever platform specific icon format we have) - here are a couple of
      ideas.


      Thought 1:

      :hi sign fg=red bg=white guifg=red guibg=white glyphmap=Debugger

      :glyph * debug_point
      :glyph + $ICONLIB\current.ico

      Thought 2:

      :hi sign fg=red bg=white guifg=red guibg=white
      glyph=+:debug_point,*:$ICONLIB\current.ico

      If we are using the multiple glyphs at one point, then we could also do:

      glyph +x $ICONLIB\current_and_debug.ico

      with some heuristics to set which was defined as the most visible mapping...
      eg. the last character in the string would be a good start.


      anyway.. just my thoughts .. I had attempted porting the sign code to
      win32 but found it too crazy for me to bother doing.

      //.ichael G.
    • Bram Moolenaar
      ... First of all, this was added to only support Sun Workshop by Gordon Prieur. I included this, with the intention to make it more generic. But I didn t have
      Message 2 of 4 , Jan 2, 2001
      • 0 Attachment
        Michael Geddes wrote:

        > Without meaning to offend anyone too much, I wanted to have a whinge about
        > the way the Sun Work* stuff was implemented... in particular, the way
        > 'signs' in the margin were done seemed particularly inelegant to me. (feel
        > free to read this as "sucks badly")
        >
        > I like the idea of having marks in the margin, and I would have thought
        > there was a way of doing this that allowed it used in a non-gui context as
        > well.

        First of all, this was added to only support Sun Workshop by Gordon Prieur.
        I included this, with the intention to make it more generic. But I didn't
        have time to work on it yet.

        For the non-GUI version the signs could be made with normal characters and a
        bit of highlighting. For example, the current position with a green ">" and a
        breakpoint with a red "#". A separate column is needed for this.

        > I also dispute the following paragraph from sign.txt
        >
        > > Creating and deleting signs are obvious functions. Why change sign type and
        > > jump to sign? Some debuggers have different signs for a breakpoint and the
        > > same breakpoint when the debugger is stopped at that breakpoint. Since the
        > > debugger may stop at a breakpoint often, it makes sense to allow the sign
        > > type to change rather than to have to remove the sign and create a new one
        > > at the same location with a different sign type (index).
        >
        > I think we should, instead, make it easier to change the sign at the cursor
        > and be able to change it back!

        Ehm, isn't that what was intented?

        > My proposal would be that you could set a character in the margin of a
        > particular line of a particular file using the :sign command eg:
        >
        > :sign * 40 test.txt
        > :sign + 40 test.txt
        >
        > or
        >
        > :sign test.txt:40=*
        > :sign test.txt:40=+

        Why use a character instead of a name? I would find a name like "stop" or
        "pc" much easier to understand. Then you can separately define which
        character and glyph to use for this sign.

        > Then you have 'highlight' mode that maps a particular character to a glyph
        > of some kind. This does stop you from having multiple glyphs at a single
        > point, but that could be solved by allowing a string of glyphs that get
        > overlayed. ie
        >
        > :sign test.txt:40=+*
        > or
        > :sign test.txt:40+=+

        Because of the way debuggers define and remove breakpoints, I think each
        sign needs to be defined and removed separately. Vim should handle multiple
        signs at the same line internally. Show more than one sign if possible (e.g.,
        a breakpoint with the pc), otherwise use some priority mechanism.

        I don't like the way how a sign is currently defined by a highlight group.
        I'll probably separate this. That would allow you to define the sign and its
        color separately. And possibly a different color for highlighting the whole
        line.

        > If we consider debug_point as some sort of internal glyph name, and
        > $ICONLIB\current.ico as an externally defined glyph name (could be an xpm or
        > whatever platform specific icon format we have) - here are a couple of
        > ideas.
        >
        >
        > Thought 1:
        >
        > :hi sign fg=red bg=white guifg=red guibg=white glyphmap=Debugger
        >
        > :glyph * debug_point
        > :glyph + $ICONLIB\current.ico
        >
        > Thought 2:
        >
        > :hi sign fg=red bg=white guifg=red guibg=white
        > glyph=+:debug_point,*:$ICONLIB\current.ico
        >
        > If we are using the multiple glyphs at one point, then we could also do:
        >
        > glyph +x $ICONLIB\current_and_debug.ico
        >
        > with some heuristics to set which was defined as the most visible mapping...
        > eg. the last character in the string would be a good start.

        I would like to separate three things:
        - Define the name of a sign and what it looks like. E.g.:
        :sign breakpoint icon=Stop.xpm char=# highlight=Breakpoint
        - Define colors (in the normal way):
        :highlight Breakpoint ctermfg=red
        - Define the line where a sign is displayed and set its type:
        :signadd 3 breakpoint 44 main.c
        :signset 3 pc
        :signdel 3
        This would be used by a debugger, it gives each sign a unique number.

        > anyway.. just my thoughts .. I had attempted porting the sign code to
        > win32 but found it too crazy for me to bother doing.

        It's currently tangled in with the Motif code. This needs to be changed...

        By the way, I was discussing with Gordon about using either "sign" or "glyph".
        I find "sign" a bit easier to type and understand. It's like using a road
        sign. But Gordon says that "glyph" is what most people use. What do you
        think?

        --
        hundred-and-one symptoms of being an internet addict:
        169. You hire a housekeeper for your home page.

        /// Bram Moolenaar -- Bram@... -- http://www.moolenaar.net \\\
        ((( Creator of Vim - http://www.vim.org -- ftp://ftp.vim.org/pub/vim )))
        \\\ Help me helping AIDS orphans in Uganda - http://iccf-holland.org ///
      • Michael Geddes
        Hmm.. some more thoughts .. not quite right, but some ideas anyway Courtesy of the WordSmith: Glyph Glyph , n. (Arch[ae]ol.) A carved figure or character,
        Message 3 of 4 , Jan 3, 2001
        • 0 Attachment
          Hmm.. some more thoughts .. not quite right, but some ideas anyway
          Courtesy of the WordSmith:
          Glyph \Glyph\, n. (Arch[ae]ol.)
          A carved figure or character, incised or in relief; a carved pictograph;
          hence, a pictograph representing a form originally adopted for sculpture,
          whether carved or painted.

          I think in computing terms, glyph refers to the actual icon itself - what
          it looks like .. physical attributes of it. Hence in defining a symbol to
          represent a concept, I think glyph fits quite well.

          :glyph breakpoint icon=Stop.xpm char=# highlight=Breakpoint

          However, I think that you then use a glyph at a 'mark' or as a 'sign'.
          Maybe we could combine the concept of glyphs and 'marks'.

          There are also two ways I can see of this being used. One is by debuggers
          where you may want to reference a mark by number and the other is for
          generally being able to place and view marks.

          :20 mark #break " mark line 20 with custom mark 'break'
          :call mark("a",20,"file.cpp") " Place mark a ('a) at
          file.cpp line 20
          :call mark('#mark', 20, "file.cpp") " Place custom mark 'break' at file.cpp
          line 20
          :call mark("#break:123",20, "file.cpp") " Place custom mark 'break' with an
          id of '123' at file.cpp line 20
          :unmark #break:123 "remove break

          :echo mark('#break:?',20,"file.cpp") " place custom mark 'break' with a
          new id and return the id.

          echo line('#mark') " return the line number of 'break'
          echo col('#mark') " ?? return the column of 'break' "

          :delmark

          I'm not sure then how to link a glyph with a mark.. but maybe

          hi mark #break:120 glyph=breakpoint guifg=red guibg=white

          Er.. this is not quite right.. but it's something to work with anyway.

          One reason for doing it this way is that you can do:

          :/string/mark #myline

          without mucking up any of the normal marks.

          As well as the equivalent of :

          hi mark a glyph=marka

          Giving us visible glyphs for normal marks at the same time (bonus no?)

          Hmm.. incomplete but some thoughts anyway.


          //.


          -----Original Message-----
          From: Bram Moolenaar [SMTP:Bram@...]
          Sent: Tuesday, 2 January 2001 21:28
          To: Michael Geddes
          Cc: 'Vim Dev'
          Subject: Re: IDE and 'signs'


          Michael Geddes wrote:

          > Without meaning to offend anyone too much, I wanted to have a
          whinge about
          > the way the Sun Work* stuff was implemented... in particular, the
          way
          > 'signs' in the margin were done seemed particularly inelegant to
          me. (feel
          > free to read this as "sucks badly")
          >
          > I like the idea of having marks in the margin, and I would have
          thought
          > there was a way of doing this that allowed it used in a non-gui
          context as
          > well.

          First of all, this was added to only support Sun Workshop by Gordon
          Prieur.
          I included this, with the intention to make it more generic. But I
          didn't
          have time to work on it yet.

          For the non-GUI version the signs could be made with normal
          characters and a
          bit of highlighting. For example, the current position with a green
          ">" and a
          breakpoint with a red "#". A separate column is needed for this.

          > I also dispute the following paragraph from sign.txt
          >
          > > Creating and deleting signs are obvious functions. Why change
          sign type and
          > > jump to sign? Some debuggers have different signs for a
          breakpoint and the
          > > same breakpoint when the debugger is stopped at that breakpoint.
          Since the
          > > debugger may stop at a breakpoint often, it makes sense to allow
          the sign
          > > type to change rather than to have to remove the sign and create
          a new one
          > > at the same location with a different sign type (index).
          >
          > I think we should, instead, make it easier to change the sign at
          the cursor
          > and be able to change it back!

          Ehm, isn't that what was intented?

          Not quite, I think they are changing the glyph for a particular mark, rather
          than changing which marks are on a particular line. I need to think about
          it a bit more to be able to say exactly what it wrong.

          > My proposal would be that you could set a character in the margin
          of a
          > particular line of a particular file using the :sign command eg:
          >
          > :sign * 40 test.txt
          > :sign + 40 test.txt
          >
          > or
          >
          > :sign test.txt:40=*
          > :sign test.txt:40=+

          Why use a character instead of a name? I would find a name like
          "stop" or
          "pc" much easier to understand. Then you can separately define
          which
          character and glyph to use for this sign.

          > Then you have 'highlight' mode that maps a particular character to
          a glyph
          > of some kind. This does stop you from having multiple glyphs at
          a single
          > point, but that could be solved by allowing a string of glyphs
          that get
          > overlayed. ie
          >
          > :sign test.txt:40=+*
          > or
          > :sign test.txt:40+=+

          Because of the way debuggers define and remove breakpoints, I think
          each
          sign needs to be defined and removed separately. Vim should handle
          multiple
          signs at the same line internally. Show more than one sign if
          possible (e.g.,
          a breakpoint with the pc), otherwise use some priority mechanism.

          I don't like the way how a sign is currently defined by a highlight
          group.
          I'll probably separate this. That would allow you to define the
          sign and its
          color separately. And possibly a different color for highlighting
          the whole
          line.

          > If we consider debug_point as some sort of internal glyph name,
          and
          > $ICONLIB\current.ico as an externally defined glyph name (could be
          an xpm or
          > whatever platform specific icon format we have) - here are a
          couple of
          > ideas.
          >
          >
          > Thought 1:
          >
          > :hi sign fg=red bg=white guifg=red guibg=white glyphmap=Debugger
          >
          > :glyph * debug_point
          > :glyph + $ICONLIB\current.ico
          >
          > Thought 2:
          >
          > :hi sign fg=red bg=white guifg=red guibg=white
          > glyph=+:debug_point,*:$ICONLIB\current.ico
          >
          > If we are using the multiple glyphs at one point, then we could
          also do:
          >
          > glyph +x $ICONLIB\current_and_debug.ico
          >
          > with some heuristics to set which was defined as the most visible
          mapping...
          > eg. the last character in the string would be a good start.

          I would like to separate three things:
          - Define the name of a sign and what it looks like. E.g.:
          :sign breakpoint icon=Stop.xpm char=# highlight=Breakpoint
          - Define colors (in the normal way):
          :highlight Breakpoint ctermfg=red
          - Define the line where a sign is displayed and set its type:
          :signadd 3 breakpoint 44 main.c
          :signset 3 pc
          :signdel 3
          This would be used by a debugger, it gives each sign a unique
          number.

          > anyway.. just my thoughts .. I had attempted porting the sign
          code to
          > win32 but found it too crazy for me to bother doing.

          It's currently tangled in with the Motif code. This needs to be
          changed...

          By the way, I was discussing with Gordon about using either "sign"
          or "glyph".
          I find "sign" a bit easier to type and understand. It's like using a
          road
          sign. But Gordon says that "glyph" is what most people use. What
          do you
          think?

          --
          hundred-and-one symptoms of being an internet addict:
          169. You hire a housekeeper for your home page.

          /// Bram Moolenaar -- Bram@... --
          http://www.moolenaar.net \\\
          ((( Creator of Vim - http://www.vim.org --
          ftp://ftp.vim.org/pub/vim )))
          \\\ Help me helping AIDS orphans in Uganda -
          http://iccf-holland.org ///
        • Bram Moolenaar
          ... I suppose that a toolbar icon could also be called a glyph, since it s a picture of something. There are two ways to approach this: - If you explain the
          Message 4 of 4 , Jan 4, 2001
          • 0 Attachment
            Michael Geddes wrote:

            > Hmm.. some more thoughts .. not quite right, but some ideas anyway
            > Courtesy of the WordSmith:
            > Glyph \Glyph\, n. (Arch[ae]ol.)
            > A carved figure or character, incised or in relief; a carved pictograph;
            > hence, a pictograph representing a form originally adopted for sculpture,
            > whether carved or painted.
            >
            > I think in computing terms, glyph refers to the actual icon itself - what
            > it looks like .. physical attributes of it. Hence in defining a symbol to
            > represent a concept, I think glyph fits quite well.

            I suppose that a toolbar icon could also be called a glyph, since it's a
            picture of something.

            There are two ways to approach this:
            - If you explain the concept of a breakpoint and PC as used by a debugger,
            displayed in Vim, what name do you associate with that?
            - If you look at the words "glyph" and "sign", what do you associate them
            with?

            We could invest thousands of dollars in a market study for this :-).

            > :glyph breakpoint icon=Stop.xpm char=# highlight=Breakpoint
            >
            > However, I think that you then use a glyph at a 'mark' or as a 'sign'.
            > Maybe we could combine the concept of glyphs and 'marks'.

            It sounds like you think of a glyph as the thing you see, while a mark or sign
            is the concept of positioning an item at a point in the text.

            > There are also two ways I can see of this being used. One is by debuggers
            > where you may want to reference a mark by number and the other is for
            > generally being able to place and view marks.

            I don't like the line of thought to find ways to come up for use of a new
            feature. I prefer to think about things we need in Vim and comes close to
            what signs offer.

            I don't think people will set signs by manually typing commands. They will
            use a debugger or some Vim script for that. The syntax of the commands should
            be designed to be easily used by a debugger.

            I don't see why we would need "custom marks". We already have the 'a - 'z
            marks, you can use them as you like.

            > I'm not sure then how to link a glyph with a mark.. but maybe

            Showing a glyph for a mark would be useful. That has been in the todo list
            for quite a long time. So, we would have:

            marks, shown with glyphs
            signs, shown with glyphs
            glyphs, displayed with an icon (GUI), highlighted line or highlighted
            character

            > hi mark #break:120 glyph=breakpoint guifg=red guibg=white
            >
            > Er.. this is not quite right.. but it's something to work with anyway.
            >
            > One reason for doing it this way is that you can do:
            >
            > :/string/mark #myline
            >
            > without mucking up any of the normal marks.

            Why not associate a glyph with a normal mark, and forget about the custom
            marks? Something like:

            :markglyph a Aglyph
            :markglyph ' PCglyph

            [quote included at random! :-)]

            --
            hundred-and-one symptoms of being an internet addict:
            225. You sign up for free subscriptions for all the computer magazines

            /// Bram Moolenaar -- Bram@... -- http://www.moolenaar.net \\\
            ((( Creator of Vim - http://www.vim.org -- ftp://ftp.vim.org/pub/vim )))
            \\\ Help me helping AIDS orphans in Uganda - http://iccf-holland.org ///
          Your message has been successfully submitted and would be delivered to recipients shortly.