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.