While ctags has the option to use regex to parse the source files, it is not what is being used for the vhdl module of ctags. The regex is only brought into the equation when the tags file is written for vhdl.
A solution involving ctags would require at least a partial re-parse and rewrite of the ctags file every time the file buffer is changed. (not a pretty solution) note: (I use token to mean any file data that needs to be kept-track-of.) I think a good solution for fixing this problem would be: rewriting the parser to include token scope, etc. and changing the tags file format, so the last tab delimited field per line would be a call to an external program. (do-able but, a bit bulky, and cumbersome) The program would output the location of the tag regardless of white-space reformatting or comments. This would break compatibility I'm almost sure of it. If we were to use GHDL to output all the token locations for each file and noting scope, the external program for locating the current location of the token regardless of white-space or comments would still be an essential tool. On Tue, Jul 22, 2014 at 11:46 AM, <[email protected]> wrote: > > Give me some time to look over the Exuberant Ctags code-base and I'll > > see what I can do. > > Can there be some general discussion with, exactly what are the > > shortcomings of the current parser: > > > > * Is there a problem with ctags not understanding that entity > > blocks and architecture blocks are connected in a fundamental > > way? > > * Are there library functions and constructs that are just too > > much for the current implementation? What do those look like? > > * Is ctags recognition outdated? > > * Is it ctags job to recognize things like flipflops, muxers or > > non-synthesizable constructs? > > From the discussion, Exuberant Ctags is using regexp to generate tags. > This works, but not very well (for example if you add a newline > or a comment). > The advantage of generating Ctags from ghdl is that this is accurate > and up to date. > > Note that the Ctags technology is somewhat old and poor. We can do > much better to handle hiding, overload and cross-file references. > That's a larger project... > > > I know the topic was on a project of larger scope but, for an IDE > > ctags is an important part of what people expect from one. > > Without good parsing support, the market for the up-and-coming IDE > > will be blasé at best. With this and that I work a full time job in > > mind, > > don't expect sudden results; If there is a wanting for new features I > > will do my best. > > Sure! > > Tristan. > > _______________________________________________ > Ghdl-discuss mailing list > [email protected] > https://mail.gna.org/listinfo/ghdl-discuss >
_______________________________________________ Ghdl-discuss mailing list [email protected] https://mail.gna.org/listinfo/ghdl-discuss
