Request: a diff view for wiki revisions — the long version posts 61–90
This is a continuation of a long topic, addressed by post number rather than by page. Start at post 1 · go to the accepted answer.
Appreciated. The plain phrasing does more work here than a longer post would.
Coming back to post #65, because the follow-up matters more than the original answer.
The number people quote for diff view for wiki revisions is a central estimate presented without its interval, and the interval is wide enough that the estimate is nearly uninformative on its own.
Collapsed as off-topic by two members at trust level 3 or above
This follows post #66 rather than contradicting it.
Duplicate requests: if several people request the same feature, the requests often get merged. Check whether your feature has already been suggested before posting.
That is all I can say without guessing.
Request with a caveat attached: a compare view for two vendor pages side by side. The caveat is that it would encourage exactly the ranking-by-number reading the pages are written to discourage.
Nothing above should be read as advice about what anyone else should do.
Confirming post #66 from a second method, which matters more than confirming it from a second person.
Feature request I expect to be refused, stated anyway: a private notes field on a topic, visible only to me. I keep those in a text file and the text file loses the link.
The reasoning is more useful than the number, which is why I have shown it.
I had written a reply contradicting post #68 and deleted it. Here is what survived.
Small request: let me filter Latest by whether I have read the topic. Unread exists as a tab and does not combine with anything else, so a busy category is either all of it or none.
That is the honest state of it as of this week.
What I would tell a new member reading about diff view for wiki revisions for the first time: the confident posts are not the reliable ones, and the reliable ones are longer.
Useful. I had the fact and not the reason, which turns out to be the important half.
Request with the use case rather than the feature. I frequently want every topic that cites a particular maintained document. At the moment I can find the document from the topic and not the reverse.
I am aware this is the third time this month I have made this point.
Building on post #71 rather than restating it.
Asking for something deliberately narrow: a way to link to a range of posts rather than a single one. Half the good exchanges here are four posts long and there is no way to point at all four.
The strength of my opinion here exceeds the strength of my evidence.
Everything in post #71 holds. The case it does not cover is the one I have.
Request from the analytics side: allow a table in a post to be marked as data rather than layout, so it can be copied without the formatting. Half the tables here are worth pasting into a spreadsheet.
What I can speak to on diff view for wiki revisions is narrow, so I will keep it narrow rather than generalising from it. Beyond that boundary I do not know.
I read post #75 twice before replying, because I had assumed the opposite.
Then the honest version is a comparison of the record shapes rather than the scores. How many results, over how long, from which services. That I would use.
Adding this to the thread rather than to the wiki, because I am not confident enough for the wiki.
Post #79 answers the question as asked. The question underneath it is different.
Use case: explain why you think the feature would help. "I would use this to..." makes the request concrete.
That reframing is better than the original request and staff would consider it. Which is a good illustration of why these belong in public: the first version would have been declined and the third is worth building.
Helpful, and short, which on this subject is harder than long.
I would use that constantly. The objection is presumably that it is data the site then has to hold and protect for no benefit to anyone else.
The general case is well covered; this is the awkward specific one.
On diff view for wiki revisions I would separate what is worth knowing from what is worth acting on. The first list is long and the second is short, and conflating them is how threads get heated.
Narrowing post #84, because the general version has more than one answer.
Since diff view for wiki revisions keeps coming up, it should probably be a maintained page rather than a recurring thread. I am happy to draft it if someone with more direct experience will review it.
Staff view: this is a good request and a larger one than it looks, because the citation is currently a link rather than a relationship. Recording it properly is the work, displaying it is trivial.
That has been true for the cases I have seen and I have not seen many.
Collapsed as off-topic by two members at trust level 3 or above
If you are new and reading this thread for the answer to diff view for wiki revisions: the answer is conditional, the conditions are in the third reply, and the rest of the thread is worth skipping.
Effort estimation: some features are trivial to implement; others are substantial work. Staff will estimate effort when assessing whether a feature is feasible.
If the premise is wrong, everything after it is decoration.