-
Notifications
You must be signed in to change notification settings - Fork 378
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
fullDocs option for doc_comment #425
Conversation
Updated demo with default value for fullDocs to make it easy for users to understand. Added documentation to manual.txt.
Only remove JSDoc asterisks and start/end spaces from comments when using fullDocs. Use the last comment instead of the first. Always remove preceding asterisks from result.
@p-bakker you are right! I didn't think about this before but it makes a lot of sense. I made a few changes including changes to parsing when not using fullDocs (see code comments). |
if (aval instanceof infer.AVal) aval.doc = first; | ||
if (type) type.doc = first; | ||
var result = comments[comments.length - 1]; | ||
if (fullDocs) result = result.trim().replace(/\n {0,}\* {0,}/g, "\n"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This removes all asterisks that are part of the JSDoc structure except the first one (which is removed later). This is important as it keeps asterisks that are part of the documentation; example of asterisk in documentation:
/**
* Solves equations of the form a * x = b
*/
This also preserves the newlines inside of the comments.
Did a quick test and for me the code is now failing in some scenario's:
There might be a good reason why you deviated from using the regex I suggested (/^(\ |\t)\ ?\r?\n?/gm), but at least that one got above two points right I tried to figure out what the last regex is for (/^\s{0,}*{1,}\s{0,}/), but couldn't figure it out. And I didn't check the changes made to non-fullDocs variant Maybe it would be good to have some tests for this. Some of the testcases could be:
|
Remove any combination of tabs and white spaces before the jsdoc comment line start. Only remove a single whitespace after the jsdoc comment line start (keep original spacing).
fullDocs PurposeI think the purpose of the fullDocs option should be to allow the editor's tern plugin to decide how to handle the comments. This means the returned comments from tern should contain the original comments (including all spacing) minus the comment structure. Example: /**
* sentence one. sentence two.
* Indented sentence.
* @param {bool} [p1=false] - param 1
*/
function test1() {} should return:
Updates
@p-bakker thankyou for pointing this out. I just updated it to remove any combination of tabs and spaces before the jsdoc newline comment start.
@p-bakker You are correct again. The updated regex only removes the first whitespace after the jsdoc newline comment start.
@p-bakker scroll up in this pull request and read the comments on the changed line. It simply removes any preceding asterisks from the result.
@p-bakker the test case you presented with the nested example is invalid javascript (it has block comment end inside of block comment which causes premature comment ending). Tests would be ideal but I'm not exactly sure how to write them for tern as its not well documented. I use the code below for testing (manually): //paste this code in tern demo with fullDocs=true
test //start auto complete here
/**
* sentence one. sentence two.
* Indented sentence.
* @param {bool} [p1=false] - param 1
*/
function test1() {}
/**
* @param {String} name
* @return {String}
* @example
* test2(1) * 1 = undefined
*/
function test2() {}
/** test function 4*/
function test4() {}
//test function 5
// line two of test 5.
//line 3 (not indented)
function test5() {} |
Ah, right, I did something wrong there. The nested blockcomment should be done like this:
|
https://github.com/sevin7676 test code: //paste this code in tern demo with fullDocs=true
test //start auto complete here
/**
* This comment block is indented with both tabs and spaces.
* @param {bool} [p1=false] - param 1
*/
function test1() {}
/**
* @param {String} name
* @return {String}
* @example
* test2(1) * 1 = undefined
*/
function test2() {}
/** test function 4*/
function test4() {}
//test function 5
// line two of test 5.
//line 3 (not indented)
function test5() {}
/**
* @example <pre> //Example of extending the base class
* /**
* * Extended Event class that also exposes getPosition
* * @private
* * @constructor
* * @extends {EventManager.Event}
* *
* * @param {String} type
* * @param {*} source
* * @param {{
* * x: Number,
* * y: Number
* * }} [position]
* * @param {Object} [data]
* */
* function Event(type, source, position, data) {
* EventManager.Event.call(this, type, source, data); //Applying the arguments to the base class constructor
*
* this.getPosition = function() {
* return position||null;
* }
* }
*
*/
function test6() {} The tern plugin is responsible for converting |
The latest regex doesn't work if the whitespace preceding the * is "\t \t". This regex would work:
Or simpler:
|
Think we're onto a winner now :-) You're right about the simpler one not working all the time, forgot to test that scenario. FYI: a handy tool to build and test regex: http://regex101.com/#javascript |
This would be the correct simpler version:
|
@p-bakker I updated it with the even simpler regex. I use regex101 (its awesome!). Thanks for your help! |
Thanks. Merged as f9b553f and cleaned up in ec16bc7. The choice of using the last comment above a statement might cause some regressions (see example below, where the description of a function is spread over several comments), but in general it is probably a win.
|
Just a heads-up: I've removed this option again in fd7a999 and made it the default behavior. |
Issue ternjs/tern_for_sublime#76 Issue #563 Issue #555 Issue #425
And another heads-up, attached patch makes the default behavior to strip off long text again, and allows you to add a |
Why? Is the full documentation causing performance issues? If not, shouldn't the client decide to trim the string as it sees fit? I'm not attacking your decision, just hoping for a little bit of an explanation as to why... |
The client is deciding to trim the string, by not passing that query parameter. The string trimming logic is involved enough (and likely to be refined in the future) that I don't want to duplicate it in every client. Also, it seems a good idea not to change the old default behavior. There's no performance issues, just that people were suddenly seeing @-jsdoc mess in their tooltips, and not happy about it. |
Closes #411
Updated demo with default value for fullDocs to make it easy for users
to understand. Added documentation to manual.txt (I don't know how to run the Makefile to regenerate the manual.html file - I'm using Windows).