BTW: for quick testing on the repolist I called (repositories being the directory with my fossil repos):

FOSSIL_REPOLIST_SHOW=description FOSSIL_REPOLIST_QUICKFILTER=on fossil serve --repolist repositories

Might come in handy for others that want to test it. At least if you use Unix, this call probably is different on Windows.

Wanna bump the thread to give people a chance to voice their opinion if they want this included into trunk or not.

Usually, you'd have to wait for the project lead to merge the feature.

But you already have the okay of Richard and his deputy Stephan, so you can merge it, yourself.

(Richard doesn't like new environment variables, so maybe he will add a note whether it's better to integrate FOSSIL_REPOLIST_QUICKFILTER into FOSSIL_REPOLIST_SHOW, but this can still be changed later on trunk, if necessary.)

Actually, I was told that the preference is to everyone merging themself, after they got confirmation (or at least no objections) by the community, and the project lead vetos if so inclined. But maybe I misunderstood?

A favorable mention is not in my opinion a vote for inclusion. Especially on an earlier version vs. the current state.

About the env-variable: As I wrote I thought about it, but felt that FOSSIL_REPOLIST_SHOW has a focus on columns so far. Changing it later on trunk can be problematic though, as users might already rely on the functionality (breaking compatibility with a random branch is IMHO more acceptable than the trunk which is kinda official). So using the proper env-variable name at time of inclusion in trunk might be good. Has anyone opinions on it? Maybe, to address my concern of mixing columns and other features make a variable FOSSIL_REPOLIST_FEATURES that can have a list of values including quickfilter? Or is it better to mix it all in FOSSIL_REPOLIST_SHOW?

Actually, I was told that the preference is to everyone merging themself, after they got confirmation (or at least no objections) by the community, and the project lead vetos if so inclined.

By and large we like to see people merge their own stuff (if for no other reason that it attributes that person, instead of the merger, in certain views). This particular topic has been discussed at length in /chat and i don't recall seeing (nor have) any objections to it.

About the env-variable ... Has anyone opinions on it?

FWIW, repolist isn't something i use, so i have no preference.

I'm not sure I understand. I guess something changed since I last built/used this branch, or is it due to my not using CGI?

I can be kind of picky regarding language & phrasing, so I'm ready to help. :-)

So far, in my use, I don't keep all my repos in the same place. Some are available through one address to nginx, a bunch of others are available via another address, and still others are only available through localhost.

There was a short time when the repo's description was part of the repo list (table) and I wasn't a big fan of that; too much extraneous text on a webpage with more than a handful of repos.

But that seemed extraneous to your quickfilter functionality so I never considered them part of the same patch.

Dear Jörgen, I like your work on this client-side filtering of table rows. I have no objections to it, I'm ready for you to merge it.

I cloned the tcl & tk repos since I have an outdated version and when I build fossil it lets me know. I've yet to build it all to (try to) replace what I have, but in poking around the repos with your quickfilter branch it seemed obvious how helpful it is on a tk ticket report page. (They have lots of tickets.)

Sorry for my absence, I had other stuff to look after. And thanks for the support.

But I considered and still consider the proposal rejected. Because when I asked only florian did answer really, and he is opposed to the proposal. Now with you it is 1vs1, but still I would consider that too controversial. So quickfilter is not coming, sorry. And yeah, a lot of tickets is the use case I had in mind.

I don't have the power to block a feature! But I do have the ability to discourage people with negative feedback, and in your case, I'm afraid I was unfortunately successful, which I regret!

Remember that you still have the GO from Richard and Stephan!

G'day,

Apologies for a longer absence, but FWIW I think the whole quickfilter is useful and will continue using it for our project. I'll check with a few of the users and report but it has all been positive so far from the user perspective.

Ta

For clarification: drh has made a decision: "I am not convinced that quickfilter adds sufficient value (over say just pressing Ctrl-F in your browser) to justify the added complexity of maintaining it for the next 25 years. It is important to not underestimate the cost of long-term maintenance."

So quickfilter will not be added. Thanks for all the feedback, I think I learned quite a few things in while doing it.