Open Tyriar opened 6 years ago
just rewrite the terminal service If it's not feasible
why is this feature taking several years what am I missing?
(https://github.com/microsoft/vscode/issues/34103#issuecomment-1680584127)
Look, I get that many of us have reasons to hate on Microsoft, but berating their engineers working on open-source (or at least, source-available) and free (as in beer) projects isn't a good way to cope with it, because:
Once more for those in the back: open source isn't special. "submit your own patch" isn't a shield, it's literally the one unique thing you can do compared to closed-source, proprietary stuff.
On the other hand, demanding that some other engineer do it because they're paid (not by you) by the company funding the development of the project isn't open source, it's open entitlement. It's the type of thing that makes corporations feel like
"open source" is childish and unreasonable
(https://github.com/microsoft/vscode/issues/34103#issuecomment-1684891222)
Thanks for coming to my TED talk, mods, please hide the above bunch of comments so other people who come looking for terminal ligature support won't go away shaking their hands and without terminal ligature support.
Hi @jeslinmx, That's a good TED talk. However, there are two things you got wrong.
VS Code is a fork of gh:microsoft/vscode
. However, the majority of users believe that VS Code is a distribution of gh:microsoft/vscode
.
gh:microsoft/vscode
is MIT lincenced (not FOSS/copyleft)gh:microsoft/vscode
is not the source code of VS Codegh:microsoft/vscode
repository description literally links to https://code.visualstudio.com/This is a Microsoft product, with Microsoft responsibility, management, and funding.
The narrative of gh:microsoft/vscode
being the open source VS Code repository was mistakenly constructed from misleading web pages, readmes, videos, and word-of-mouth conversations. The term "Code - OSS" does not fix this. Microsoft's failure to uphold its responsibility in this case is a reminder of the importance of corporate ethics.
Sorry @Tyriar, but comparing this distribution model to Google Chromium/Chrome is again a bit misleading. Google Chrome does not title itself as being "built on open Source" whatever that means. Atom was, but it had no users, which was a product design issue, not a licencing issue.
https://en.wikipedia.org/wiki/Visual_Studio_Code
made by Microsoft
https://en.wikipedia.org/wiki/Google_Chrome
developed by Google
Not called "open source" once in either article.
Go ahead and try to get any downloads on a closed-source npm package. good luck. It's the same everywhere. The super secret SaaS product your company is working on would hardly get any downloads if distributed closed-source. Yes, we usually tend to overvalue our own software. But no developer will ever choose a closed-source technology (framework, library, middleware, code linter, etc.) to develop their own software with. VS Code and GitHub are an absolute exception to this, being the only closed-source non-infra technologies that the majority of developers use.
Oftentimes SaaS vendors don't even have the choice anymore to go closed-source. Without adoption, maybe even without VC investment, you can't build the product, and huge repercussions (https://www.youtube.com/watch?v=HzBA6FIn_Bo&t=142s) will follow if you close it afterward.
Only apps and games distributed within app stores benefit from being closed-source as of 2020. Users and developers expect products to be source-available. This is a significant change from 20 years ago. I would argue a positive cultural development. The world should not be split into computer wizards and mortals.
How about you mark your own post as off-topic 😅. Because my previous comments were a lot more on-topic than your meta-discussion (discussion about discussions).
Of the many VS Code users I've spoken to, both in professional and personal settings, none were aware that VS Code is closed-source software. In fact, many Discord users I talked to (hundreds), were under the impression that it is free and open-source software (FOSS). It was important for me to speak out about this misunderstanding in plain and honest language.
Trying to personally attack ("you're not an engineer") is actually the thing that makes open source look unprofessional. Not harsh language itself. You're correct, I am not. I work as a developer, as you can read from my profile, and I honestly don't have compassion for brittle, company, code. and yes, grown-ups sometimes cuss. I apologize.
who's the weirdo now? certainly not the FOSS group.
@junaga please stop, you're only being a nuisance. Whenever you make a comment, everyone who is subscribed or has commented will get a notification. A feature request about ligatures in a terminal is not the right place for this kind of thing.
You were warned before about the code of conduct. If you keep going I'll either block you from the repo or lock this issue, the latter of which I really don't want to do as it disables voting.
https://www.unicode.org/L2/L2023/23107-terminal-suppt.pdf TCSS (Terminal Complex Script Support)
We find that a standardized specification for how to handle text in terminals is important work for the modern community of developers, and all other people that use text terminals.
Fonts that meet these requirements, referred to as “terminal fonts”, will work properly with the layout algorithm defined in the specification.
Looks like the issue will be fixed upstream. Couldn't the mentioned algorithm be re-used, but with queries against the font instead? I mean, it would have to be implemented in the terminal emulator either way.
@junaga the terminal renderers work by splitting up the rendering of the characters. The ligatures addon in xterm.js is implemented by joining sets of characters such that they are rendered together: https://github.com/xtermjs/xterm.js/tree/master/addons/xterm-addon-ligatures
So yes, but this is already done. We're just stuck on a packaging issue as mentioned in the last update: https://github.com/microsoft/vscode/issues/34103#issuecomment-1331018529
@junaga the terminal renderers work by splitting up the rendering of the characters. The ligatures addon in xterm.js is implemented by joining sets of characters such that they are rendered together: https://github.com/xtermjs/xterm.js/tree/master/addons/xterm-addon-ligatures
So yes, but this is already done. We're just stuck on a packaging issue as mentioned in the last update: #34103 (comment)
The mentioned PR is closed but this issue is still open - any idea what the current state is?
so this is still an open issue ? Is there a specific reason why ?
Regresses with performance improvements in terminal's renderer https://github.com/Microsoft/vscode/pull/33954