There is so little difference, I can't imagine the purpose of this.

Sorry, please do me a favour and try it once.
The screen layout is much clearer, and faster.

The difference is explained in my report and fully took into account your
comments (that the NUMBER wasn't shown, as mentioned by you). Have you ever user
UseMod ? It is incredible faster in RC views.

The other difference is already in 756: no more listings of older changes in
sections for past days (for a certain page), if that page was already listed on
a more recent day.

For test purposes, I recommend that you apply my tiny patch as listed in
http://bugzilla.wikipedia.org/show_bug.cgi?id=756 and measure the time of
getting the data. And the screen layout is much clearer ! Even when you have
"Enhanced RC View" enabled - because the patch skips the second (and so on)
older recent changes. I admit, that all skipped data should be then in the first
(folded) view, but this can be implemented as mentioned in this bugzilla.

Why exactly don't you want such a UseMod-Style view as a third alternative,
there are no more lurking.

Brion, you have invested time to remove my code for RCUseModStyle, even when it
could be disabled fully by a "master" setting for the Sysop in
DefaultSettings.php and an accompanying user option (which is only shown, when
the Sysop setting allowed this).

However, I know of many users test installations who like that code and the
possibility to select one or the other view preference.

I deeply wish to re-request the implementation of RCUSeModSytle, as it gives
much clearer RC views:

when only one (the last) change of a page is shown.

Admittedly, not everyone will like that, but think (please) of the other users,
who do.

In my opinion, there was not any impact on performance when the "master"
settings disabled that feature, because the only change was a tiny conditional
addition to the select statement - so no performance drawback. It seems to me,
that we both are of a diverging opinion, so I kindly ask you to talk about this
patch, which I pray to have, in Berlin.

It can be used with or without the enhanced RC view.

Added a screenshot of RCUseModStyle view of Recent Changes (remember what it
does: it only shows the most recent change (one entry) of a page - any user has
an option to opt-out from this, so that s/he get the full view: any change of a
page).

I personally do prefer th RCUseModStyle and will give convincing arguments (i.e.
"fight") to have this option in 1.5 . Let me know your opinion. I admit, that
any single change might need to be patrolled; but some more reluctant users do
not need to see any single change of a page. This is, where my proposed patch
helps, as it suppresses "older" changes than the recent one), Brion has already
said. that he do not see an advantage, but I am of a diverging opinion.

How does the community of developers deal with such a problem ?

Created attachment 197
missing codelets for the patch

Brion,

I upload here the diff (Diff between the current CVS as of 04.01.2005, 20:26
UTC) which reestablishes the UseModStyle View. I really would like to suggest
to have this in the CVS 1.5.

My patch makes it a "UPO" (user preference option) when a Sysop has decided to
allow UseModStyle View (switch $wgRCUseModStyle in DefaultSettings.php =
true;), so any user can opt-in or opt-out.

Later (to do):

I will modify it according to what we have discussed in Berlin (to show the
number of versions) OR to modify the enhanced recent changes view, so that all
changes of a certain page are mapped to the one (most recent change) entry.

Attached:

Remark: the texts are already (still) in Language.php (see rcusemodstyle and tog-rcusemod ).

Brion:

please can you fix the missing things - see patch - to re-enable my
Pseudo-Usemod style for the recent changes view ?

As discussed with you in December in Berlin, this step of you would enable me to
resume my work towards the display of the real number of changes coming with the
one only entry of a changed page (in RC view).

At the moment, as you know, the enhanced RC view (w/ or w/o $wgUseModStyle=true)
still shows a changed page on every day when it was changed. Exactly this
problem needs to be overcome, so that all instances are put into the folded view
on the last recent change entry of a certain page, if a user opted for enhanced
RC view or UseMod-style.

For the other readers: with UseModStyle it is meant, that the wiki software
first creates and sends only the information about the (one) recent change of a
page, rather than sending all change information falling into the selected
interval (e.g. 500 changes in last 7 days). This saves transmission bandwidth;
users, who wish to patrol can still click onto (diff) and (hist) links to get
the missing data or simply to permanently opt-out from the UseMod-style ... ...
... Brion has stated in 2004 to be against this UseMod-style, but I am in favour
of having this and I programmed it as option (= Sysop option and user option in
preferences). A preview can be seen on screenshots on my
http://meta.wikipedia.org/Enotif [sic] pages. What else can I do than to ask it
again and again, this is a very difficult situation and I can only pray again to
let me fully implement this in CVS and THEN to see the developers' opinion.

Tom, why don't you go ahead and make the fix to enhanced recent changes mode and post a patch for that? As I
understood it, this was what we agreed to in December.

(In reply to comment #8)

Tom, why don't you go ahead and make the fix to enhanced recent changes mode

and post a patch for that? As I

understood it, this was what we agreed to in December.

Because I need your commitment to my idea, not a butchering of it and lengthy
discussions about a feature which can be disabled by sysop and user options. I
hardly saw a commitment of developers to my several hundreds of hours program
efforts, which makes me more and more reluctant to do anything more. (I am *not*
saying, that I resign)

Why don't you re-enable what I have programmed first, than fine-tuning is easy
business for me and everyone can help to improve the code again. This would show
me your commitment.

What we discussed is a specific change to the behavior of enhanced recent changes, which is
in no way dependent on the patch attached to this bug. This patch is for the old hack you
submitted, which as you agreed during our discussion would be unnecessary if the agreed-
upon change to enhanced recent changes was made.

(In reply to comment #10)

What we discussed is a specific change to the behavior of enhanced recent

changes, which is

in no way dependent on the patch attached to this bug. This patch is for the

old hack you

submitted, which as you agreed during our discussion would be unnecessary if

the agreed-

upon change to enhanced recent changes was made.

If there is a commitment lurking, I can barely see it.

Brion:

so the only thing which you miss from my patch as attached is the display and
link to the number of available changes (of a certain page in RC view) in the
wiki history - am I right ?

Please can you confirm this to avoid an only potential misunderstanding.
Tom

In Berlin you suggested, and I agreed, that the enhanced recent changes mode
should sort all changes for a page under its most recent edit instead of splitting
them across days. You represented that this would be a sufficient change for
your requirements, and I agreed it would be acceptable and would be accepted.

This patch does not cause enhanced recent changes display to sort all changes
to a given page under its most recent change instead of splitting them across
days. This patch just adds another user option (to a sea of user options which
should not be increased lightly) which ignores everything but the most recent
edit.

The patch attached to this bug will not help to perform the change that you
suggested and we agreed on, so I don't see why you would ask now for it to be
committed.

I renamed my bugzilla title to better reflect the current implementation of it
in Enotif 3.x for MediaWiki REL1_4 (1.4.1/pre-1.4.2) as published
http://bugzilla.wikipedia.org/show_bug.cgi?id=454 .

The function can be configured by sysops, i.e.totally disabled or enabled.

In the latter case, the user gets a new option in user preferences and can
decide at her discretion to enable or disable the

• suppressed view: to list only the current revision of any changed page, or

• standard view (standard): to list every single page revision in recent changes view.

Oops, here we have a real clash between Brion and me.

It is *implemented* as a user option(!) in ENotif/EConfirm v3.16, see
http://bugzilla.wikipedia.org/show_bug.cgi?id=454 and sysops can fully disable it.

So Brion: be relaxed and make a concession

I cannot say, whether this will be implemented in public release version or not,
but I fully support it.

Solution for MediaWiki 1.15+ using a hook:

// see http://www.mediawiki.org/wiki/Manual:Hooks/SpecialRecentChangesQuery
function onlyRecentRecentChanges( &$conds, &$tables, &$join_conds, $opts, &$query_options = array() ) {
$tables[] = 'page';
$conds[] = 'rc_this_oldid=page_latest';

return true;

}
$wgHooks['SpecialRecentChangesQuery'][] = 'onlyRecentRecentChanges';