Hello Kaz,

You raise a good point here. I am going to research the possible approaches available to address the problem you raise. My main concern is providing the necessary backwards compatibility.

Darren

On Oct 31, 2011, at 3:23 PM, Kaz Kylheku wrote:

Hi JD,

There is nothing wrong with adding another option, or parameter to an option.

"ctags has more options than ls" is just someone's emotional problem, not a technical issue.

But I agree that adding another option to ctags might not be the best way. This issue is caused by the semantics of the tags file, which comes from the legacy of the vi editor.  The original vi tags system didn't have the concept of a filename tag. Tags were for things inside the file, not the file itself. Ctags just works with the results of this legacy.

Perhaps it is Vim that should have the option of ignoring a request to perform a useless jump to line 1 encoded in a tags file. Even as a default behavior, it would be acceptable. There will rarely be an identifier tag pointing to line 1, and if that's a problem, pattern tags can be used anyway.

Here is another idea: how widely do various editors react to the line number being 0 instead of 1?  In vim, if we run "vim +0 file", the effect is the same as "vim +1 file". Likewise, this editor does not mind a 0 in the tags file.

If the most widely used editors are similarly tolerant to 0, that could be generated for file tags. Later, people could hack their editors to interpret the 0 differently from 1.

P.S. I don't think that scripting in some big, messy programming language to post-process its output is a convincing answer to the objection that a program has too many options. :)

On Mon, 31 Oct 2011 13:27:16 -0600, "J.D. Laub" <ctags@laubster.org> wrote:

If the original post was a request for an option to customize the ex_cmd for file entries, the first bug listed at http://ctags.sourceforge.net/ctags.html#BUGS is relevant: "Ctags has more options than ls(1)."  Adding another seems a step in the wrong direction.

For those wants to customize the ex_cmd to a specific vim command "singlequote doublequote" instead of the positioning command "1", confirm that vim is the only consumer of your tag file (not the case in all shops, like mine), then try either of these barely-tested commands:

perl -p -i -e 's@^(([^\t]+\t){2})1;@$1\x27";@' tags

or

perl -F'\t' -i -ape '$F[2]=s@1;@\x27";@' tags

 
 
 

On Tue, 25 Oct 2011 16:06:23 -0700, Kaz Kylheku wrote:

On Tue, 25 Oct 2011 22:45:11 +0000, Gary Holloway
<Gary.Holloway@castandcrew.com> wrote:
"parser.c" is a tag to the source file itself, hence the tag's "location" is line 1, so it's going to line 1, which is exactly where it should go.
Yes; this is the behavior I would like to customize. I'm accustomed
to the cursor being where I last edited when I open a file.

Line 1 is exactly where the cursor should go if your user name
is a member of the set that includes "Gary Holloway"; it
would be a shame if that behavior went away.

Others might prefer the behavior of "vi -t parser.c" to be
more or less exactly that of "vi path/to/parser.c".
The quote in the tag file introduces a comment.
I see. The man page gives this general format:

tag_namefile_nameex_cmd;"extension_fields

Somehow, using the command '" for ex_cmd works. The
end result is that the cursor jumps to the correct line.
Perhaps this is by some kind of fluke.
If you 'vi -t' to a tag that is a function in the file, it will go to that line in the file when opened.
Well yes; that would be the "hello, world!" use case for tags, right?

But from this it does not follow that if I'm referencing an
object which is a file, I must also want the first line of
the file.

For one thing, the first line of the file kicks off a
50 line copyright and licensing notice, identical to one that
appears in dozens of other files.