Big fan of all of this except for the emojis in my console
It should be easy to patch out or possibly add a command line switch to disable it if desired.
Usability Improvements in GCC 15
61–70 of 231 posts
Re: Usability Improvements in GCC 15
#62Earlier quoted context omitted.
Well, other than the fact that it's hard to search for, things should be kept as simple as possible to improve reliability/interoperability. Are you confident that multi-column-wide non-ASCII characters work reliably without causing rendering issues on every possible combination of terminal/shell/OS, including over SSH? I'm certainly not.
You can already put multi-column-wide non-ASCII characters in your source code, so the horse has left the barn already.
Of course you can. I'd argue you shouldn't, but that's beside the point. There is clearly a difference between people being able to do something, and the compiler forcing it on them.
Re: Usability Improvements in GCC 15
#63Earlier quoted context omitted.
Why?
Well, other than the fact that it's hard to search for, things should be kept as simple as possible to improve reliability/interoperability. Are you confident that multi-column-wide non-ASCII characters work reliably without causing rendering issues on every possible combination of terminal/shell/OS, including over SSH? I'm certainly not.
If anything, an emoji is easier to search for, as less things would be using it than a general "warning" (or whatever would make sense, as the emoji'd thing isn't the warning itself). Do have to get a copy from somewhere to search for though. It's also much easier to "visually" search for it.
At least in the blog there are a two spaces after the emoji so it can freely draw past its boundaries rightwards without colliding with anything for a good bit; and nothing to its right is used assuming monospace alignment. So at worst you just get a half-emoji.
Re: Usability Improvements in GCC 15
#64What is the status of GCC plugins?
Re: Usability Improvements in GCC 15
#65Usability improvement request for this article: don't hijack the browser back button :P
Not an issue with JS disabled ;)
Re: Usability Improvements in GCC 15
#66Earlier quoted context omitted.
It's already egregious when a site adds history pushState entries for just clicking through a gallery or something, but wow adding them just for scrolling down on a page is simply bizarre, especially on a page about usability.
It's in the spirit of adding emojis to compiler output...
I actually quite like the emojis they put in the output, it helps alleviate the balance of providing enough context while also giving a clear visual indicator for the actual error message.
They aren't going overboard on it, they just put a warning emoji in front of the error message.
Re: Usability Improvements in GCC 15
#67Earlier quoted context omitted.
Alternatively, if you join a Stallman-led Free Software project and hope he'll accept your ideas for making life easier for proprietary vendors, you're gonna have a bad time. I mean, the GNU Emacs FAQ for MS Windows ( https://www.gnu.org/software/emacs/manual/html_mono/efaq-w32... ) says: > It is not our goal to “help Windows users” by making text editing on Windows more convenient. We aim to replace proprietary soft…
I mean, I think he is right. If everyone stopped supporting Windows, it would have long died out in favor of easy-to-install Linux distributions... probably.
[deleted]
Re: Usability Improvements in GCC 15
#68Usability improvement request for this article: don't hijack the browser back button :P
Browser makers should straight up remove the JS API for interacting with history. There are legitimate uses for it, but the malicious actors far outweigh the good ones at this point. Just remove it.
Re: Usability Improvements in GCC 15
#69Earlier quoted context omitted.
Embedded compiler vendors and UNIXes want a possibly slightly patched C or C++ compiler, maybe with an extra back-end bolted on. I'm talking about use-cases like Rust and Zig and Swift, projects which want a solid optimizing back-end but their own front-end and tooling.
gccrs is a rust implementation for gcc. Just because Rust developers don't want their users to be fully free doesn't mean there are any problems with gcc. And clang is developed by Apple which is a huge warning sign by itself.
Rust developers don't "not want their users to be fully free", they disagree with you on which license is best. Don't deliberately phrase people's motivations in an uncharitable way, it's obnoxious as hell.
Re: Usability Improvements in GCC 15
#70With GCC error messages usually the only part I wanna see is "required from here" and yet it spams zillions of "note: ...". With the nesting enabled, it's way easier to read --- just look at the top indentation level. Hooray!!!