Open MasterInQuestion opened 8 months ago
The line numbers are meant to be highlightable. Also, I don't see anything unusual with the whitespace when I do "editor.renderWhitespace": "all"
?
So when selected... Does it mean to select the file's content, or the added line numbers along with?
Does the displayed portion of file contain leading " "..? Or is it the culprit of the display?
Since there are leading spaces, it shows dots in place of the spaces.
How to tell if it's the line numbers' space, or the file itself..?
Hey @andreamah, this issue might need further attention.
@MasterInQuestion, you can help us out by closing this issue if the problem no longer exists, or adding more information.
This issue has been closed automatically because it needs more information and has not had recent activity. See also our issue reporting guidelines.
Happy Coding!
The bot screwed up: Change in the main post not noticed.
The end of the line number should be aligned on each line. You can look at where this ends to see where the actual file line starts.
Noticed, as in your image. Somehow tricky to guess: if the file also has " " (Space) indentation. (in particular, trailing " " on empty lines)
Right. I believe that the alignment from the search editor is usually the longest line number plus 1 space (the longest line is usually the one with the colon). Then, you can sort of benchmark where the alignment ends?
Yes..?
Currently, this is an editor view, so it's inevitable that the line numbers are selectable. Also, in some cases, when people copy+paste the text, they want to also select the numbers. Does this answer your issue?
Unsure which case happens more frequently... (IMO most wouldn't want the line numbers) Whatever, the look may be confusing. (per aforementioned)
We can make this a feature request candidate for being able to remove line numbers.
This feature request is now a candidate for our backlog. The community has 60 days to upvote the issue. If it receives 20 upvotes we will move it to our backlog. If not, we will close it. To learn more about how we handle feature requests, please see our documentation.
Happy Coding!
This went awry...
The line numbers are basically always expected for informational purpose:
Merely the selectability and display (with `"editor.renderWhitespace": "all"
`).
If the line numbers weren't selectable, I probably would want a different UI, and that isn't quite in the scope of what we originally wanted in the search editor.
Perhaps. 2 issues: |1| People may expect to have line numbers selectable and unselectable, the same time. |2| Hinting the whitespace of predictable content would be likely meaningless: and at times mere noise (per the hinting scheme). [ See [ https://github.com/orgs/community/discussions/68734#discussioncomment-7487371 ], the underlining issue. ]
Regarding # 2, we would need a new API to support editors that have this type of non-selectable content, which we currently don't have the bandwidth to handle anytime soon (to be honest).
For its high predictability, maybe simply sorting the content out with RegEx..? (I may help)
Ideally, it would be to selectively force no whitespace hinting for part of the content based on: |1| In Search Editor? |1.1| RegEx match? [ Proposed: /^\s*\d+[ :] /gm ]
----
I think the #1 may be also sort of addressed in similar manner: Making certain content in Editor unselectable conditionally.
Perhaps some fundamental redesign needs to be considered for the Search Editor.
"Test Sample.html": https://bugzilla.mozilla.org/show_bug.cgi?id=587438#c17
I further noted the text content being editable... [ Doesn't seem to make sense in Search Editor. ] Also a language highlighter named "search-result": Seem to apprehend your original intent of which: though which may not be of much practical use: |1| Mostly doesn't work out-of-the-system. |2| Tricky general interoperability due to the Space handling. |3| Without the search functionality, these texts hardly make much sense.
I further noted the text content being editable... [ Doesn't seem to make sense in Search Editor. ]
We make this editable because people might want to change the text content before saving the editor contents as a file.
Also a language highlighter named "search-result":
Are you talking about syntax highlighting? https://code.visualstudio.com/api/language-extensions/syntax-highlight-guide This only regards the color of the text, not the text highlight itself.
For its high predictability, maybe simply sorting the content out with RegEx..?
Again, this would require an API to control what can be highlighted, which does not exist yet.
(via the "search-result" highlighter) I seem to understand your intent making the Search Editor interface mostly implemented in Plain Text: Perhaps for some special uses, though of limited practical use.
Depends. And probably not "what can be highlighted". Regardless, the core definition has been given mostly.
You could perhaps write an extension that affects what is consumed by the clipboard when you copy from a search-result file https://code.visualstudio.com/api/references/vscode-api#Clipboard.
Thanks for the hint. (though the whole problem requires more than Clipboard access to address) I might consider it. Or perhaps things there might change even sooner...
See: https://github.com/microsoft/vscode/issues/201719#issuecomment-2048611360
= Line numbers selectable in Search Editor ("search.action.openNewEditor") =
Unsure if it's really intended behavior. Also the whitespace displays unusually with `
"editor.renderWhitespace": "all"
`.----
Version: 1.88.0 Commit: 5c3e652f63e798a5ac2f31ffd0d863669328dc4c User Agent: Mozilla/5.0 (Linux; rv:999) Gecko/20100101 Firefox/999 Embedder: vscode.dev