Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Change tags file default path to .vscode/tags #722

Merged
merged 1 commit into from
Feb 9, 2017
Merged

Change tags file default path to .vscode/tags #722

merged 1 commit into from
Feb 9, 2017

Conversation

jltrv
Copy link
Contributor

@jltrv jltrv commented Feb 8, 2017

Motivation for this change:
The appearance of the tags file at the root of the project is a bit surprising when using the extension. Since that file is only relevant when using vscode with the python extension, it should live in the .vscode folder.

See https://github.com/DonJayamanne/pythonVSCode/issues/721

@DonJayamanne
Copy link
Owner

@jltrv you might want to modify the code to be backwards compatible (i.e. what about the others users using this extension today and have a tags file in the root directory).

@jltrv
Copy link
Contributor Author

jltrv commented Feb 9, 2017

Currently the extension will regenerate a new tags file if we change the path, are you suggesting auto-moving the file ?

@DonJayamanne
Copy link
Owner

Ah yes that's fine

@DonJayamanne DonJayamanne merged commit 70abdf7 into DonJayamanne:master Feb 9, 2017
@jltrv
Copy link
Contributor Author

jltrv commented Feb 9, 2017

Soooo... it turns out when the tags file is not directly at the workspace root, symbol searching (Cmd+T) breaks on file paths.
My PR should probably be reverted.

@DonJayamanne
Copy link
Owner

DonJayamanne commented Feb 10, 2017

@jltrv I'll look into that, should be easy fix. Thanks for pointing the issue out.

DonJayamanne added a commit that referenced this pull request Feb 10, 2017
@danieljl
Copy link

danieljl commented Mar 7, 2017

@DonJayamanne Thanks for the fix! But we still need to create .vscode directory manually, otherwise it won't work. Maybe .vscode directory creation should be automated?

@DonJayamanne
Copy link
Owner

Lol... Will do, please could you create an issue for this.. Lest I forget

DonJayamanne pushed a commit that referenced this pull request Feb 16, 2018
* Basic tokenizer

* Fixed property names

* Tests, round I

* Tests, round II

* tokenizer test

* Remove temorary change

* Fix merge issue

* Merge conflict

* Merge conflict

* Completion test

* Fix last line

* Fix javascript math

* Make test await for results

* Add license headers

* Rename definitions to types

* License headers

* Fix typo in completion details (typo)

* Fix hover test

* Russian translations

* Update to better translation

* Fix typo

*  #70 How to get all parameter info when filling in a function param list

* Fix #70 How to get all parameter info when filling in a function param list

* Clean up

* Clean imports

* CR feedback

* Trim whitespace for test stability

* More tests

* Better handle no-parameters documentation

* Better handle ellipsis and Python3

* #385 Auto-Indentation doesn't work after comment

* #141 Auto indentation broken when return keyword involved

* Undo changes

* #627 Docstrings for builtin methods are not parsed correctly

* reStructuredText converter

* Fix: period is not an operator

* Minor fixes

* Restructure

* Tests

* Tests

* Code heuristics

* Baselines

* HTML handling

* Lists

* State machine

* Baselines

* Squash

* no message

* Whitespace difference

* Update Jedi to 0.11.1

* Enable Travis

* Test fixes

* Undo change

* Jedi 0.11 with parser

* Undo changes

* Undo changes

* Test fixes

* Re-lint when interpreter changes

* Re-lint on linter config change

* Run linting command

* Encapsulate jupiter

* Handle promise

* More tests

* Tests

* Use service

* Linter provider tests

* Move methods to documents manager
DonJayamanne pushed a commit that referenced this pull request Mar 7, 2018
Due to a bug in Pylint where specifying `E` as enabled checks flips on `--py3k`, we need to explicitly list all `E` checkers to explicitly avoid (at least) print-statement which throws false-positives for folks not porting to Python 3.

Closes #722 by partially reverting #954
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants