Skip to content
This repository has been archived by the owner on Sep 6, 2021. It is now read-only.

Add new comments preference. Support indent block comments on line co… #13254

Merged
merged 7 commits into from
Apr 24, 2017

Conversation

ficristo
Copy link
Collaborator

@ficristo ficristo commented Apr 1, 2017

…mment command

Fixes #13169

I created a new comments preference with an indent option with the idea of deprecate the indentLineComment preference. Is there a way to deprecate a preference?
I used a new object with the idea to add also a padding option in the future (like the CodeMirror addon), but maybe is better to simply create a new indentBlockComment preference without deprecate anything.
Any thought?

@redmunds
Copy link
Contributor

redmunds commented Apr 3, 2017

@ficristo I think it's more trouble that it's worth to deprecate the indentLineComment preference. I vote for simply adding a new indentBlockComment preference.

@redmunds
Copy link
Contributor

redmunds commented Apr 3, 2017

@ficristo Also, I think #13169 can be fixed without adding a new preference as follows:

For languages that do not have a different line comment format (such as HTML), the block comment format is used on a single line. In that case, the indentLineComment preference could be checked.

But I can also see the value of having a separate indenting preference for block comments.

@ficristo
Copy link
Collaborator Author

ficristo commented Apr 3, 2017

I would find indentLineComment a bit misleading if used also for block comments.
(In fact I wanted a single indent option to be used for line and block comments)
While I think the new object preference would be cleaner, I'll keep it simple and go with adding a new pref.

@ficristo
Copy link
Collaborator Author

ficristo commented Apr 5, 2017

I still need to test it a bit more

@ficristo
Copy link
Collaborator Author

ficristo commented Apr 9, 2017

It should be ready.
@redmunds do you have time to review?

@redmunds
Copy link
Contributor

Seeing weird results for block comment, indentBlockComment=true, and cursor at start of line (i.e. line not selected). Before:

  <p>lkj wlekjr wlkerj lwkejr wlke lqkwje lkqjwe lkqwje lwkqje lq</p>

After:

--<!-->  <p>lkj wlekjr wlkerj lwkejr wlke lqkwje lkqjwe lkqwje lwkqje lq</p>

if (indentBlockComment) {
var endCh = _firstNotWs(doc, sel.end.line - 1);
editGroup.push({
text: _.repeat(" ", endCh) + suffix + "\n",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can't always insert spaces -- need to use indent preference here in case it's Tabs.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great catch! Fixed.

@@ -2709,6 +2713,27 @@ define(function (require, exports, module) {
};

/**
* Returns true if blockCommentIndent is enabled for the specified or current file
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

First line of this comment is true for "get", but not "set".

@redmunds
Copy link
Contributor

@ficristo Done with review. Found a couple cases that don't work as expected, but mostly working as advertised. Tests pass for me on Mac 10.12.

@redmunds
Copy link
Contributor

Also, all Preferences should be listed in wiki here:
https://github.com/adobe/brackets/wiki/How-to-Use-Brackets#preferences

Please add indentBlockComment and indentLineComment (which was never added). Thanks!

@ficristo
Copy link
Collaborator Author

I cannot reproduce the issue above about the html. Is that the full snippet?

@redmunds
Copy link
Contributor

@ficristo To repro this bug, make sure cursor is at start of line, or in middle of indent. Doesn't seem to happen if cursor is immediately before start tag.

I also notice weird results when cursor is in middle of tag contents. Comment is added from start of tag to cursor positioin, which causes invalid HTML:

  <!--<p>lkj wlekjr wlkerj lwkejr wlke--> lqkwje lkqjwe lkqwje lwkqje lq</p>

@redmunds
Copy link
Contributor

@ficristo Here's a simple page where I'm also seeing problem on <p> tag:

<!doctype html>
<html>
<head>
<title></title>
</head>
<body>
  <p>one two three</p>
</body>
</html>

@ficristo
Copy link
Collaborator Author

ficristo commented Apr 12, 2017

Odd, I still cannot reproduce. I tryed opening a new folder with only a test.html file with the snippet you posted above.
Some tests I added put the cursor at the beginning of the line. Do all the tests pass for you?

Nevermind. The feature work if you use Edit \ Toggle Line Comment but not if you use Edit \ Toggle Block Comment. I'll take a look.

@ficristo
Copy link
Collaborator Author

Initially I thought that Edit \ Toggle Block Comment was equal to Edit \ Toggle Line Comment but added block comments. But instead it add a block comment starting and ending at the exact position of the cursors.
I don't want to change that.
I want to support indentation for line comments also for languages with only block delimiters (like html).
I also removed the new preference and reused indentLineComment, I think the new preference would be misleading.
@redmunds could you take a look?

@redmunds
Copy link
Contributor

@ficristo

But instead it add a block comment starting and ending at the exact position of the cursors.

Yes, that's the case when either start or end cursor is in middle of line. I agree that behavior should not change.

But the other case is when the selection only contains full lines (both start and end cursors are at start of line). In that case, a new line is added above selection with opening block delimiter, and another line is added after selection with closing block delimiter. This is the case where I was expecting the new indentBlockComment to take effect and delimiters would be indented to match code. Indenting for first line of selection might not match indenting of last line -- not sure how to handle that case.

Does that make sense? Let me know if you want to take that on or not -- I'll review code either way.

@ficristo
Copy link
Collaborator Author

Oh, I think we had a bit different things in mind.
(Now that I know what it does...) I prefer to leave Edit \ Toggle Block Comment as is.
While interesting, it would seem odd to match the indentatation when the cursors are exactly at the beginning but not if they aren't, or so it appears to me at the moment.
If possible I prefer to not implement this part of the feature.

function _firstNotWs(doc, lineNum) {
var text = doc.getLine(lineNum);
if (text === null || text === undefined) {
return null;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The return value from this function is not validated -- it gets used directly as a char position. Seems like it would be more consistent with CodeMirror APIs to return -1 here (but my CM API knowledge is rusty...).

@redmunds
Copy link
Contributor

@ficristo Done with review. Looks good except for maybe 1 change.

@ficristo
Copy link
Collaborator Author

ficristo commented Apr 20, 2017

I seems to remember I hit a case where the API could return null, but I don't remeber which...
And looking around the codebase I didn't find any check at all after the call to doc.getLine.
I changed it to return 0, I hope its fine for now.

@ficristo
Copy link
Collaborator Author

@redmunds could you take a final look (and eventually merge)?

@redmunds
Copy link
Contributor

LGTM. Merging.

@redmunds redmunds merged commit 9b03593 into adobe:master Apr 24, 2017
@ficristo
Copy link
Collaborator Author

Thank you.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants