ghci etags for emacs (was: better generation of vi ctags in ghci)

[Peter Hercek]

Simon Marlow wrote:
> I'm an infrequent etags user, and I never use ctags.

The problem is I do not know whether I should try to improve etags too. 
So far I tried to keep them the same they were. The only difference I 
know about is that if more tags happen to exist on the same source line 
then they may have different order (but only within the group of the 
symbols on the line). This is probably because different GHC interface 
is used and the symbols are coming in different order. Vim can accept 
emacs tags too and they work fine as they are generated by the new code.

So the questions for emacs users are:

* Should the non-exported top level symbols be added to emacs TAGS file? 
As far as I could find on the internet, emacs does not have notion of 
"static" symbols as vim has so it may not be a good idea. But if emacs 
prefers jump to a symbol in the local file to symbols in the other files 
it may work well enough to be worth it.

* The last data field of the tag definition is "byte_offset". But in 
past (and I kept it as it was so even when the patch is applied) this 
was actually byteOffset-numberOfLines*sizeOfLineDelimiter. The size of 
newLine delimiters was ignored (and moreover it is system dependent). 
This does not matter that much since based on Claus information emacs 
allows some fuzz in the position information. The question is whether to 
keep this as it was or add 1 for each line or somehow try to detect 
platform and add the correct number of bytes for each line?

If no answers come I just keep it as it is and hope for the support of 
the vim related ctags changes only :)


Peter.