johncoltrane

When will that "dashboard with tacked-on tablets" trend stop?

It can somehow be excused in cheap models because new versions are generally incremental evolutions, which would make proper integration of the touchscreen harder/more expensive. But not in a brand new model of a luxury brand.

That would be a third track since the current Web is already (at least) "two-track": humans and search engines.

The world goes on.

A bunch of William Gibsons.

Philip K. Dick's Ubik, A Scanner Darkly, and Flow My Tears, The Policeman Said.

Clifford D. Simak's City.

Classics.

I was 11 when I started roleplaying with gamebooks. I vaguely remember L'œil Noir as a classic among "Livres dont vous êtes le héros". The same year I saw the older kids play a full D&D campaign with the adults during summer camp. In the following months Casus Belli and Jeux & Strategies, two magazines dedicated to RPGs, gradually replaced comics… and we eventually put together an "official" club at our middle school, where we played D&D for a while, and more games as we discovered them: MEGA II, Paranoia, Rêve de dragons, le JRTM, Call of Cthulu, Zone, etc.

Fond memories of Laelith ;-).

Not sure what's the most surprising to me. That an attack on ANTS happened or that the Entrevue rag still exists. Also, for what it's worth: https://ants.gouv.fr/toute-l-actualite/communication-sur-la-...

> Do you separate the product from the founder?

Yes… if the founder does. I don't care on which side of which ring they are as long as they keep me out of their pointless fights.

FWIW, you don't have to do any of that to enter China.

The problem is that compositors typically don't have the notion of 3D scene.

It's all just a stack of layers, one window per layer. There is no shadow to speak of, only a mask around the window that provides the illusion of shadow. So there is no real interaction between all those items, no source of light, no distance, and no way to do ray tracing or some other techniques.

They add this black line when an important figure of tech dies. It is the HN equivalent of a black armband: https://en.wikipedia.org/wiki/Black_armband

Today, it's Tony Hoare: https://news.ycombinator.com/item?id=47324054

Assuming you already had a ~/.vimrc, the only non-defaults in that list are:

    :let no_man_maps=1
    :let loaded_matchparen = 1
    :set comments=""
    :set matchpairs=""
    :set paste

All the other lines set options to their default value, which is pointless.

The values for 'comments' and 'matchpairs' are incorrect, they should be:

    :set comments=
    :set matchpairs=

Enabling 'paste' by default is a very bad idea, with lots of side-effects.

Setting the following variable is useless if you don't enable the 'man' plugin, but maybe you do it manually during a session. I don't know. YMMV.

    :let no_man_maps=1

I didn't switch because there was no reason to. And there is still none.

Conspiracy theorists have that special ability to jump to the most implausible conclusions from the smallest amount of facts.

I tried to watch The Age Of Disclosure and, well… Everyone in it manages to stay relatively reasonable during the first fourth of the movie. Until they decide that the most likely explanation of all those unexplained phenomenons is a race of technologically advanced extraterrestrials hiding at the bottom of the ocean for thousands of years.

It went from "we don't know anything" to "it's threatening aquatic ETs" in a heartbeat. It was almost scary.

You can try what Apple calls "fast user switching", which is actually pretty fast. The last (and only) time I used it, my days were split half-and-half between two projects for two clients, each with its own infrastructure. I did that primarily to help me focus but it had one pretty cool perk that I've been missing ever since: isolated accounts meant that I never had to worry about which Git/$SAAS/whatever user was currently authenticated and managing keys and such was a breeze as there was no "managing" needed, really.

I could do it because I had _some_ level of control on my work machine. Now that I work for a much larger organisation… I can't even imagine how hard it would be to have such a setup.

I don't know how usable it is in practice if you are switching contexts every 10 minutes, though.

Good work!

FWIW, I use Chrome 145.0.7632.117 on a M1 MacBook Pro and I just got a notification suggesting me to "correct" the o'rer tab because it used too much resource. I was looking at the details of my Transilien station.

Also, looking a the same "details" popin, I see some irrelevant info when I click on the "alert sign" of a Transilien line (Line N in this case): something about bus stops.

I have a couple of questions about the API:

I've looked at the data provided by IDFM and SNCF a few times but I was never able to find a way to match a commercial train number, say "134671", to a physical train number, say "211L" or "Z50421/22" or the more complicated EVN. Did you, by any chance come upon such a thing?

Also, could you confirm that the only data available concerns _departure_ times?

Good luck.

Funny how they use the term "City of Darkness" a few times, without ever referring to the book "City of Darkness", by Greg Girard and Ian Lambot, from which most of the pictures in the article come.

Strongly recommended.

https://cityofdarkness.co.uk/

All text editors have always supported markdown, even before markdown even existed.

I prefer my background dark so light colorschemes are not really an area I've explored seriously. Also, dark colorschemes are much easier to design than light ones due to the disproportionate amount of light a white, say, background emits compared to the amount emitted by text. It dramatically reduces the number of colors you can use.

I have one here: https://github.com/romainl/vim-sweet16 but it is intentionally weird and essentially unmaintained.

Because it means making choices, breaking assumptions, etc.. They have made it user-customizable so they don't have to go through all that.

FWIW, the current de-facto standard is set by xterm. Here is a relevant excerpt of its source code:

    ! Disclaimer: there are no standard colors used in terminal emulation.
    !
    ! The choice for color4 and color12 is a tradeoff between contrast, depending
    ! on whether they are used for text or backgrounds.  Note that either color4 or
    ! color12 would be used for text, while only color4 would be used for a
    ! background.  These are treated specially, since the luminosity of blue is
    ! only about half that of red/green, and is typically not accounted for in the
    ! RGB scheme.
    !
    ! Blue text on a black background should be readable.
    ! Blue backgrounds should not be "too" bright.
    !
    ! Originally color4/color12 were set to the names blue3/blue
    !*VT100*color4: blue3
    !*VT100*color12: blue
    !
    ! They are from rgb.txt respectively:
    !  0   0 205  blue3
    !  0   0 255  blue
    ! However, blue3 is not readable on a black background.
    !
    ! Another choice was from the Debian settings:
    !*VT100*color4: DodgerBlue1
    !*VT100*color12: SteelBlue1
    !
    ! From rgb.txt:
    ! 30 144 255  DodgerBlue1
    ! 99 184 255  SteelBlue1
    !
    ! Some users object to this choice because the background (color4) is brighter
    ! than they are accustomed.  Others point out that the different weights for
    ! the red/green components make it appear to be not really blue.  Finally, it
    ! provides poor contrast against color13 and color14.
    !
    ! The current choice uses equal weights for red/green (effectively adding a
    ! gray to the result).  It is brighter than the original choice, and provides
    ! more contrast between color12 and color13, color14 than SteelBlue1 did.
    ! Contrast of color4 against black is slightly improved over the original.
    !
    ! Some refinement is certainly possible (you are welcome to try) -TD

Make that what you will :-).

My latest, "zaibatsu" is bundled with Vim.

- Apprentice, a low-contrast colorscheme I made years ago and used for a long time: https://github.com/romainl/Apprentice.

- Malotru, my curent colorscheme, more contrasted: https://github.com/romainl/vim-malotru.

- Dichromatic, for colorblind users: https://github.com/romainl/vim-dichromatic.

- Bruin, which only uses typography: https://git.sr.ht/~romainl/vim-bruin

No one can and people have been complaining about it for decades.

But there is no standard or standard body anywhere for terminal colors so there is no obvious way to improve this situation.

And no urgency either, because all terminal emulators allow users to customize the palette anyway.

I make Vim colorschemes so I'm fully in control of all those aspects. If I decide I want a given token in muted violet it is because I know that it will works well with the background… that I have defined myself.

The exact values of your 0-15 don't matter to me and they don't matter to you either, because you chose to use my 256c colorscheme to begin with.

No, because I don't develop programs. I make third-party Vim colorschemes that users install because they like the colors. There is no impending happening, here.

It has been working for decades and I would rather have it keep working for decades to come.

What would be optimal is semantic _styles_ (not colors):

- The developer marks the string "XXX" as an error message without even trying to style it.

- The platform/user agent/terminal/whatever displays the string in the default style for "error".

- The user can adjust the theme of their platform/user agent/terminal/whatever to fit their needs/wants.

I would really love to have that, too, on every "platform" I have to work on.

I don't want true colours. I want what I already have, 16-255, to stay reliable in the future.

First, I make third-party Vim colorschemes, not app. People install my colorschemes because they like the colors, not because I'm a monster with a gun pointed at their face. No one is harmed. No one is forced to do anything they don't want.

Outside of my text editor, where colors matter a lot to me for syntax highlighting, I'm definitely in the NO_COLORS camp (and in the NO_EMOJI camp, nowadays).

> Color usage in the terminal should be largely semantic, not stylistic.

I wholeheartedly agree but 0-15 sadly have zero inherent semantics, which is the single reason behind every terminal colors-related drama since forever: developer choses 9 to highlight an error message because it is generally a bright red by default --> user sets 9 to whatever makes sense to them --> error message is illegible.

I'm not an app developper. I make third-party colorschemes for Vim, which I assume are downloaded, installed, and used by people on their own volition, after they have looked at, and liked, the screenshots. Moreover, I take great care to make sure they are still usable in 16c, within reason.

Because all my work is based on 16-255, I can actually guarantee to my users that, given a properly configured terminal emulator, they will get the colors on the screenshots.

If I can't rely on 16-255 to be fixed anymore, then I won't be able to make any promise anymore. In practice, it just means adding a caveat in the README.md, but I'd prefer not to. Here's hoping this breaking change gets hidden behind a checkbox/flag.

Yes, I know that (see the venerable https://github.com/trapd00r/colorcoke, etc.) but those tricks are not used widely enough for them to be a concern. Using those tricks is also a deliberate choice so it is definitely on the user if my lovingly crafted 256c colorscheme is broken.

Having all terminal emulators run the equivalent of colorcoke without asking the user is not a very bright idea.

I have a bunch of Vim colorschemes under my belt.

0-15 are, as I said, a minefield because they are user-customizable: there is no guarantee whatsoever that my user's 1 will be the same dark-ish red as mine… or that it will be dark-ish… or that it will even be vaguely red-ish. It is actually somewhat fun to design colorschemes within those crazy constraints but oh well.

On the other side of the spectrum, truecolors is a nice idea in principle but support is still spotty and inconsistent. In theory, this gives me, the designer, full control over the colors used in the UI, which is a good thing for us and for my users. In fine, if I want my colorscheme to be usable by most users, then I can't blindly rely on this.

Which leaves me with 16-255, which are more widely supported than truecolors and, more importantly, dependable. They have problems, as mentioned in the article, but their _fixed_ nature gives me confidence that the background color of the status-line, for example, will look exactly the same -- and exactly how I want it to look -- in all my user's environments. Which, again, is good for my users and for me. Losing that confidence is what worries me, here.

Like you said, maybe 146 will still be a muted violet —— just not exactly the same -- but I'm not sure about this and I think that, at the minimum, this "feature" should be put behind a checkbox/flag.