This post implies that timeline-plaintext should be the default, again, but I think there's some incompatible changes how links with descriptions are displayed in the CLI timeline. It seems it's no longer possible to see the link target in the CLI timeline, only the description.

As I'm working mostly with the CLI timeline, this indeed seems not very handy, as it's no longer possible to copy hyperlinks from the terminal.

BTW: This seems to work fine in the web UI, where timeline-plaintext=1 shows the description and target of hyperlinks.

I hope we can get this back for the CLI, too.

Thanks for the fix!

As of this check-in, the help for commit says:

Commit message text is interpreted as fossil-wiki format.

This is not correct: it depends on the timeline-plaintext setting, and maybe others. Should this be reverted?

In the same commit, I noticed that the help text for the --branchcolor and --bgcolor options was changed to discourage their use, and later removed entirely.

That's the stuff I'm using almost daily! And I always forget the spelling, and whether --bgcolor is for branches or for the current check-in only.

Apart from causing inconveniences, I still don't think it's a good idea to hide features from users. If Fossil removes support for the bgcolor tag, then the help text for the options to set it could go away, but otherwise I think it should be kept to avoid confusion.

Especially with regard to recent help command enhancements, I think a complex system becomes even more complex if it's incompletely documented.

Any chance this can be restored?

As of this check-in, the help for commit says:

Commit message text is interpreted as fossil-wiki format.

This is not correct: it depends on the timeline-plaintext setting, and maybe others. Should this be reverted?

You are talking about this checkin? I asked for it, because I saw people using formatted commit-messages and didn't figure out how, because the help didn't say anything. All the cool features stay unused if nobody learns about them. Maybe the text could be amended, but I think the help should have a notice to help people use that feature.

You are talking about this checkin?

Yes, I'm sorry I messed up the links in my post.

I think it's okay to give a hint about the format. But the current version is incorrect.

In the same commit, I noticed that the help text for the --branchcolor and --bgcolor options was changed to discourage their use, and later removed entirely.

bgcolor and branchcolor have been discouraged since fossil got skin support (well more than 10 years ago), as it's impossible to hard-code color values which are legible with arbitrary skins. Removing them from the help text simply formalizes that discouragement.

Removing them from the help text simply formalizes that discouragement.

So did adding the help text hint that they're discouraged, without making it more complicated for people relying on the feature to look it up. So I don't agree this is the right way to deprecate well-established features.

.. people relying on the feature ...

It's not a "feature", it's a "misfeature". It was a bad idea. It was a mistake. I regret adding it to the code in the first place. I have since learned that it works far better to let Fossil choose its own colors, automatically.

If you insist on choosing colors yourself, then that's on you. You can do what you want on your own repositories. But I do not want to lure newbies into thinking choosing their own colors is a good idea. So we won't be advertising the --bgcolor and --branchcolor options. I grudgingly accept that they exist, but they do not belong in the help-text.

It's especially handy to say --bgcolor="red" for a commit with a bug, or --bgcolor="green" for a release.

Handy for you, maybe. But then somebody else comes along and wants to view your work using a different skin or with --darkmode, and then they can't read it at all.

If you can come up with an algorithm that translates a hard-coded color (ex: #ff0000) into some alternative color appropriate for the current skin, that would be terrific. Please share your work. Then maybe we can translate the (usually garish) colors chosen by the average user into something more pleasing, and resurrect the --bgcolor and --branchcolor options.

Ok, I'll share my work and new ideas here.

I'm somewhat busy, at the moment, but as soon as I can get to it, I'll start a new thread.

Just noting another idea:

Calling window.getComputedStyle(<element>).backgroundColor returns "rgb(255, 0, 0)" even if the original style assigned by CSS was "red", "#ff0000" or "#f00", so maybe that's a (client-side) way to get a normalized form of ANY user-specified color, then apply some (HSL?) formula to lighten or darken it, depending on what's suitable for the current skin.

come up with an algorithm

Terminal themes take the 8 colors in 2 brightness levels defined by ANSI X3.64 and redefine them to work with the background color. The program emits the color code for “bright red” but the user sees “pinkish-mauve.”

So now on trunk, there is a new routine that filters user-requested background colors to try to make them less ghastly. Notes:

• There is test page: /test-bgcolor.

• There are probably some uses of user-requested background colors that I have not yet filtered out.

• It just occurred to me that there should probably be a new setting to disable the color-filter, as I'm sure there are some users out there who prefer their to have their background color requests fulfilled exactly as written, however heinous those requests may be. But the color-filter needs to be on by default. If you want ugly colors, you first have to search out and turn on the ugly-color setting.

The TCL devs often pick their own background colors. I have not yet updated the main TCL server on core.tcl-lang.org. But I have updated the server running this forum, which also serves mirror1.tcl.tk. Behold the difference:

• https://core.tcl-lang.org/tcl/timeline?ymd=20250306

• https://mirror1.tcl.tk/tcl/timeline?ymd=20250306

Behold the difference:

Add &skin=darkmode to those to see an even starker improvement.

Big improvement in both the light and dark themes, well done!

I'd pitch in the opinion to hold off on the color-filter setting. There's a pretty good balance in the new feature, providing a requested feature, but holding back from totally shooting yourself in the foot. (I suppose you could set every branch to the same color, but that'd be a you problem. 😀)

I'd pitch in the opinion to hold off on the color-filter setting.

FWIW, 100% agreed.

Experience suggests that we'll eventually get a request from someone who wants their exact colors, but as George Clooney's character so elegantly put it in Dusk 'til Dawn:

It's not a problem until you make it a problem.

Wow, super cool! Thank you!

Another test page:

• https://fossil-scm.org/home/brlist?colors=on&skin=default
• https://fossil-scm.org/home/brlist?colors=on&skin=darkmode

I haven't studied your solution, yet, but it looks really nice. I haven't checked all the details, for example, whether the color of the rails is also adjusted, or whether this is not necessary.

And, from some quick tests on the new /test-bgcolor page, it seems only "long forms" (#RRGGBB) of colors are handled, but not "short forms" (#RGB), maybe this could be added.

And I was also thinking of adding a table to convert named HTML colors to RGB to allow fixing these, as well.

My approach with transparent background colors is alpha-blending the branch color against the background color, as summarized here.