Re: IDE

[Eli Zaretskii]

> From: Oleh Krehel <address@hidden>
> Cc: Dmitry Gutov <address@hidden>,  address@hidden,  address@hidden,  
> address@hidden,  address@hidden,  address@hidden
> Date: Tue, 27 Oct 2015 09:21:40 +0100
> 
> >> > Once again, the issue is not the format of the database.  That's
> >> > immaterial.
> >> 
> >> Database format can have a real performance impact.
> >
> > Yes, but the issue is performance, not the database format.
> 
> If I understood correctly what you mean by the database format, it
> matters to me. The TAGS files are too simplistic, they don't understand
> the language, either C and especially C++.  On the other hand, have a
> look that these Semantic tags entries for e.g. etags.c:
> 
> ("regex.h" include (:system-flag t) nil [4626 4644])
> ("CTAGS" variable (:constant-flag t) nil [4934 4939])
> ("streq" function
>          (:typemodifiers ("static")
>                          :arguments 
>                          ( ("s" variable
>                                 (:pointer 1
>                                           :constant-flag t
>                                           :type "char")
>                                 (reparse-symbol arg-sub-list) [4973 4987])
>                            ("t" variable
>                                 (:pointer 1
>                                           :constant-flag t
>                                           :type "char")
>                                 (reparse-symbol arg-sub-list) [4988 5002]))   
>                
>                          :type "bool")
>          nil [4954 5035])
> 
> This is a lot of useful information in a readable and usable format.
> The only problem is that it's a little slow to parse: 190 files in
> emacs/src take around 30 seconds for a full reparse. But then, all this
> info is kept and is re-parsed only on timestamp changes.
> 
> I did a caching optimization for `moo-jump-local' from function-args
> package. When called without update it takes <0.1s to bring up all 19356
> semantic tags. The update (through a call with "C-u") takes ~3 seconds +
> reparse time for any out-of-date file.
> 
> My point is that because `moo-jump-local' uses semantic, it's a lot more
> precise than e.g. `ggtags-find-definition' that gives only the names of
> 9956 tags, with no semantic information.

The point I was trying to make is that for users all this is
unimportant.  All they want is functionality: performance, accuracy,
minimum false positives, etc.  How this affects the database format is
something they expect us the developers to figure out.

And even if you take the POV of a developer, first there should be
requirements: performance, accuracy, supported languages, etc.  Only
after that we get to design and implementation, where we select the
database which can enable the functionality and support the
requirements.  Note as you explain above why TAGS might not be
appropriate _because_ it cannot support certain important
functionality:

> In my opinion, the tags format of semantic is very good, much better
> than plain TAGS. Maybe some work needs to be done to make them generate
> faster/more precise, e.g. make GCC output these tags files.

And that's my point exactly: first there's functionality we want, and
only after that comes the selection of the database.