Quoting Joerg Fischer <[EMAIL PROTECTED]>:
> Bert Wesarg wrote:
>
> > ...
> > So, I ended up with this:
> >
> > list_{tags,tips}([file ][, stub [, mode]])
>
> You're right, list_tags() and list_tips() is better than the mode
> option. What searching is concerned, I thought it is better to search
> in a macro string. Suppose we have a thousand tags and we're
> interested in those tags that match a certain pattern, which would be
> roughly a dozen tags. Searching like implemented in the original
> patch, this would mean one search per tag. Searching in a macro
> string, ie, a newline separated list of all tags, this would mean just
> a dozen searches. Moreover, I thought the most common pattern would
> be for completions, in which case one can get the desired tags
> directly without doing searches. This explains the whole thing. I
> didn't consider the naming of the function or why to have an mode
> option or having two functions. There were no rationale about these
> things.
Consider also things like multipart lookup with class and namespace names as
in C++ and Java. I have found that tag lookup can't cope with partially
qualified names.
ctags can give fully qualified names (in C++ at least), or just the final
entity name, ie biglib::common::util::mybit as well as mybit. Now select mybit
and hit Ctrl-D to look it up and you find >100 matches. Select the fully
qualified name and you just get the one. Thing is your code most probably has
a midway stage, eg util::mybit. Select that and Ctrl-D - nothing is found.
This is verging on a bug!
Tony
--
NEdit Develop mailing list - [email protected]
http://www.nedit.org/mailman/listinfo/develop
