Very grateful that this was disabled at least for now. It is a relief to be able to write edit notes without fighting the software. We take simple things that work for granted, and I would be remiss if I didn't say thanks for making the software functional, simply, again.

Again would you please just remove the counter. You can fix it offline. Thanks.

Yes I posted here since this appears to be where this was agreed to. Aklapper the problems with this counter are obvious and explained at depth at the phab thread just linked and at VPT.

Please roll this back. It breaks a basic function. I was unaware this was being considered and this is a perhaps-nice-to-have-gadget but not necessary. If re-implemented it should be an opt-in and not default. In my view this counter is clutter: I would never turn it on.

Am using chrome Version 59.0.3071.115 (Official Build) (64-bit) on a Mac. In addition to what is described above, when the content does starts disappearing behind the counter , if I try to delete and start typing again, the text is oddly repeated.

I just want to say that I fully support this. Related discussions that are kind of more about how search results are presented... here and links to phabs therein, namely T156493 and T23139 T40403 . Having the advanced search parameters contemplated here might be helpful towards wasting less time!

In T40403#2981446, @TheDJ wrote:

@Jytdog i want to clarify a few things here if you don't mind.

Polarised starting points to simplify the next discussion:
1: Developers don't understand the editing process
2: Editors don't understand the intricacies of our technology stack

What you see in the discussion above (and what you describe) is an assortment of desires and wishes (usecases) mixed with technology solutions chosen by editors and developers. This caused a logical response by developers, of evaluating these two, and developers telling editors: 'the solution you picked is not actually solving your problem'. Consequently, developers either have ignored the original usecases, or come up with alternative solutions, which have proven to be prohibitive as well for a multitude of reasons (at this point in time).

A short summary:
1: Yes, having sort filters on the results would be very nice
2: Implementing sort filters (both backend and in UI) is going to be costly.
3: As such, priorities will have to be set. By asking to show usecases that can be met, developers (and managers in this case) try to ascertain if these costs will be offset by potential gain/benefits.
4: Editors present several usecases, but the usecases don't match the technical solution detailed in this ticket. (at least not in an effective way)
5: Inertia sets in, and frustration builds.

Your own use case is a perfect example: Talk archives.
1: We only index the contents of the current version of a page (to index everything would be an increase of 21x of the current infrastructure, which would likely also add some logarithmic increase in complexity of the overall process and technology). This is expensive and still several years out (We are NOT a search company, anything we have will be some 10-15 years behind in what Google is able to do).
2: As such any notion of date and 'recent' is only as recent as the last edit to a page
3: Talk archives are edited all the time (and thus their recent indicator that we currently have isn't useful to determine their age).
4: So while your use case is valid, the chosen technical solution detailed in this ticket probably won't help you solve this particular problem in any foreseeable timeframe.

Volunteer time is the lifeblood of Wikipedia and the search engine wastes it.

I think we all agree on that volunteer time is valuable. But that doesn't negate the cost of a potential solution.

I have always thought it would be amazing if there is was a way to get the diff underlying a comment in an archive by right clicking or something. I imagine that is impossible, but wanted to note that.

That would be amazing, but also non-trivial since a comment can be made up of multiple diffs, pages can be copy pasted and moved etc etc.. There are some tools like wikiblame, which do this to some degree, but to roll those out more widely is probably not realistic at this time. But it has nothing to do with this ticket.

I think the general answer to this is still: You need structured discussions if you want to do that (aka, something based on similar principals as LQT/Flow).

But I can't imagine how daunting and off-putting the process of finding and linking to, or getting diffs for, archived comments is, for new editors who are interested in joining the community. I reckon this is one reason why new editors so often fail to successfully raise issues on behaviour noticeboards, where diffs are essential, and complain that community noticeboards are byzantine.

I think developers and editors alike agree that our discussion system is not targeted at including newcomers. But again, that has little to do with this particular ticket.

One of the problems that I often see in discussion tickets like these, are the mixing of usecases (desires) and technical solutions (abilities/possibilities) within the same ticket. I personally think it would be much better to have usecases and technical solutions in separate tickets with these larger problems, for the sole reason that otherwise you get this back-and-forth between the two that is not constructive to solving problems (especially because the audiences are so different as well).

Regardless, I think that @MZMcBride's summary is really clear and correct (because he understands enough about both sides of the problems, to know what to exclude from his statement). We have 'recentism/last edited' information, we have the technology to order by that parameter, we have an advanced tab in the UI, so it should be possible to expose this information. And that is actually exactly what the german team is considering to be working on: T143310: Implement a way to access keywords such as "incategory", "intitle" via the Search special page and T154911: Redesign the special:search page (Session). But in the strictest sense, that is a just a subset of the request that this ticket started with and the usecases mentioned within it, which likely would require indexing the entire history of each and every page.

In order to solve YOUR problem, with the current technology, we should probably look into the direction of: "Is there some way, that we can special case a subset of Talk pages in the searchengine, to become more discoverable and useful to editors trying to find older discussion, without blowing up our current search solution". I'm thinking like a way to put a special parser key or something on an archive page/template (as we do for disambiguation pages), like for instance {{#TALKARCHIVE|index|date-range}}. But that would be a totally different ticket, because it's not directly related to this particular technical solution that this ticket deals with. I welcome anyone to create more tickets :)

I recently opened at thread on this at Village Pump technical. I have over 100K edits in en-wiki since 2008.