I like using syntax highlighting when it breaks. For example, if all code below a particular line is a single color, then I probably forgot an end-quote or something. But this has become less uniquely useful due to the broader integration of parser-driven linters (e.g. tree-sitter), which—besides being able to drive highlighting—can explicitly deliver inline hints or parsing errors.
All that said, I'm one who appreciates information density! How about coloring branching code paths/call stacks?
My keyboard has a concept of "layers," which allows each key to map differently depending on the layer. I've seen this used to make a numpad or to have a QWERTY and DVORAK layer. What if highlighting was the same? Instead of competing for priority over the color channels, developers could explicitly swap layers?
Great point! Similarly, I sometimes use Emacs' excellent (and near-unique) electric-indent as a hint of syntax brokenness. "What do you mean this is getting indented at that lev-- oooh"
The downside with broken syntax highlighting (and electric-indent!) is when the editor's parser is insufficient, as is often the case with basic online editors, and breaks with legitimate constructs (Emacs with certain C macros). Then I can't trust the highlighter and also I have less-legible code.
I got so used to electric-indent and the immediate feedback it gives, that for a very long time it prevented me from even considering any other editors.
These days I rely on clangd driven autoindent (which is fast enough to do every line), but I still use emacs because it is so easy to tweak the interaction to clangd to work exactly as I prefer.
> All that said, I'm one who appreciates information density! How about coloring branching code paths/call stacks?
>
> My keyboard has a concept of "layers," which allows each key to map differently depending on the layer. I've seen this used to make a numpad or to have a QWERTY and DVORAK layer. What if highlighting was the same? Instead of competing for priority over the color channels, developers could explicitly swap layers?
I was thinking about coloring logic /scope blocks as a way to help visualize scope and flow, even if it required static analysis and a simple script it could be useful when I need to debug
If we isolate this from the recent controversy: in general, is an alternative (yet mostly compatible) package source, package manager, and/or language version manager neutral, good, or bad for an open source ecosystem?
Not OP, but I think OP is looking for dates, as in a year, month, day, situation—not only version numbers. I think they want to know what specific date 3.23 will be released with this change.
They didn't understand the version numbers (notice they were complaining that the blog post jumped the gun because there is no merge-usr in 3.22) and wanted dates. I explained the version numbers to them. Yes, there are no dates; Alpine never gives expected dates for future releases because nobody knows what they are.
I think I understand where there was confusion. I only commented because, as of my reading of the comments, OP clarified they were looking for a date, and your reply repeated version numbers. Perhaps they were originally asking for clarification of the version number (though I don't believe they were, based on the original comment, as written now), but their reply specifically referenced there being no dates. Perhaps they do not know that Alpine does not provide dates? Your reply suggests you might have misinterpreted that.
To OP: this announcement from Alpine doesn't contain dates, like you've mentioned. This is apparently not an accident.
I totally understand the version release methods. Ive been using Alpine as long as it has existed. Ive installed it manually and automated to thousands of nodes. This is however a breaking and major change so I would expect an actual timeline of when people can test it and when it will be mandatory using dates. I believe this is a reasonable ask.
I feel the same. I can't quite tell where this fits in, in a production context.
I suppose the value proposition might be that it's all built-in, meaning there's no events to publish over the network nor any OTEL collectors to deploy. This is just a file on the host that you can read and use go's built-in trace tool to examine. In that way, I guess it's simply like any log file, but enriched with trace data and configured to only contain only the traces you're interested in.
Single-use plastic bags, while a substantial source of litter, have a surprisingly small carbon footprint due to their manufacturing process, light weight and inert material not releasing methane into the environment.
A 2018 study by the Ministry of Environment and Food in Denmark suggests that an organic cotton tote needs to be used 20,000 times to offset its overall environmental impact of production.
I think that most Rubyists want to forgive each other and move forward. The board, staff, and volunteers at Ruby Central are all people and people are fallible, that's fine. The way to receive forgiveness isn't to convince others (who weren't there and who don't have the full context) that what was done was reasonable or justified. It doesn't matter. It doesn't even matter who is at fault. What matters is who will take responsibility.
The actions taken by people in service of Ruby Central have had unintended consequences, including damaging the community's trust in Ruby Central's stewardship.
A new governance model will solve only the problem of there not being a governance model. There also has to be an acknowledgment that the lack of an existing appropriate governance model wasn't just a "fiduciary failure," but a failure which cased harm to the community and contributors. Contributors who—like the board—are volunteers, and would have probably liked to have their significant dedication shown more respect.
You show respect to someone by giving them important information from which they can use to make their own decisions. As opposed to withholding information because you are uncomfortable with the possibility that they may make a decision you don't want them to.
All that said, I'm one who appreciates information density! How about coloring branching code paths/call stacks?
My keyboard has a concept of "layers," which allows each key to map differently depending on the layer. I've seen this used to make a numpad or to have a QWERTY and DVORAK layer. What if highlighting was the same? Instead of competing for priority over the color channels, developers could explicitly swap layers?