New feature: Highlighting whitespace errors #1897
Conversation
Nano does highlighting of trailing whitespace only. As I'm transitioning from Nano to Micro, your PR is godsend! |
|
@zyedidia what do you think about this? |
|
Ping. Are there any blockers to this being merged? |
|
Just stumbled upon this and would welcome this addition. Is this still viable? |
|
I'm still using it all the time. If you feel like compiling micro yourself, you can also pull this PR and try and use it. @zyedidia Any chance you review this PR? |
|
I would like to see this feature in the near future too, because it's a really good idea to add this in a generic way into the But just one question from my side: |
|
I consider trailing whitespace an error too, so tab errors are just a special case of whitespace errors. Or are you suggesting to combine both options into a single option, which would be not boolean but allowing to specify what to highlight: trailing ws, tab errors, or both, or neither, and perhaps others types of ws errors in the future? Maybe it's a good idea. Or maybe it isn't worth it. (BTW, the |
|
No, combining So yes, that took an interesting direction. |
|
I see here one weird thing. If we consider something as an error, we shouldn't reproduce that error but auto-indentation just copies previous line indentation so if it contained error, new line will contain the same error |
Shouldn't we? Consider such a code:
The So I think it's better to keep things simple and keep these 2 features (highlighting indentation errors and auto-indentation) orthogonal to each other, i.e. avoid introducing interdependence rules with unexpected consequences. |
|
Ok I think you are right |
|
Rebased on top of the newest master (just to clean up the commit history, no functional changes). |
Community asks! One more reason to ping @zyedidia |
|
These things have bothered me a lot in the micro repos, there are PR's like this one almost 4 years old where the "owner" of the editor doesn't show up in the discussions even when called while others the merge is done in less than a month. I believe that in the beginning only one person used this editor, but that's not the case today. I don't want to get into the merits of individual time spent reviewing and responding to each topic. I hope we can achieve this without having to fork the project, but if we do that's great too, it would be a plus for the community to know that it could be active and welcomed in this fork. It reinforced the question that my friend deleted:
And how much longer does he intend to wait? |
|
I created a discussion to centralize this. |
|
@dmaluka: @ the rest: |
Added option `hltaberrors` which helps to spot sloppy whitespace errors with tabs used instead of spaces or vice versa. It uses the value of `tabstospaces` option as a criterion whether a tab or space character is an error or not. If `tabstospaces` is on, we probably expect that the file should contain no tab characters, so any tab character is highlighted as an error. If `tabstospaces` is off, we probably expect that the file uses indentation with tabs, so space characters in the initial indent part of lines are highlighted as errors.
Added option `hltrailingws` for highlighting trailing whitespaces at the end of lines. Note that it behaves in a "smart" way. It doesn't highlight newly added (transient) trailing whitespaces that naturally occur while typing text. It would be annoying to see transient highlighting every time we enter a space at the end of a line while typing. So a newly added trailing whitespace starts being highlighting only after the cursor moves to another line. Thus the highlighting serves its purpose: it draws our attention to annoying sloppy forgotten trailing whitespaces.
Fix unwanted highlighting of whitespace in the new line when inserting a newline after a bracket (when hltrailingws is on). To fix it, change the order of operations: insert the new empty line after all other things, to avoid moving the cursor between lines after that.
Handle the case when the cursor itself hasn't really moved to
another line, but its line number has changed due to insert
or remove of some lines above.
In this case, if the cursor is still at its new trailingws,
we should not reset NewTrailingWsY to -1 but update it to the
new line number.
A scenario exemplifying this issue:
Bind some key, e.g. Alt-r, to such a lua function:
function insertNewlineAbove(bp)
bp.Buf:Insert(buffer.Loc(0, bp.Cursor.Y), "\n")
end
Then in a file containing these lines:
aaa
bbb
ccc
insert a space at the end of bbb line, and then press Alt-r.
bbb and ccc are moved one line down, but also the trailing space
after bbb becomes highlighted, which isn't what we expect.
This commit fixes that.
Improve user experience: if we are at a line with a new (i.e. not highlighted yet) trailingws and we begin selecting text, don't highlight the trailingws until we are done with selection, even if we moved the cursor to another line while selecting.
This PR implements highlighting of common whitespace problems (trailing whitespaces and tab/space errors), making it easy to spot such problems. It is somewhat similar to highlighting of whitespace errors by
git diff.Namely, added 2 new options
hltaberrorsandhltrailingws(both disabled by default).hltaberrorshighlights tabs used instead of spaces and vice versa. It uses the value oftabstospacesoption as a criterion whether a tab or space character is an error or not.If
tabstospacesis on, we probably expect that the file should contain no tab characters, so any tab character is highlighted as an error.If
tabstospacesis off, we probably expect that the file uses indentation with tabs, so space characters in the initial indent part of lines are highlighted as errors.hltrailingwshighlights trailing whitespaces at the end of lines. Note that it behaves in a "smart" way. It doesn't highlight newly added (transient) trailing whitespaces that naturally occur while typing text. It would be annoying to see transient highlighting every time we enter a space at the end of a line while typing.So a newly added trailing whitespace starts being highlighted only after the cursor moves to another line. Thus the highlighting serves its purpose: it draws our attention to annoying sloppy forgotten trailing whitespaces.
I don't really know if such smart highlighting of trailingws is implemented in any of the existing editors. If it's not, micro can be the pioneer.
A screenshot with
hltaberrorsandhltrailingwsworking on a real-life example: micro's help (it does have some trailing spaces as well as some mixture of tab and space indentation):