Use tags-table-list instead of tags-file-name #592
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Do: then squash those commit into one commit (read on the internet how to do this) then force-push new version: |
|
In magit this is |
|
Phew, looks like I've done! Thank you, Gracjan! |
|
@lukehoersten: can you also have a look at this? How tags work is a bit of mystery to me... Thanks! |
|
What's the difference between |
|
It allows to use multiple TAGS files at the same time. Think: program +
library.
|
|
@lukehoersten I had similar question, original PR #478 message was:
|
Tested: + (haskell-process-generate-tags) ⇒ "Tags generated." + (haskell-process-generate-tags "SomeTag") ⇒ jumps to tag definition
lukehoersten
added a commit
that referenced
this pull request
Apr 22, 2015
Use tags-table-list instead of tags-file-name
purcell
added a commit
to purcell/haskell-mode
that referenced
this pull request
Nov 2, 2015
As part of haskell#592, commit 2b4e49c modified this code to alter the global value of tags-table-list as a side-effect, but this change was incorrect and causes problems elsewhere. Specifically, consider the following scenario: - User tries to jump to a definition with haskell-mode-jump-to-def-or-tag - That function falls back to haskell-mode-tag-find, which then calls haskell-mode-jump-to-tag This results in a call to haskell-process-generate-tags, which tries to run hasktags, whether or not it is installed. As a side effect, the global value of tags-table-list is set to include "/project/root/dir/TAGS", which was probably not even created properly (most people won't have hasktags installed). Then, imagine we're working in an unrelated project, and use Emacs' built-in completion-at-point functionality (or company-mode, which wraps it). Now, the tags-completion-at-point-function (enabled by default) sees and uses the modified value of tags-table-list, and errors noisily when called because that file does not exist. And even if it didn't error, the tags would not be relevant to the current project. In other words, this code either breaks or disrupts completion everywhere beyond the current haskell project. So, the correct solution here is to leave tags-table-list unchanged: users such as the author of 2b4e49c should instead use directory-local variables to set tags-table-list or tags-file-name locally to their haskell project.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Tested:
Sorry, I can't get rid of first commit (without delete and re-fork).