bugfix Emacs TAGS format #43
Conversation
src/FastTags/LexerTypes.hs
Outdated
| , posLine = aiLine | ||
| , posOffset = Offset aiAbsPos | ||
| , posPrefix = aiPrefix | ||
| , posText = aiPrefix <> (fromString $ show $ unLine aiLine) |
There was a problem hiding this comment.
this is just a placeholder...
There was a problem hiding this comment.
we have the aiInput, so it should be a case of taking that position to the next newline.
|
It is late, I will fix the tests in the morning... but I have confirmed that this fixes the problem 😄 I suspect there is a similar bug in |
| increaseLine :: Line -> Line | ||
| increaseLine (Line n) = Line $! n + 1 | ||
|
|
||
| data SrcPos = SrcPos { | ||
| posFile :: !FilePath | ||
| , posLine :: {-# UNPACK #-} !Line | ||
| , posOffset :: {-# UNPACK #-} !Offset | ||
| -- | No need to keep prefix strict since most of the prefixes will not be | ||
| -- used. | ||
| , posPrefix :: Text |
There was a problem hiding this comment.
Since this field of the position is not used anywhere, I think it can be removed.
There was a problem hiding this comment.
all these fields are now used.
src/FastTags/LexerTypes.hs
Outdated
| , posLine = aiLine | ||
| , posOffset = Offset aiAbsPos | ||
| , posPrefix = aiPrefix | ||
| , posText = aiPrefix <> (Text.takeWhile (/= '\n') aiInput) |
There was a problem hiding this comment.
I think it would be nice to not populate this field if aiTrackPrefixes is False. I.e. when we're generating tags for vim - there's no reason to keep lots of lines around which will not be consumed in the end.
There was a problem hiding this comment.
it's a lazy field in the data type, so we get that anyway for free, or do I misunderstand ?
|
@sergv @elaforge I have updated the PR so the tests now pass. I can also confirm that the current release of And this patch produces identical output to |
|
Looks good to me, merging. Thanks for giving emacs some attention, it needed it! |
|
BTW I'll do a cabal release soon unless you have some other change in mind. |
fixes #42
This more correctly matches the output that I see from something like
exuberant-ctags, i.e. https://stackoverflow.com/questions/1990579