I worked on a feature I called quickfilter. With this thread I ask if the community deems the feature fit for inclusion in trunk.

This feature is an input-field on the pages repolist and the ticket report, that you can type in a search term. As you are typing the list on the page is filtered with your search term, showing only matching items and highlighting the found text.

This is implemented with Javascript. So it only works with JS enabled (although I made the input-field invisible for non-JS users as graceful fallback). Also it makes no Ajax-calls, therefore the list can only filtered by information visible on the page.

A previous forum-thread helped me guide the development with the feedback - thank you for everyone participating. But I think it is time to ask for inclusion on trunk, and to keep the discussion focused I decided to make this new forum thread.

The feature has to be enabled. The ticket reports have a new checkbox in the forms for creating a new report or for editing one. Checking the box enables the quickfilter for that ticket report. For the repository list you need to set the environment variable, in a CGI-Script by using the line:

setenv: FOSSIL_REPOLIST_QUICKFILTER on

As a note: I decided to have an own environment variable and not add it to FOSSIL_REPOLIST_SHOW. That is because FOSSIL_REPOLIST_SHOW so far only enables columns for the list. Adding something outside columns might be confusing, especially if in the future additional columns could be added to the listing.

This feature adds some clutter for instance in options (as just pointed out for enabling it) and adds Javascript. But I think the usefulness outweighs the clutter. This is my personal opinion though, so please weigh in with your own view on it.

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.

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.