-
Notifications
You must be signed in to change notification settings - Fork 130
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
consider proportional font char width #656
Conversation
This makes the package consider the actual width of characters from proportional fonts when displaying them on the minimap.
Hi @Zambonifofex, sorry for the very late reply. While I would have enjoyed see support for proportional font, it looks like this implementation have a catastrophic effect on performances. I pulled the PR locally to test it and opening the |
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.
As is the performances are lacking so I can't merge it, but if any improvements were to be made making the whole thing almost as fast as the current system then it'll be good to merge.
Hello, @abe33. You don’t need to worry about taking time to reply at all! I have realized this problem soon after I made this pull request. I was hoping to mention it, but eventually I forgot and moved away because of the lack of interest. But now, since you actually showed interest, I figured I should spend some time thinking about it again. I spent yesterday trying a couple different approaches such as reading the size directly from the DOM in the Atom editor itself. Eventually I came accross the I created this method called I called it “estimate” because it’s exactly that, unfortunately. It calculates the advance‐width of each token, but it fails to realize that kerning between tokens and ligatures might make the estimate wrong. For example, consider that I have the following text in an editor:
And suppose that I have a grammar that considers A better estimative would be to measure the advance‐width of the entire line, perform the current estimation on each token of that line, then finally scale the estimate of each token so that they all fit within that line. Of course, that’d still be just a estimative. Consider that I have the following text in an editor, and the same grammar I already mentioned:
Now, the lines have same width, but the spaces in the middle that are aligned in the editor are offset from each other in the minimap. Unfortunately, I don’t think there is a clear solution to this problem. Something to note is that I got rid of the use of the character width setting from the methods I edited as well as of the placeholder character I estimate the character height by assuming it is equal to the font size. I commented out a more sofisticated approach using attributes of the result of the My hope is that the character width setting as well as the interline setting can eventually go away, as they can be derived from the minimap plugin’s character height setting and Atom’s builtin line height setting. Something else kinda cute that could be done once the fancier Not particularly related to this pull request and issue, but noteworthy nonetheless: Something I’ve worked on when I first started playing around with the minimap codebase is the ability to resize the minimap with a handle. Something else related to that I also worked on is to have the minimap be naturally sized based on the actual width of the editor, making so that characters that don’t appear on the editor when it is scrolled all the way left also won’t appear on the minimap. (As well as characters that do appear on the editor will always appear on the minimap.) Whenever I dragged the handle, it changed the size of the minimap. Whenever I double‐clicked the handle, it resetted the minimap to the be based on the width of the editor. Unfortunately, I don’t think I have that code anymore. But if there is interest, I can try to work on it again. Talking about proportinal font support once again, I’m not sure whether I can use this pull request to share the code I wrote, and even if I can, I’m not sure it’s a good idea, since the code I wrote now has nothing to do with the code I wrote then. Worst case scenario I end up creating a different pull request to share my code. Also, I’m not sure if I should start working on the second estimation approach I mentioned before sharing my code, or if I should just share it as it is and think about it later. 🤔 Finally, sorry for the lengthy comment. I feel like generally I’m kinda bad at containing my own thoughts when I’m writing. 😅 |
So, I created the following grammar to test out what I said: {
"name": "Test Language",
"scopeName": "my-language",
"fileTypes": [],
"patterns":
[
{"match" : "l(LT)*", "name": "keyword"},
{"match": "L", "name": "keyword"}
]
} And, as it turns out, the behavior I said would happen in the minimap also happened in the actual editor. I’ve reported the bug to the Chromium issue tracker, but, until it gets fixed, I think it’ll be a good idea for me to just share the code I’ve written already. |
Hi @Zambonifofex and thank you for taking the time of writing such a detailed post 🙇. There's definitely interesting information here. As I said, I had started looking into this a long time ago and this is definitely a healthy refresher about current possible solutions. I'll try to take some time today or tomorrow to write down some of the things I had in mind at the time (I need to find the notes I wrote at the time). Stay tuned |
Closing since it is marked |
This makes the package consider the actual width of characters from proportional fonts when displaying them on the minimap.
Notes:
minimap-selection
. (If no‐one else wants to, I can probably try to do it.)