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

Re: setting path recursively, macro tutorial

Expand Messages
  • Edward Peschko
    ... ah.. & denotes variabes. to set them apart from environmental varbs(?) ... I think that s a bit simpler... I see the looking for pattern bit becoming
    Message 1 of 21 , Sep 12, 2004
    • 0 Attachment
      > > do appending to an existing value..
      >
      > For that you can use the string concatenation operator, '.', e.g.,
      >
      > let &path = system('system command') . ',' . &path


      ah.. '&' denotes variabes. to set them apart from environmental
      varbs(?)

      > You could either parse the line looking for a particular pattern or
      > patterns, or you could include cursor-movement commands in the macro
      > and do something like yank the previous word into one register, yank
      > the following word into another register, then build a command that
      > includes the values of those registers.

      true, or you could have a shortcut:

      :nmap gF <C-W>f<cfile> <cfile+1>G

      I think that's a bit simpler... I see the looking for pattern bit becoming
      harder and harder to maintain with lots of areas for error. Also, not
      generalizable.


      BTW ..

      the following doesn't seem to work, even when I type something as simple as:

      :nmap gF <cword>G

      Are the tags literal? ie: why aren't they replaced by the text behind the tag
      before passed to the macro?

      As it stands, I can't think of a way to even make this mapping happen - it
      replaces the literal string <cword> and expects G to understand its meaning.
      Which it doesn't.. The only way I can think to overcome this is to
      use substitute, etc. but I'm not even sure that will work.

      Ed
    • Dave Silvia
      Sorry to be so tardy. Anyway, IIUC, you want to be able to open the file under the cursor with the understanding that it is in some subdirectory of the
      Message 2 of 21 , Sep 13, 2004
      • 0 Attachment
        Sorry to be so tardy. Anyway, IIUC, you want to be able to open the file
        under the cursor with the understanding that it is in some subdirectory of
        the current file's directory. You have received some good advice/response.

        An alternative would be to use the vimgrep.vim plugin and define a mapping
        of the sort:

        map gvf :call EditVimfind(expand("%:p:h"),expand("<cfile>"),'-d','-M')<CR>

        Briefly, this expands the current file's path as the first argument, uses
        the filename under the cursor for the second, '-d' says to search
        subdirectories, and '-M' says to match case.

        There are other Vimgrep/Vimfind commands/functions that may also be of use
        to you in the endeavor you allude to. The plugin comes with documentation
        in .rtf, .html, .doc, .ans, and .txt formats, so you should be able to find
        something to browse to suit.

        HTH:

        MfG,
        Dave S.
        "Okay, that's an engineer's response, what's a user's response?"

        *** -----Original Message-----
        *** From: Edward Peschko [mailto:esp5@...]
        *** Sent: Sunday, September 12, 2004 6:09 PM
        *** To: vim-dev@...
        *** Subject: setting path recursively, macro tutorial
        ***
        ***
        *** I was wondering -
        ***
        *** I have a large project (series of projects, really) that I
        *** maintain, and I wanted
        *** to be able to edit the files succinctly through the 'gf' mechanism.
        ***
        *** Anyway, I was thinking that the easiest way to do this was
        *** through setting a path
        *** via:
        ***
        *** set path=%RECURSIVE_PATH%
        ***
        *** or some such, where recursive path would basically do a system
        *** find underneath
        *** the current directory and prepend the directory names it found
        *** to the path.
        *** Is it possible to do this? I noticed that:
        ***
        *** set path=`system command`
        ***
        *** doesn't work, so I'm not sure if you can actually script it this way...
        ***
        ***
        *** Also - is there a way to macro it so that - on a gf - the file
        *** splits the screen
        *** first, *then* opens the file? And perhaps a method to go to the
        *** particular
        *** line number of the file, rather than starting at the beginning?
        ***
        *** I'm thinking of something like:
        ***
        *** source.cpp:1000
        ***
        *** where you want to not only see source.cpp, but your item of
        *** interest is on line
        *** 1000. Hitting gf in that case should split the screen and goto
        *** line 1000...
        *** this seems much more useful than closing the trace file and
        *** going to line 1..
        ***
        *** Any hints - along with a pointer to a comprehensive tutorial of
        *** vim macro programming
        *** would be appreciated..
        ***
        *** Ed
      • Antony Scriven
        Hello I think this discussion probably belongs on the vim users list, vim@vim.org, not on vim-dev. Aside from being more on-topic there, there are probably
        Message 3 of 21 , Sep 13, 2004
        • 0 Attachment
          Hello

          I think this discussion probably belongs on the vim users'
          list, vim@..., not on vim-dev. Aside from being more
          on-topic there, there are probably many helpful people
          reading that list who aren't subscribed to the vim-dev list.
          I've cc'd the vim users list; you may prefer to reply there.

          Edward Peschko wrote:

          [About using gf to jump to file and line of file:line patterns.]

          > [...]
          >
          > > You could either parse the line looking for a particular pattern or
          > > patterns, or you could include cursor-movement commands in the macro
          > > and do something like yank the previous word into one register, yank
          > > the following word into another register, then build a command that
          > > includes the values of those registers.
          >
          > true, or you could have a shortcut:
          >
          > :nmap gF <C-W>f<cfile> <cfile+1>G
          >
          > I think that's a bit simpler... I see the looking for pattern bit
          > becoming
          > harder and harder to maintain with lots of areas for error. Also, not
          > generalizable.

          Maybe something along these lines would be more suitable.

          fun! GotoFileAndLineNumber()
          let bufnr = bufnr('%')
          let saved_isf = &l:isf
          let saved_inex = &l:inex
          setl isf+=:
          " Warning: if you happen to have a filename {file}:{line}
          " then this will get loaded. In practice this is unlikely.
          let &l:inex = 'substitute(v:fname, ":\\d\\+$", "", "")'
          let linenr = matchstr(expand('<cfile>'), '\d\+$')
          if bufname("%") != substitute(expand("<cfile>:t"), ':\d\+$', '', '')
          exe "norm! \<C-W>f"
          else
          " Don't split if you jump to a different line in the same file,
          " but save the ` mark instead.
          norm! m`
          endif
          " linenr == '' if no number found was found.
          exe linenr
          call setbufvar(bufnr, '&inex', saved_inex)
          call setbufvar(bufnr, '&isf', saved_isf)
          endfun
          nnoremap <silent> gF :call GotoFileAndLineNumber()<CR>

          That's perhaps not as neat as it could be, but give it a go
          and see how it works for you. It would be a nice addition if
          it didn't split a new window when the buffer being jumped to
          is already loaded in another window. 'switchbuf' doesn't
          seem to affect gf.

          There's probably a lot in there you'll want to look up in
          the help docs. Most importantly :help 'includeexpr' and
          :help 'isfname' explain how gf can be made to parse the
          {file}:{line} pattern correctly. Also :help local-option,
          :help expr-option and, for a general overview, :help
          usr_41.txt may be helpful.

          Alternatively check out the vim.org web site, the list
          archives. I'd guess this topic has appeared before.

          > BTW ..
          >
          > the following doesn't seem to work, even when I type something as simple
          > as:
          >
          > :nmap gF <cword>G
          >
          > Are the tags literal? ie: why aren't they replaced by the text behind the
          > tag
          > before passed to the macro?

          It is explained in the help, but not right at :help <cword>.
          You need to scroll up a bit to `Ex special characters':

          In Ex commands, at places where a file name can be used, the
          following characters have a special meaning. These can also
          be used in the expression function expand() |expand()|.

          So to display the word at the cursor you can type:

          :echo expand('<cword>')

          Antony
        • Dave Silvia
          Since he s looking to use file names under the cursor, it should probably be :echo expand( ) MfG, Dave S. Okay, that s an engineer s response,
          Message 4 of 21 , Sep 13, 2004
          • 0 Attachment
            Since he's looking to use file names under the cursor, it should probably be
            ":echo expand('<cfile>')"

            MfG,
            Dave S.
            "Okay, that's an engineer's response, what's a user's response?"

            *** -----Original Message-----
            *** From: Antony Scriven [mailto:adscriven@...]
            *** Sent: Monday, September 13, 2004 6:27 AM
            *** To: vim-dev@...
            *** Cc: vim@...
            *** Subject: Re: setting path recursively, macro tutorial
            ***
            ***
            *** Hello
            ***
            *** I think this discussion probably belongs on the vim users'
            *** list, vim@..., not on vim-dev. Aside from being more
            *** on-topic there, there are probably many helpful people
            *** reading that list who aren't subscribed to the vim-dev list.
            *** I've cc'd the vim users list; you may prefer to reply there.
            ***
            *** Edward Peschko wrote:
            ***
            *** [About using gf to jump to file and line of file:line patterns.]
            ***
            *** > [...]
            *** >
            *** > > You could either parse the line looking for a particular pattern or
            *** > > patterns, or you could include cursor-movement commands in
            *** the macro
            *** > > and do something like yank the previous word into one
            *** register, yank
            *** > > the following word into another register, then build a command that
            *** > > includes the values of those registers.
            *** >
            *** > true, or you could have a shortcut:
            *** >
            *** > :nmap gF <C-W>f<cfile> <cfile+1>G
            *** >
            *** > I think that's a bit simpler... I see the looking for pattern bit
            *** > becoming
            *** > harder and harder to maintain with lots of areas for error. Also, not
            *** > generalizable.
            ***
            *** Maybe something along these lines would be more suitable.
            ***
            *** fun! GotoFileAndLineNumber()
            *** let bufnr = bufnr('%')
            *** let saved_isf = &l:isf
            *** let saved_inex = &l:inex
            *** setl isf+=:
            *** " Warning: if you happen to have a filename {file}:{line}
            *** " then this will get loaded. In practice this is unlikely.
            *** let &l:inex = 'substitute(v:fname, ":\\d\\+$", "", "")'
            *** let linenr = matchstr(expand('<cfile>'), '\d\+$')
            *** if bufname("%") != substitute(expand("<cfile>:t"), ':\d\+$', '', '')
            *** exe "norm! \<C-W>f"
            *** else
            *** " Don't split if you jump to a different line in the same file,
            *** " but save the ` mark instead.
            *** norm! m`
            *** endif
            *** " linenr == '' if no number found was found.
            *** exe linenr
            *** call setbufvar(bufnr, '&inex', saved_inex)
            *** call setbufvar(bufnr, '&isf', saved_isf)
            *** endfun
            *** nnoremap <silent> gF :call GotoFileAndLineNumber()<CR>
            ***
            *** That's perhaps not as neat as it could be, but give it a go
            *** and see how it works for you. It would be a nice addition if
            *** it didn't split a new window when the buffer being jumped to
            *** is already loaded in another window. 'switchbuf' doesn't
            *** seem to affect gf.
            ***
            *** There's probably a lot in there you'll want to look up in
            *** the help docs. Most importantly :help 'includeexpr' and
            *** :help 'isfname' explain how gf can be made to parse the
            *** {file}:{line} pattern correctly. Also :help local-option,
            *** :help expr-option and, for a general overview, :help
            *** usr_41.txt may be helpful.
            ***
            *** Alternatively check out the vim.org web site, the list
            *** archives. I'd guess this topic has appeared before.
            ***
            *** > BTW ..
            *** >
            *** > the following doesn't seem to work, even when I type
            *** something as simple
            *** > as:
            *** >
            *** > :nmap gF <cword>G
            *** >
            *** > Are the tags literal? ie: why aren't they replaced by the
            *** text behind the
            *** > tag
            *** > before passed to the macro?
            ***
            *** It is explained in the help, but not right at :help <cword>.
            *** You need to scroll up a bit to `Ex special characters':
            ***
            *** In Ex commands, at places where a file name can be used, the
            *** following characters have a special meaning. These can also
            *** be used in the expression function expand() |expand()|.
            ***
            *** So to display the word at the cursor you can type:
            ***
            *** :echo expand('<cword>')
            ***
            *** Antony
          • Antoine J. Mechelynck
            ... Environment variables are set off by $, e.g., $HOME, $PATH, etc. See :help expr-env Options, when used like variables (in expressions and the :let
            Message 5 of 21 , Sep 13, 2004
            • 0 Attachment
              Edward Peschko <esp5@...> wrote:
              > > > do appending to an existing value..
              > >
              > > For that you can use the string concatenation operator, '.', e.g.,
              > >
              > > let &path = system('system command') . ',' . &path
              >
              >
              > ah.. '&' denotes variabes. to set them apart from environmental
              > varbs(?)

              Environment variables are set off by $, e.g., $HOME, $PATH, etc. See ":help
              expr-env"

              Options, when used like variables (in expressions and the ":let" statement)
              are set off by &, e.g., &path, &viminfo, &compatible, &readonly, etc. To
              distinguish the global and the local value of those which have both one can
              also use &g:filetype vs. &l:filetype, &g:fileformat vs. &l:fileformat, etc.
              See ":help expr-option".

              Registers, when used like variables, are set off by @, e.g., @a, @b, @c, @/,
              @*, etc. See ":help expr-register".

              Variables are just a name, e.g., var1, i, j, save_cpo, etc. They are defined
              by using them as the left-hand end of a ":let" statement and they are
              undefined (and their memory space reclaimed) by ":unlet". There are also
              script-local variables (s:name), global variables (g:name) and variables
              predefined by vim (v:name), buffer-local variables (b:name) and, at least in
              some versions of Vim, window-local variables (w:name), etc. See ":help
              internal-variables".

              [...]
              > BTW ..
              >
              > the following doesn't seem to work, even when I type something as
              > simple as:
              >
              > > nmap gF <cword>G
              >
              > Are the tags literal? ie: why aren't they replaced by the text behind
              > the tag before passed to the macro?

              nmap is for Normal mode. If you map the above, and the current word is
              "join", hitting gF will (IIUC):
              (a) go down one line (j)
              (b) open an empty line below the current line (o) and switch to Insert
              mode
              (c) insert inG

              For an nmap, you have to imagine you're using (g)vim in Normal mode. Then
              the {rhs} is used as if you had typed it, usually as Normal-mode commands.
              See ":help map-overview" -- and the rest of the same help file (map.txt).

              >
              > As it stands, I can't think of a way to even make this mapping happen
              > - it replaces the literal string <cword> and expects G to understand
              > its meaning. Which it doesn't.. The only way I can think to
              > overcome this is to
              > use substitute, etc. but I'm not even sure that will work.
              >
              > Ed

              To insert the characters <, c, w, o, r, d, > and go to the end of the file
              you might use

              :map gF i<lt>cword><Esc>G

              HTH,
              Tony.
            • Edward Peschko
              ... well, yes I agree with you that it has a large users component, but the below is also a feature request. Look at the function that you have typed in below,
              Message 6 of 21 , Sep 13, 2004
              • 0 Attachment
                On Mon, Sep 13, 2004 at 12:27:10PM +0100, Antony Scriven wrote:
                > Hello
                >
                > I think this discussion probably belongs on the vim users'
                > list, vim@..., not on vim-dev. Aside from being more
                > on-topic there, there are probably many helpful people
                > reading that list who aren't subscribed to the vim-dev list.
                > I've cc'd the vim users list; you may prefer to reply there.

                well, yes I agree with you that it has a large users component, but
                the below is also a feature request.

                Look at the function that you have typed in below, and compare it
                to

                :nmap gF <C-W>f <cfile+1>G

                which one is easier to do? Perhaps an 'auto expand' mechanism is in order, something
                like <:cfile:> or <:cfile+1:> for use with mapped keys. Having expand(..) doesn't work
                with regular commands (like G), and you need to go through the contortions below
                in order to get something done.

                Not that what you have done isn't cool, it just takes a lot more effort IMO than
                is necessary.

                Ed
              • Edward Peschko
                ... well, I work on both platforms, actually, so yes its a bit of a pain to switch between the two. IMO this argues for lots of integrated behaviour (into vim
                Message 7 of 21 , Sep 13, 2004
                • 0 Attachment
                  On Mon, Sep 13, 2004 at 02:22:05AM -0500, Dave Silvia wrote:
                  > Also, it appears from the content of your posting that you are on some type
                  > of DOS/Windows platform. Be advised that much of the advice you'll receive
                  > will be UNIX specific (a large portion of the community). Some things just
                  > won't work properly (thank you, Bill Gates!;). The mapping I gave in the
                  > previous mailing will work regardless of platform.
                  >

                  well, I work on both platforms, actually, so yes its a bit of a pain to switch
                  between the two. IMO this argues for lots of integrated behaviour (into vim itself)
                  to lessen the pain. For example, you can do:

                  vi `cat /tmp/filelist`

                  to view a list of files on unix, there is no good substitute on
                  dos, so - if there was a command line option:

                  vi -L /tmp/filelist

                  to do this, it would be extremely helpful.


                  Likewise, I can't imagine that this is all that uncommon (to want to be able
                  to view files under the current path, so if there was a variable set:

                  set path=&RECURSIVE_PATH,path

                  or more generally a way to have functions be interpolated by set that would be
                  really cool. Just from a relative newbie to vim programming's point of view,
                  having 'let' and 'set' and the interactions between them is confusing IMO.
                  And I'm really big into perl so I've had my share of special characters
                  denoting different things.. ;-)

                  Anyway, I'm going to download the grep utilities as suggested, but perhaps an
                  audit could be done on the scripts accumulating inside of there,
                  and some sort of vim API could be put together for the standard distribution?

                  Not sure if this hasn't already been done.. but it sure would save a lot
                  of effort on the part of users.

                  Ed
                • Edward Peschko
                  ... right, that s why I wanted . So I wouldn t need to do this. ... well, actually was to indicate that the text was to be substituted in
                  Message 8 of 21 , Sep 13, 2004
                  • 0 Attachment
                    > >:nmap gF <C-W>f <cfile+1>G

                    > Well, maybe a more effort than *should* be necessary, but what it does
                    > *is* necessary. The value returned by <cfile> only returns characters
                    > listed in the 'isfname' option, and : isn't there by default on
                    > Unix-like systems. Thus, his function saves the current value of
                    > isfname, temporarily adds : to it, then resets isfname to the original
                    > value before leaving. Now, the value returned by <cfile> will contain
                    > the filename:lineno pattern.

                    right, that's why I wanted <cfile+1>. So I wouldn't need to do this.

                    > After that, he saves the requested line number into the linenr variable.
                    > He has to parse the filename:lineno pattern to find it. Your
                    > <cfile+1> suggestion would simplify that one step, but how do you
                    > specify the delimiter to be used to find the +1 value? Is that what was
                    > being indicated by using <:cfile+1:>?

                    well, actually <:cfile+1:> was to indicate that the text was to be substituted
                    in the context before G, ie:

                    5
                    ^
                    <cword>

                    :nmap gF <:cword:>G

                    would - as an effect, make gF a synonym of 5G (in this case), rather than
                    <:cword:>G. Its not the best syntax, I admit, but I'm open to suggestions.

                    Perhaps the thing I'm thinking of is instead of 'Ex' special characters,
                    'Esc' special characters. Or, come to think of it, 'insert' special characters.
                    Characters that are interpolated for each given context.


                    > A problem with your example above doesn't actually get the file name to
                    > open. It creates a new split window then tries to jump to line
                    > <cfile+1> without actually loading a file in the new split window.
                    > Borrowing from Antony's script, your command above can be changed to

                    hmm.. maybe I got the syntax wrong, I thought that

                    <c-w>f

                    automatically took the the name of the file underneath the cursor and
                    split the buffer, and opened the file. Hence I thought that

                    :nmap gF <c-w>f <:cfile+1:>G

                    would open the file under the cursor in a separate window (<C-w>f) and
                    then go to the approriate line (because vim would substitute <:cfile+1:> for the
                    line number it found. I don't think I need to do anything with isfname, if
                    vim buffered a number of words above and behind the current one.

                    Admittedly splitting into multiple buffers is an issue, but that could be solved
                    by a buffer guard (one that closes all frames except the current one) Splitting
                    into the same file isn't that big a deal; that's what you've asked for, after all.

                    > :he :normal
                    > :he :isfname
                    > :he bufnr()
                    > :he bufwinnr()

                    Ok, so if I wanted to do what I was to do above I'd say:

                    :nmap gF :only<CR><c-w>f<:cfile+1:>G

                    ...assuming that <:cfile+1:> was an 'Esc' special character which got substituted
                    before the G command was hit.

                    Look, I appreciate the information about expand, functions, et al, but you really
                    shouldn't have to dive into pattern matching in order to get this command
                    done. IMO its too simple. I guess I could do

                    :nmap gF :only<CR><c-w>f<c-w><c-w>/:<CR>wyw<c-w><c-w>:<register><CR>

                    but then again, this assumes that 'register' command existed for Ex (which would
                    probably be useful) But this is getting a bit long in the tooth, too..

                    Ed

                    (
                    ps - the more that I look at normal, the more I'm not sure what its
                    trying to do.

                    If you say:

                    :exe "normal :only\<CR>:split\<CR>\<cfile>G"

                    the <cr>s get translated, but <cfile> doesn't. What's its use?

                    Also - <cfile>, <cword>, etc, don't work in ex mode, ie: if you say:

                    :<cword>

                    it doesn't translate for you.

                    Now, I admit that this might be a bit dangerous, but it would also be
                    powerful... caveat emptor..
                    )
                  • Dan Sharp
                    Okay, I think I finally understand the feature requests. You want a version of , , etc., that will work in place without expand(), and you want
                    Message 9 of 21 , Sep 13, 2004
                    • 0 Attachment
                      Okay, I think I finally understand the feature requests. You want a
                      version of <cfile>, <cword>, etc., that will work in place without
                      expand(), and you want to be able to specify +num or -num to mean "the
                      'num'th (filename|word|etc.) before or after the current one." I never
                      really could tell for what you asking in the previous posts in the
                      thread. Sorry.

                      Edward Peschko wrote:
                      >>>:nmap gF <C-W>f <cfile+1>G
                      >
                      > :nmap gF <:cword:>G
                      >
                      > would - as an effect, make gF a synonym of 5G (in this case), rather than
                      > <:cword:>G. Its not the best syntax, I admit, but I'm open to suggestions.

                      :exec "normal " . expand('<cword>') . 'G'

                      in place of

                      <:cword:>G

                      works, but is certainly much longer.

                      > hmm.. maybe I got the syntax wrong, I thought that
                      >
                      > <c-w>f
                      >
                      > automatically took the the name of the file underneath the cursor and
                      > split the buffer, and opened the file.

                      You are right. I apparently only read the first line of the help for
                      the command.

                      > Admittedly splitting into multiple buffers is an issue, but that could be solved
                      > by a buffer guard (one that closes all frames except the current one) Splitting
                      > into the same file isn't that big a deal; that's what you've asked for, after all.
                      >
                      >
                      > Ok, so if I wanted to do what I was to do above I'd say:
                      >
                      > :nmap gF :only<CR><c-w>f<:cfile+1:>G
                      >
                      > ...assuming that <:cfile+1:> was an 'Esc' special character which got substituted
                      > before the G command was hit.
                      >
                      > Look, I appreciate the information about expand, functions, et al, but you really
                      > shouldn't have to dive into pattern matching in order to get this command
                      > done. IMO its too simple. I guess I could do
                      >
                      > :nmap gF :only<CR><c-w>f<c-w><c-w>/:<CR>wyw<c-w><c-w>:<register><CR>
                      >
                      > but then again, this assumes that 'register' command existed for Ex (which would
                      > probably be useful) But this is getting a bit long in the tooth, too..

                      Replace <register> with @" and it should work. Changing <c-w><c-w> to
                      <c-w>p would make it a touch shorter and a help it work if you didn't
                      want to include the :only.

                      > ps - the more that I look at normal, the more I'm not sure what its
                      > trying to do.
                      >
                      > If you say:
                      >
                      > :exe "normal :only\<CR>:split\<CR>\<cfile>G"
                      >
                      > the <cr>s get translated, but <cfile> doesn't. What's its use?
                      >
                      > Also - <cfile>, <cword>, etc, don't work in ex mode, ie: if you say:
                      >
                      > :<cword>
                      >
                      > it doesn't translate for you.
                      >
                      > Now, I admit that this might be a bit dangerous, but it would also be
                      > powerful... caveat emptor..

                      <CR> represents a key that would be pressed, so it gets converted.
                      <cword>, etc., aren't keys. They are replaced with something else, thus
                      the need for expand(). Granted,

                      :e <cfile>

                      will work directly, without expand(). Also, you separate multiple
                      commands in a sequence with | not <CR>, so your example above would be

                      :only | split | exec "normal " . expand('<cfile>') . "G"

                      The :normal command just lets you issue normal-mode commands from
                      command mode. In your example, you only need :normal for the last part.
                      You need expand() to convert the <cfile> symbol into the string it
                      represents, and the exec command is necessary to let you execute the
                      concatenation of the strings. As a shorter example, if you always
                      wanted to move to line 5 in the split, you could do something like

                      :only | split | normal 5G


                      Dan Sharp
                    • Edward Peschko
                      ... not a problem. I tend to type out loud a bit, and things get muddled as a result. I wasn t even sure there were features to be requested, until halfway
                      Message 10 of 21 , Sep 13, 2004
                      • 0 Attachment
                        On Mon, Sep 13, 2004 at 09:12:36PM -0400, Dan Sharp wrote:
                        > Okay, I think I finally understand the feature requests. You want a
                        > version of <cfile>, <cword>, etc., that will work in place without
                        > expand(), and you want to be able to specify +num or -num to mean "the
                        > 'num'th (filename|word|etc.) before or after the current one." I never
                        > really could tell for what you asking in the previous posts in the
                        > thread. Sorry.

                        not a problem. I tend to type out loud a bit, and things get muddled as
                        a result. I wasn't even sure there were features to be requested, until
                        halfway through when I realized people were reaching for the functions
                        and parsers...

                        Thanks much,

                        Ed
                      • Keith Roberts
                        ... I still see unanswered questions here ... - to what does the +/-num refer? {word|WORD|word after some separator|word within vs. word before/after
                        Message 11 of 21 , Sep 14, 2004
                        • 0 Attachment
                          >-----Original Message-----
                          >From: Edward Peschko [mailto:esp5@...]
                          >Sent: Monday, September 13, 2004 7:01 PM
                          >To: Dan Sharp
                          >Cc: vim-dev@...
                          >Subject: Re: setting path recursively, macro tutorial
                          >
                          >On Mon, Sep 13, 2004 at 09:12:36PM -0400, Dan Sharp wrote:
                          >> Okay, I think I finally understand the feature requests. You want a
                          >> version of <cfile>, <cword>, etc., that will work in place without
                          >> expand(), and you want to be able to specify +num or -num to
                          >mean "the
                          >> 'num'th (filename|word|etc.) before or after the current one." I
                          >> never really could tell for what you asking in the previous posts in
                          >> the thread. Sorry.
                          >
                          >not a problem. I tend to type out loud a bit, and things get
                          >muddled as a result. I wasn't even sure there were features to
                          >be requested, until halfway through when I realized people
                          >were reaching for the functions and parsers...
                          >
                          >Thanks much,
                          >Ed

                          I still see unanswered questions here ...

                          - to what does the +/-num refer? {word|WORD|word after some
                          separator|word within <cfile> vs. word before/after <cfile>|...}

                          - how to specify separator if that's what's intended (in the example, he
                          used ':')

                          Don't forget, in the example the 'word' after <cfile> (in vim terms) is
                          actually the ':' itself, and the 'WORD' after <cfile> is not what
                          follows the ':', since that is not whitespace. Of course, he could use
                          +2 instead if 'word' was used ... but how do you specify that? Perhaps
                          <cfile+2w>? It would only make sense to extend that to include all
                          classes allowed in rexexes: w for \w, W for \W, k for \k, etc.

                          --
                          Keith
                        • Edward Peschko
                          ... well, what I was thinking was a bit simpler, that cfile+1 would indicate the cfile after the current cfile.. but what you suggest could generalize it:
                          Message 12 of 21 , Sep 14, 2004
                          • 0 Attachment
                            > I still see unanswered questions here ...
                            >
                            > - to what does the +/-num refer? {word|WORD|word after some
                            > separator|word within <cfile> vs. word before/after <cfile>|...}

                            well, what I was thinking was a bit simpler, that cfile+1> would indicate
                            the cfile after the current cfile.. but what you suggest could generalize it:

                            <cfile + cword + cfile>

                            > - how to specify separator if that's what's intended (in the example, he
                            > used ':')

                            I'd assume that isfnam would be used for cfile throughout..

                            > Don't forget, in the example the 'word' after <cfile> (in vim terms) is
                            > actually the ':' itself, and the 'WORD' after <cfile> is not what
                            > follows the ':', since that is not whitespace. Of course, he could use
                            > +2 instead if 'word' was used ... but how do you specify that? Perhaps
                            > <cfile+2w>? It would only make sense to extend that to include all
                            > classes allowed in rexexes: w for \w, W for \W, k for \k, etc.

                            well, you could if you want reproduce the entire regex engine inside <..> but
                            for my purposes it would be overkill.. I think it would be far more useful
                            for most people to have shortcuts, ie:

                            <cfile + 1>
                            <cword + 1>

                            and only if you need to get more serious, go into regular expression classes.
                            I don't know if it makes sense to go further than supporting regular expression
                            classes. If you do, you lose the shortcuts above - is 1 in <cfile + 1>
                            literal or to be translated?

                            I suppose if you did want to put regular expressions inside of <..> you could
                            have a special tag like perl does to indicate both them and current position:

                            < m"(\S*\G\S*)" >

                            where \G is the current position anchor... then my example would be:

                            < m"\S*\G\S*:(\d+)" >

                            which I could live with, although I'm not sure other people would. It would be
                            powerful though.

                            Ed

                            (ps - the other thing that I can think of that is outstanding is, when are
                            the expressions evaluated?

                            If I say:

                            :nmap gF :only<cr><c-w>f<:cfile + 1:>G

                            does <:cfile + 1:> refer to the buffer that I started the gF command in, or
                            the buffer which was switched to (via <c-w>f?)

                            I'd vote for the buffer I started in, since there's no way that I'm going to
                            know what text is in the other buffer - and if I'm counting on the other buffer
                            having a certain pattern, something is wrong with my design..
                            )


                            (
                            pps - how do you use | inside of :nmap? I noticed -

                            :nmap gF :only | :split

                            doesn't work, because | is the terminator for nmap...
                            )
                          • Keith Roberts
                            ... Call me crazy ... But either you ve completely missed the boat here ... Or I have! is defined as the pathname under the cursor. In the OP you were
                            Message 13 of 21 , Sep 14, 2004
                            • 0 Attachment
                              >-----Original Message-----
                              >From: Edward Peschko [mailto:esp5@...]
                              >Sent: Tuesday, September 14, 2004 11:08 AM
                              >To: Keith Roberts
                              >Cc: vim-dev@...
                              >Subject: Re: setting path recursively, macro tutorial
                              >
                              >> I still see unanswered questions here ...
                              >>
                              >> - to what does the +/-num refer? {word|WORD|word after some
                              >> separator|word within <cfile> vs. word before/after <cfile>|...}
                              >
                              >well, what I was thinking was a bit simpler, that cfile+1>
                              >would indicate the cfile after the current cfile.. but what
                              >you suggest could generalize it:
                              >
                              ><cfile + cword + cfile>

                              Call me crazy ... But either you've completely missed the boat here ...
                              Or I have!

                              <cfile> is defined as the pathname under the cursor. In the OP you were
                              using a degenerate <cfile> (ie, the filename without the path), and you
                              were sucking the line number into it by defining ':' as part of
                              'isfname'. So <cfile> in your case was filename.c:1000 or the like. In
                              the normal case you would only get filename.c (or dir/subdir/filename.c
                              or /usr/vim/vim63/src/filename.c or c:\MySrc\filename.c or the like).

                              I was talking about using the normal setting for 'isf' and having vim be
                              able to return entities before/after the one the cursor is on.

                              >> - how to specify separator if that's what's intended (in the
                              >example,
                              >> he used ':')
                              >
                              >I'd assume that isfnam would be used for cfile throughout..
                              >
                              >> Don't forget, in the example the 'word' after <cfile> (in vim terms)
                              >> is actually the ':' itself, and the 'WORD' after <cfile> is not what
                              >> follows the ':', since that is not whitespace. Of course, he could
                              >> use
                              >> +2 instead if 'word' was used ... but how do you specify that?
                              >> +Perhaps
                              >> <cfile+2w>? It would only make sense to extend that to include all
                              >> classes allowed in rexexes: w for \w, W for \W, k for \k, etc.
                              >
                              >well, you could if you want reproduce the entire regex engine
                              >inside <..> but for my purposes it would be overkill.. I think
                              >it would be far more useful for most people to have shortcuts, ie:

                              What I was talking about has nothing to do with replicating the regex
                              engine anywhere. There are a finite number of classes to consider, and
                              the optional constuct of [+-]\d\+[wWkK...] following the existing list
                              of known entities inside <>.

                              >(
                              > pps - how do you use | inside of :nmap? I noticed -
                              >
                              > :nmap gF :only | :split
                              >
                              > doesn't work, because | is the terminator for nmap...
                              >)

                              Escape the | twice: one is removed when the map is created, the other
                              when used.

                              :nmap gF :only \\| :split
                            • Edward Peschko
                              ... yes, that s what I was talking about too. I *wasn t* redefining : . and using to get the current file. would get the next pattern that
                              Message 14 of 21 , Sep 14, 2004
                              • 0 Attachment
                                > ><cfile + cword + cfile>
                                >
                                > Call me crazy ... But either you've completely missed the boat here ...
                                > Or I have!
                                >
                                > <cfile> is defined as the pathname under the cursor. In the OP you were
                                > using a degenerate <cfile> (ie, the filename without the path), and you
                                > were sucking the line number into it by defining ':' as part of
                                > 'isfname'. So <cfile> in your case was filename.c:1000 or the like. In
                                > the normal case you would only get filename.c (or dir/subdir/filename.c
                                > or /usr/vim/vim63/src/filename.c or c:\MySrc\filename.c or the like).
                                >
                                > I was talking about using the normal setting for 'isf' and having vim be
                                > able to return entities before/after the one the cursor is on.

                                yes, that's what I was talking about too. I *wasn't* redefining ':'.
                                and using <cfile> to get the current file. <cfile + 1> would get the next
                                pattern that matched <cfile>, ie: in my case '1000'.


                                > What I was talking about has nothing to do with replicating the regex
                                > engine anywhere. There are a finite number of classes to consider, and
                                > the optional constuct of [+-]\d\+[wWkK...] following the existing list
                                > of known entities inside <>.

                                fine, but I think that you should allow <cfile + 1> as a shortcut, literals, and
                                automatically skipping text on non-matches if you are going to do this.

                                Examples on

                                my/source/filename:1000:whatever/file

                                (assume cursor at beginning of text):

                                <cfile + 1> returns '1000'
                                <cfile + 2> returns 'whatever/file'
                                <cfile + word> returns '1000'
                                <cfile + 2file> returns 'whatever/file'

                                <cword + 1> returns 'source'
                                <cword + file> returns 'my/source/filename'
                                <cword + 2> returns 'filename'
                                <cword + 3> returns '1000'

                                <cword + ':' + word> returns '1000' (skips everything up to ':', returns next word)

                                <word + (\d+)> returns '1000'
                                <word + (\w+)> returns 'source'
                                <word + (\d)> returns '1'

                                <word + (2word)> returns 'source/filename'
                                <word + (2file)> returns '1000:whatever/file'
                                <word + 2file> returns 'whatever/file' (no parens, hence assume
                                last file is wanted

                                this is getting fairly close to a regular expression engine. A simpler one, but
                                still a regex engine.

                                Like I said, I don't have a problem with that, it makes things a lot more
                                powerful. But it is a bit more work to set up... And a full regex engine
                                need not be 'replicated', but extended and reused, although I don't know
                                how usable vim's builtin regular expression engine would be for this
                                purpose.

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