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

Need an autocmd event when setting marks

Expand Messages
  • Christl Timon
    I want to visualize marks by setting signs. For example, when I set the mark a in the second line of a text it should look like this (I have also linenumbers
    Message 1 of 12 , Mar 5, 2003
      I want to visualize marks by setting signs. For example, when I set the
      mark 'a' in the second line of a text it should look like this (I have
      also linenumbers enabled):

      1 First
      a# 2 Second
      3 Third

      Similar for the remaining lowercase marks b-z and for the upper-case
      marks A-Z. I don't care about any other marks.

      I would like to re-bind/re-define

      m{a-zA-Z}
      :[range]ma[rk] {a-zA-Z}
      :[range]k{a-zA-Z}

      so that my own functions are called which first issue the appropriate
      :sign commands then do whatever the original bindings/functions did. I
      experimented a bit and came up with something that should IMHO work, but
      does not. It looks like this:

      function NewM(x)
      let foo=a:x
      normal 'm'.foo
      endfunction

      nnoremap ma call NewM('a')
      nnoremap mb call NewM('b')
      nnoremap mc call NewM('c')
      nnoremap md call NewM('d')
      " e-z, A-Z omitted

      What is wrong with that code? Why can't I write "normal 'm'.a:x" (it
      says something about trailing characters if I do), and is there a more
      elegant way to map 2*26 similar commands like these? Actually re-mapping
      this sole command would be sufficient as I don't use :mark or :k at all.

      Of course, a more clean solution would be to provide an autocmd event
      for this, but that would require code changes and I don't want to delay
      6.2 even more.

      Another problem I was facing is a lack of detailed documentation for the
      :sign command. What is the search path for icons (the icon= parameter
      of :sign define), and precisely which image formats can be used (and on
      which platforms)? :sign list always looks like this

      sign SignMarkA icon=no.xpm (not supported) text=MA texthl=LineNr

      on my linux box, gvim 6.1, compiled with big features and patched up to
      365.

      --
      Timon Christl <me@...>
      AIM: sgmfragcollector
      ICQ: 172280602
    • Hari Krishna Dara
      Not to steel your enthusiasm away, but there is already a script for exactly what you are trying to do, just checkout:
      Message 2 of 12 , Mar 5, 2003
        Not to steel your enthusiasm away, but there is already a script for
        exactly what you are trying to do, just checkout:

        http://www.vim.org/scripts/script.php?script_id=152

        HTH,
        Hari

        On Wed, 5 Mar 2003 at 7:35pm, Christl Timon wrote:

        > I want to visualize marks by setting signs. For example, when I set the
        > mark 'a' in the second line of a text it should look like this (I have
        > also linenumbers enabled):
        >
        > 1 First
        > a# 2 Second
        > 3 Third
        >
        > Similar for the remaining lowercase marks b-z and for the upper-case
        > marks A-Z. I don't care about any other marks.
        >
        > I would like to re-bind/re-define
        >
        > m{a-zA-Z}
        > :[range]ma[rk] {a-zA-Z}
        > :[range]k{a-zA-Z}
        >
        > so that my own functions are called which first issue the appropriate
        > :sign commands then do whatever the original bindings/functions did. I
        > experimented a bit and came up with something that should IMHO work, but
        > does not. It looks like this:
        >
        > function NewM(x)
        > let foo=a:x
        > normal 'm'.foo
        > endfunction
        >
        > nnoremap ma call NewM('a')
        > nnoremap mb call NewM('b')
        > nnoremap mc call NewM('c')
        > nnoremap md call NewM('d')
        > " e-z, A-Z omitted
        >
        > What is wrong with that code? Why can't I write "normal 'm'.a:x" (it
        > says something about trailing characters if I do), and is there a more
        > elegant way to map 2*26 similar commands like these? Actually re-mapping
        > this sole command would be sufficient as I don't use :mark or :k at all.
        >
        > Of course, a more clean solution would be to provide an autocmd event
        > for this, but that would require code changes and I don't want to delay
        > 6.2 even more.
        >
        > Another problem I was facing is a lack of detailed documentation for the
        > :sign command. What is the search path for icons (the icon= parameter
        > of :sign define), and precisely which image formats can be used (and on
        > which platforms)? :sign list always looks like this
        >
        > sign SignMarkA icon=no.xpm (not supported) text=MA texthl=LineNr
        >
        > on my linux box, gvim 6.1, compiled with big features and patched up to
        > 365.
        >
        >
      • Daniel Elstner
        ... The sign icon feature is currently not supported in the GTK+ GUI. Funny should you ask since I implemented it just about 2 days ago in GTK+ 2 Vim.
        Message 3 of 12 , Mar 5, 2003
          On Mit, 2003-03-05 at 19:35, Christl Timon wrote:

          > Another problem I was facing is a lack of detailed documentation for the
          > :sign command. What is the search path for icons (the icon= parameter
          > of :sign define), and precisely which image formats can be used (and on
          > which platforms)? :sign list always looks like this
          >
          > sign SignMarkA icon=no.xpm (not supported) text=MA texthl=LineNr

          The sign icon feature is currently not supported in the GTK+ GUI. Funny
          should you ask since I implemented it just about 2 days ago in GTK+ 2
          Vim. (Automatically including support for all image types you have
          pixbuf loader modules installed for, i.e. with the default set all
          popular ones except .gif of course.)

          For platform consistency I have to implement this for GTK+ 1 as well.
          The patch will probably available in a couple of days. Until then, get
          the latest GTK+ 2 patch (IIRC you are one of those who already tried
          it.)

          --Daniel
        • Daniel Elstner
          ... Oh, and the latest patch can always be found here: http://regexxer.sourceforge.net/vim/ --Daniel
          Message 4 of 12 , Mar 5, 2003
            On Mit, 2003-03-05 at 20:17, Daniel Elstner wrote:

            > For platform consistency I have to implement this for GTK+ 1 as well.
            > The patch will probably available in a couple of days. Until then, get
            > the latest GTK+ 2 patch (IIRC you are one of those who already tried
            > it.)

            Oh, and the latest patch can always be found here:

            http://regexxer.sourceforge.net/vim/

            --Daniel
          • Christl Timon
            ... That s exactly the reason why I rebuilt vim with +signs and why I had this idea. Without your post a few days ago I would not even know that vim had
            Message 5 of 12 , Mar 6, 2003
              On Wed, Mar 05, 2003 at 08:17:04PM +0100, Daniel Elstner told me:
              > The sign icon feature is currently not supported in the GTK+ GUI. Funny
              > should you ask since I implemented it just about 2 days ago in GTK+ 2
              > Vim. (Automatically including support for all image types you have
              > pixbuf loader modules installed for, i.e. with the default set all
              > popular ones except .gif of course.)

              That's exactly the reason why I rebuilt vim with +signs and why I had
              this idea. Without your post a few days ago I would not even know that
              vim had signs.

              Back to business, what about the search path? I assume those pixbuf
              loader modules use the search paths set in .gtkrc?

              > For platform consistency I have to implement this for GTK+ 1 as well.
              > The patch will probably available in a couple of days. Until then, get
              > the latest GTK+ 2 patch (IIRC you are one of those who already tried
              > it.)

              Yes I did, but had problems with a broken font config. I had a
              '"monospaced" is not a fixed-width font' problem if you remember.
              The problem is that figuring out which font is actually chosen is
              not very transparent to the user. Apart from using a debugger there is
              little you can do. Or am I missing something?

              --
              Timon Christl <me@...>
              AIM: sgmfragcollector
              ICQ: 172280602
            • Daniel Elstner
              ... Ahh ;-) ... No, that s an entirely different thing. Hmm, the help doesn t mention any search path... I had a look at the code (the generic non-GUI part)
              Message 6 of 12 , Mar 6, 2003
                On Don, 2003-03-06 at 17:57, Christl Timon wrote:

                > That's exactly the reason why I rebuilt vim with +signs and why I had
                > this idea. Without your post a few days ago I would not even know that
                > vim had signs.

                Ahh ;-)

                > Back to business, what about the search path? I assume those pixbuf
                > loader modules use the search paths set in .gtkrc?

                No, that's an entirely different thing. Hmm, the help doesn't mention
                any search path... I had a look at the code (the generic non-GUI part)
                and it seems you _have_ to specify the full path name.

                > > For platform consistency I have to implement this for GTK+ 1 as well.
                > > The patch will probably available in a couple of days. Until then, get
                > > the latest GTK+ 2 patch (IIRC you are one of those who already tried
                > > it.)
                >
                > Yes I did, but had problems with a broken font config. I had a
                > '"monospaced" is not a fixed-width font' problem if you remember.
                > The problem is that figuring out which font is actually chosen is
                > not very transparent to the user. Apart from using a debugger there is
                > little you can do. Or am I missing something?

                Oh I thought you got that solved. A debugger won't help much ;-)
                It's all in /etc/fonts/fonts.conf (provided you use Xft2). However, I
                disabled the fixed width check in the latest patches since there is the
                possibility of false positives, and variable width fonts actually do
                work. So just give it a try again -- you should be able to use the GUI
                font selector now ;-)

                Cheers,
                --Daniel
              • Mikolaj Machowski
                ... BTW Is it possible to make variable width fonts drawing in the center of the cell ? This is very low priority thing but displayed text in variable width
                Message 7 of 12 , Mar 7, 2003
                  On Thu, Mar 06, 2003 at 06:11:57PM +0100, Daniel Elstner wrote:
                  > disabled the fixed width check in the latest patches since there is the
                  > possibility of false positives, and variable width fonts actually do
                  > work.

                  BTW Is it possible to make variable width fonts drawing in the center of
                  "the cell"? This is very low priority thing but displayed text in
                  variable width would look better.

                  m.
                  --
                  LaTeX + Vim = http://vim-latex.sourceforge.net/
                  Learn Touch Typing with Vim:
                  http://vim.sourceforge.net/script.php?script_id=461
                  vim.pl - http://skawina.eu.org/mikolaj
                • Daniel Elstner
                  ... Yes, good point. I had postponed this for a while because centering the glyph without breaking composing characters didn t seem trivial. However, I think
                  Message 8 of 12 , Mar 7, 2003
                    On Fre, 2003-03-07 at 19:50, Mikolaj Machowski wrote:
                    > On Thu, Mar 06, 2003 at 06:11:57PM +0100, Daniel Elstner wrote:
                    > > disabled the fixed width check in the latest patches since there is the
                    > > possibility of false positives, and variable width fonts actually do
                    > > work.
                    >
                    > BTW Is it possible to make variable width fonts drawing in the center of
                    > "the cell"? This is very low priority thing but displayed text in
                    > variable width would look better.

                    Yes, good point. I had postponed this for a while because centering
                    the glyph without breaking composing characters didn't seem trivial.
                    However, I think I got it working now. Here's yet another patch to
                    try out:

                    http://regexxer.sourceforge.net/vim/vim-gtk2-20030308.patch.gz

                    Have fun,
                    --Daniel
                  • vim@cox.net
                    I m using VIM6.1.320 on WinXP Pro. I have a number of files scattered in a directory tree in which I would like to do some batch search/replace. So on the
                    Message 9 of 12 , Mar 7, 2003
                      I'm using VIM6.1.320 on WinXP Pro.

                      I have a number of files scattered in a directory tree in which I would like to do some batch search/replace. So on the command
                      prompt, I first do

                      gvim --servername BATCH

                      to open a vim which has title "BATCH", then under the root of the directory tree, I do

                      FOR /R . %I IN (foo*.bar) DO gvim --servername BATCH --remote %I

                      (for those not familiar with windows shell script, "FOR /R . %I IN (foo*.bar) DO ..." basically traverses the directory tree and
                      sets the path of each matching file into %I and execute whatever after DO)

                      Here comes the problem, some of the matching files are opened in the gvim with title "BATCH", while some others are not.

                      If I try something like the following

                      FOR /R . %I IN (foo*.bar) DO gvim --servername BATCH --remote %I & sleep 3

                      Here "& sleep 3" basically makes the shell waiting for 3 seconds after executing the gvim command, for each file. With this change,
                      all the matching files are opened in gvim as I expected, of course, at a very slow pace due to the 3 seconds delay between every two
                      files.

                      I wonder whether anybody else noticed similar behavior, either on Windows or Unix?

                      -J.X.
                    • Bram Moolenaar
                      ... Isn t the problem that this is going too fast, thus the file is replaced with another before you even notice it? Perhaps you can use --remote-wait, so
                      Message 10 of 12 , Mar 8, 2003
                        > I'm using VIM6.1.320 on WinXP Pro.
                        >
                        > I have a number of files scattered in a directory tree in which I would =
                        > like to do some batch search/replace. So on the command
                        > prompt, I first do
                        >
                        > gvim --servername BATCH
                        >
                        > to open a vim which has title "BATCH", then under the root of the =
                        > directory tree, I do
                        >
                        > FOR /R . %I IN (foo*.bar) DO gvim --servername BATCH --remote %I
                        >
                        > (for those not familiar with windows shell script, "FOR /R . %I IN =
                        > (foo*.bar) DO ..." basically traverses the directory tree and
                        > sets the path of each matching file into %I and execute whatever after =
                        > DO)
                        >
                        > Here comes the problem, some of the matching files are opened in the =
                        > gvim with title "BATCH", while some others are not.

                        Isn't the problem that this is going too fast, thus the file is
                        replaced with another before you even notice it? Perhaps you can use
                        --remote-wait, so that the search for files continues only after the
                        file was edited.

                        --
                        The budget process was invented by an alien race of sadistic beings who
                        resemble large cats.
                        (Scott Adams - The Dilbert principle)

                        /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
                        /// Creator of Vim - Vi IMproved -- http://www.Vim.org \\\
                        \\\ Project leader for A-A-P -- http://www.A-A-P.org ///
                        \\\ Help AIDS victims, buy at Amazon -- http://ICCF.nl/click1.html ///
                      • Jing Xue
                        ... Well, indeed the problem is that it s going too fast, but the part I don t understand is how some of the files could be _replaced_ by others. For example,
                        Message 11 of 12 , Mar 10, 2003
                          > -----Original Message-----
                          > From: Bram@... [mailto:Bram@...]
                          > Sent: Saturday, March 08, 2003 10:43 AM
                          > To: vim@...
                          > Cc: vim@...
                          > Subject: Re: Problem opening multiple file through Command window
                          >
                          > Isn't the problem that this is going too fast, thus the file is
                          > replaced with another before you even notice it? Perhaps you can use
                          > --remote-wait, so that the search for files continues only after the
                          > file was edited.

                          Well, indeed the problem is that it's going too fast, but the part I don't understand is how some of the files could be _replaced_ by others. For example, I know I have, say, 36 files that match foo*.bar in the directory tree, but after the script only about 25 are actually opened in Vim which I can tell by using :ls. And which ones end up opened out of the whole matching set seem to be quite random...

                          As for --remote-wait, it wouldn't exactly help in this case because I intend to open all the files in Vim, and use :bufdo to do some search/replace.

                          Thanks.
                          -Jing Xue
                        • Bram Moolenaar
                          ... Hmm, don t know what happens when Vim is overrun with --remote calls. Perhaps some messages are lost. You were using MS-Windows? This sends Windows
                          Message 12 of 12 , Mar 10, 2003
                            Jing Xue wrote:

                            > > Isn't the problem that this is going too fast, thus the file is
                            > > replaced with another before you even notice it? Perhaps you can use
                            > > --remote-wait, so that the search for files continues only after the
                            > > file was edited.
                            >
                            > Well, indeed the problem is that it's going too fast, but the part I
                            > don't understand is how some of the files could be _replaced_ by
                            > others. For example, I know I have, say, 36 files that match foo*.bar
                            > in the directory tree, but after the script only about 25 are actually
                            > opened in Vim which I can tell by using :ls. And which ones end up
                            > opened out of the whole matching set seem to be quite random...
                            >
                            > As for --remote-wait, it wouldn't exactly help in this case because I
                            > intend to open all the files in Vim, and use :bufdo to do some
                            > search/replace.

                            Hmm, don't know what happens when Vim is "overrun" with --remote calls.
                            Perhaps some messages are lost. You were using MS-Windows? This sends
                            Windows messages to the Vim server, perhaps it is possible for these
                            messages to get lost when there are many. Perhaps some error checking
                            is missing somewhere.

                            You are probably better off using --remote-send with an ":argadd"
                            command. This doesn't load the file, thus it's faster and perhaps this
                            avoids messages getting lost. Then you can use an ":argdo" command to
                            operate on all the files.

                            --
                            hundred-and-one symptoms of being an internet addict:
                            25. You believe nothing looks sexier than a man in boxer shorts illuminated
                            only by a 17" inch svga monitor.

                            /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
                            /// Creator of Vim - Vi IMproved -- http://www.Vim.org \\\
                            \\\ Project leader for A-A-P -- http://www.A-A-P.org ///
                            \\\ Help AIDS victims, buy at Amazon -- http://ICCF.nl/click1.html ///
                          Your message has been successfully submitted and would be delivered to recipients shortly.