Re: [Ctags] Feature request - minor (?)

[Neil B. <nei...@rd...>]

Darren Hiebert wrote:
> This idea has been suggested more than once before, and I have
> seriously considered it, especially when I consider the possibility
> of allowing ctags to automatically regenerate an existing tag file.

  I'd not even considered that!


> However, it has two problems, one practical problem which you have
> forseen (below), and one philosophical problem:
> <snip>

  OK, now here's a thought. If we can assume that this is to be a special
option (as opposed to the default behaviour), then we can apply certain
restrictions to it; e.g., line length if final command < 256 or 512. That
would get around that side of things.

  A slightly more tricky solution would be to split the command line up
into several (using '-a') which leads me to the solution to your other
problem:

  Simply allow multiple instances of !_TAG_FILE_COMMAND, the first of
which creates the file, and subsequent ones append to it.

  In fact, the more I think about that, the more one of my other
suggestions becomes unnecessary (q.v.). Even *if* a command issued by the
user is globbed by the shell into 1000 odd files, it's *still* possible to
break that up into sveeral appended ctags commands.

  Then for regeneration, the list of ctags commands found is executed in
orderm as opposed to just issuing one. The first would crteated the
maintained command list, thereby allowing re-issue upon error.


  My other thought, which now not quite necessary, might still be a good
thought, is to add a -g/--glob option that allows to user to give quoted
glob patterns which *ctags* can expand (and hence include in the
generation of the tag files). If the 'keep generation command' option is
to be used, the help/docs. can recommend [enforce?] the use of -g to
specify files.

  E.g.,

ctags -f tagfile -g "$HOME/usr/include/*.h" -g "*.h"

   ... might give:

!TAG_FILE_COMMAND ctags -f tagfile -g "$HOME/usr/include/*.h" -g "*.h"
!TAG_FILE_COMMAND ctags -f tagfile -a -g "*.h"


  I think you may not want to put regen. info. in the tagfile by default
without restricting the number of !TAG_FILE_COMMAND entries (if you allow
mulitple entries).

  On the other hand - it'd make life on the command line simpler. You then
either just generate a tagfile as normal (no spacial args), or issue
'ctags --regenerate -f tagfile' and be done.

  You'd either need to actually prevent other args from being given in
this case, or somehow merge them with the existing ones (for, say, a
verbose debug run?)

-- 
=====================- http://www.thalesgroup.com/ -=====================
  Neil Bird   Principal Engineer                     |
       work - mailto:nei...@uk...    |    $> cd /pub
   personal - mailto:ne...@fn...                 |    $> more beer