User talk:Cacycle/wikEdDiff/Archive 001

Screenshot?[edit]

A screenshot of the tool in action would be useful. Λυδαcιτγ 03:41, 17 April 2007 (UTC)[reply]

I second to this suggestion. OhanaUnited 22:29, 17 April 2007 (UTC)[reply]

Thanks, User:Mahanga. Λυδαcιτγ 17:35, 18 April 2007 (UTC)[reply]

Supported browsers[edit]

Support on Safari would be nice to know about, as well as Firefox. -- Yellowdesk 15:25, 19 April 2007 (UTC)[reply]

Test it and update the list. Cacycle 16:26, 19 April 2007 (UTC)[reply]

Color legend and symbol map[edit]

In a large diff I just checked I see sections highlighted in red, green, light green, yellow, grey, pink, purple and blue, and the occasional purple and grey buttons with arrows inside. It's not self-explanatory. I think a summary section of what this all means would go a long way.--Fuhghettaboutit 12:17, 20 April 2007 (UTC)[reply]

OK. The colors are indicating moved blocks (due to a bug the block color coding ends with the 'normal' change indicators, not with the real block end. I will try to fix that soon). Cacycle 12:51, 20 April 2007 (UTC)[reply]

Safari 3[edit]

The script does function on Safari 3, but the CSS is not loaded. This problem is a bug in Safari, and a similar problem was also present in Twinkle. Safari does not register empy <style> elements if they are appended. See this diff for an easy fix to that problem. --TheDJ (talk • contribs) 20:49, 12 July 2007 (UTC)[reply]

Unfortunately I have no access to Safari. Please could you point me to the code that you suspect. On a (very) quick inspection I did not find the addition of empty stylesheets to the document. Thanks, Cacycle 02:02, 13 July 2007 (UTC)[reply]

In function WikEdDiffStyleSheet(documentObject), where it says "this.styleElement = documentObject.createElement('style');" before "insert.appendChild(this.styleElement);" add "this.styleElement.appendChild(document.createTextNode());" --TheDJ (talk • contribs) 02:28, 13 July 2007 (UTC)[reply]

I have added that change, please could you check if it works now. Thanks, Cacycle 20:40, 14 July 2007 (UTC)[reply]

Works like a dream !! Thanks. --TheDJ (talk • contribs) 23:55, 14 July 2007 (UTC)[reply]

Thanks, Well Done![edit]

I've been looking for something like this for a long time -- see my comments going back a year and a half on Bugzilla Bug 5072. I just stumbled across WikEdDiff and it looks like you've solved my problem. Thanks very much for a valuable editing tool. --SteveMcCluskey (talk) 02:06, 30 March 2008 (UTC)[reply]

About the crash.[edit]

There are crashlogs of Safari here: https://bugs.webkit.org/show_bug.cgi?id=18392 It seems to have something to do with how a node element is being treated. So I think there is an error in the way HTML nodes are "walked". probably need to verify the type that you want to use in ann iteration or something like that. --TheDJ (talk • contribs) 00:32, 13 April 2008 (UTC)[reply]

I took a quick look: probably caused by this:

var tdArray = document.getElementsByTagName('TD');
	var tdOld;
	var tdNew;
	for (var i = 0; i < tdArray.length; i ++) {

getElementsByTagName returns a NodeList, not an array. --TheDJ (talk • contribs) 00:36, 13 April 2008 (UTC)[reply]

Unfortunately, I do not have Safari and cannot debug this myself. If somebody can figure this out I would be happy to fix the code. Thanks, Cacycle (talk) 02:25, 13 July 2008 (UTC)[reply]

Tracking authorship[edit]

Hi, I just came across your work on wikEdDiff. I have some suggestions on how to improve wikipedia, following up on an old feature request thread at bugzilla. I'd be interested in your comments on this issue. --Jt68 (talk) 16:33, 13 July 2008 (UTC)[reply]

Bugs[edit]

Hi!
I don't know, where is the best place to report bugs. I hope someone will read it here.
Take for example this diff: [1]. Using WikEdDiff the string "Kompositionen" seems to be deleted at top and put to bottom. But that is not true. Perhaps the mapping of the two strings "Original" is somehow wrong. -- Lustiger seth (talk) 16:23, 20 November 2008 (UTC)[reply]

another example for probably the same bug: [2] (3->3000). -- seth (talk) 00:49, 28 March 2009 (UTC)[reply]

Thanks for reporting this. I will have a look at it, but it may take a while as I am really busy in real life. Cacycle (talk) 16:42, 28 March 2009 (UTC)[reply]

~~Fixed in 0.9.6a.~~ Cacycle (talk) 04:38, 14 August 2009 (UTC)[reply]

No, the bug remains the same, see the above given examples. -- seth (talk) 21:51, 14 August 2009 (UTC)[reply]

Sorry, I thought the problem was in the linkified original diff when it actually is in the wikEdDiff diff. Cacycle (talk) 23:03, 14 August 2009 (UTC)[reply]

another example: [3] -- seth (talk) 19:46, 13 October 2009 (UTC)[reply]

External link bug[edit]

I love how I can click on wikilinks in the diff to take me to the article, and notice that this app provides clickable links for ELs too, but the EL links are always broken. The link is always truncated. Can you fix this, because I would like to be able to use that feature. Thanks! Wizard191 (talk) 21:03, 24 May 2009 (UTC)[reply]

Hi, that's because of that rubbish behavior of js to match "i" by /[\u0130]/i, see [4]

I recommend changing of

html = html.replace(/((https?|ftp):(\/\/[^\u0000-\u0020\!\"\$\'\(\)\*\,\<\>\[\\\]\^\`\{-\|\}\u007f-\uffff]*|<[^>]*>)+)/gi

by

html = html.replace(/((?:https?|ftp):(?:\/\/[^\u0000-\u0020!"\$'()*,<>[\\\]^`{|}\u007f-\uffff]*|<[^>]*>)+)/g

-- seth (talk) 19:15, 26 July 2009 (UTC)[reply]

Fixed in version 0.9.6, please Shift-Reload to update. Cacycle (talk) 01:33, 13 August 2009 (UTC)[reply]

Thanks! Wizard191 (talk) 01:51, 13 August 2009 (UTC)[reply]

Great! Thx! Btw. you don't need to escape all chars in a char class.

/\b(?:(?:https?|ftp|irc|gopher):\/\/|news:|mailto:)(?:[^\x00-\x20\s"\[\]\x7f|{}<>]|<[^>]*>)+?(?=[!"().,:;‘-•]*(?:\s|$)|[\x00-\x20\s"\[\]\x7f|{}])/gi

should be enough. -- seth (talk) 13:14, 15 August 2009 (UTC)[reply]

New EL bug[edit]

See this diff: [5]. Wizard191 (talk) 19:16, 13 August 2009 (UTC)[reply]

Fixed in 0.9.6a. Overlapping linkification and diff tags are no longer a problem. Cacycle (talk) 04:33, 14 August 2009 (UTC)[reply]

&-bug[edit]

Hi!
In [6] there is a bug:
doing

html = html.replace(/&amp;/g, '&');

and then

html = html.replace(/&/g, '&amp;');

will not leave html in its original state, because the second line replaces " " by "&nbsp;". -- seth (talk) 11:36, 23 September 2009 (UTC)[reply]

The   bug has been fixed with version 0.9.6c (Shift-Reload this page to upgrade if needed). Thanks for reporting, Cacycle (talk) 13:39, 23 September 2009 (UTC)[reply]

Incorrect diff[edit]

Hi. WikiEdDiff seems to show some of the deleted text on an incorrect place in the displayed diff here. --Tomaxer (talk) 23:52, 12 December 2009 (UTC)[reply]

Difficult color differenciation, use standard "del" and "ins" elements for accessibility[edit]

Using dark colors for the inverted text showing diffs within paragraph makes the differenciation between successive runs in red then green quite difficult to see, notably because they are too dark, or because they don't have easily distinctive lightness. I really suggest that you make the red much lighter, or simply change it into black, so that it will contrast easily with the green for added text. The most difficult differences to see is with narrow characters (like "i", "l", ".", ",", ":", ";", "!", or even just a space or a single quote... And given that this applies to source text, it could help if the deleted text was also overstroken ~~like this~~ (using the standard "del" element) and the added text (or replacement text) was tagged with the standard "ins" element like this : users could easily tweak their presentation preference for the "ins" and "del" elements in their personal CSS stylesheet (or using a ready-made stylesheet available to anyone, even without an account, from a shared accessibility theme). verdy_p (talk) 01:14, 28 December 2009 (UTC)[reply]

Non-Wikimedia site[edit]

This is a great tool on Wikipedia, but I can't get it to work on Appropedia. I tried "the old-fashioned way" in Appropedia:

// install [[User:Cacycle/wikEdDiff]] enhanced diff view using ajax
document.write('<script type="text/javascript" src="'
+ 'http://en.wikipedia.org/w/index.php?title=User:Cacycle/wikEdDiff.js'
+ '&action=raw&ctype=text/javascript&dontcountme=s"></script>');

But it shows nothing other than a line when I click it in a diff from history, and when I do the "Show changes" in edit mode, it shows the following text in red:

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"><html><head><title>Forbidden</title></head><body><h1>Forbidden</h1><p>Raw pages must be accessed through the primary script entry point.</p></body></html>

(which is not in the wiki markup) and I think the whole section being edited is shown in green. Clues? Thanks --Chriswaterguy talk 13:33, 6 March 2010 (UTC)[reply]

Maybe an incompatibility with a gadget, userscript or an add-on? It works fine for me using the exact same code on my monobook.js page there. Cacycle (talk) 22:02, 23 April 2010 (UTC)[reply]

Active links[edit]

It seems that in the last few days the ability to click on internal and external links in the diff has stopped working. Just a heads up. Thanks! Wizard191 (talk) 12:21, 23 April 2010 (UTC)[reply]

Has already been fixed yesterday :-) (Shift-Reload this link to update). Cacycle (talk) 21:53, 23 April 2010 (UTC)[reply]

I finally got around to writing you a message here, and then later this morning it started working again. Go figure. Thanks for the help! Wizard191 (talk) 22:06, 23 April 2010 (UTC)[reply]

Non-English Wikipedias[edit]

Which code snippet is recommended for Non-English Wikipedia wikis (in my case the Dutch Wikipedia)? ImportScript('User:Cacycle/wikEdDiff.js') and importScript('en:User:Cacycle/wikEdDiff.js') do not work. The old fashioned code snippet does work, but the shorter version would be nice. Ceinturion (talk) 09:34, 28 May 2010 (UTC)[reply]

It should be ImportScript('User:Cacycle/wikEdDiff.js','en'). Infovarius (talk) 18:02, 10 October 2011 (UTC)[reply]

FYI[edit]

Just an FYI, wikEdDiff butchered this diff: [7]. Wizard191 (talk) 17:46, 14 June 2010 (UTC)[reply]

Stopped working[edit]

I love this tool but it's stopped working for me. I just get three dots where the analysis used to be. I cleaned out User:Will Beback/vector.js, and turned off virtually every gadget or option, but still nothing. Any ideas? Will Beback talk 11:48, 30 October 2010 (UTC)[reply]

It stopped working for me too. The triangle-button has disappeared a month ago in Internet Explorer (IE8). In Google Chrome the triangle button still exists, but it is dysfunctional in the way you describe: it responds with three dots. What a pity this tool no longer works.

Cacycle warned a month ago that "The configuration syntax has changed with version 0.9.92 (September 24, 2010). Please see the wikEd customization page for details", may be that has something to do with it (http://en.wikipedia.org/wiki/User:Cacycle/wikEd_help). Ceinturion (talk) 20:07, 30 October 2010 (UTC)[reply]

It's fixed in the next release. Cacycle (talk) 23:41, 30 October 2010 (UTC)[reply]

Yippee! Thanks for providing and maintaining this tool. Will Beback talk 23:45, 30 October 2010 (UTC)[reply]

Fixed in wikEdDiff 0.9.13b, you might have to load and Shift-Reload this page. Cacycle (talk) 21:25, 1 November 2010 (UTC)[reply]

Yes, it's working. Life is good again. Will Beback talk 23:06, 1 November 2010 (UTC)[reply]

Lost my tabs[edit]

Yesterday, I edited my vector.js file to install wikEdDiff. Editing this morning, I noticed that the tabs (+-, history, etc.) were missing from the top of my WP pages. Commenting out the vector.js line installing wikEdDiff restored my missing tabs. (??) Wtmitchell (talk) (earlier Boracay Bill) 15:21, 24 April 2011 (UTC)[reply]

Two suggestions[edit]

Hi Cacycle,

I love wikEdDiff. I have two suggestions.

Is it possible to use the technology to quantify a diff in a small number of numbers? Something like x characters added, y characters deleted, z characters moved.
I noticed that this diff gives slightly unexpected results in wikEdDiff. The list of record labels has been reordered (and added to) but the re-ordering is not recognised by wikEdDiff. Is this because the label names are less than three words? I realise that there are various things you have to balance when doing this, but could you make it so that it recognises lists and hence makes it more obvious if the list has been added to or re-ordered? There are certain characters that are commonly used to separate lists, the most common being commas.

Yaris678 (talk) 20:13, 5 May 2011 (UTC)[reply]

Ad 1: Sure, that's possible. Just take the final diff text and count the addition, deletion, and block markups.

Ad 2: Interesting observation. It is actually a result of how the word oriented algorithm works: moved blocks are detected from words unique to the whole text and that appear in both versions. Think of them as seed crystals. Since none of the words moved around in that sentence is unique (not even in that sentence!), no blocks are detected in that line.

Hope that helped, Cacycle (talk) 21:41, 9 May 2011 (UTC)[reply]

Thanks.

Cool. I might look in to how I could implement that in code... though I am not familiar with your code so any pointers would be appreciated.
Interesting information in on how the algorithm works. Thanks. I just did a test to see for myself. Could you do something that looked for unique collections of non-unique words? Or am I suggesting something too complicated? I guess you could look for collections of specific sizes or you could look for collections broken up by certain characters, such as line breaks, full stops and commas.

Yaris678 (talk) 08:26, 10 May 2011 (UTC)[reply]

1: The result is a plain text with markup, just use a regexp loop to count the markup codes.

2: Yes, to resolve these positions it would be possible to repeat the process stepwise with increasing size of the "word atoms" (or decrease?!). If a complete wikilink would count as one "word atom" instead of single words and wiki markup elements, then the algorithm would have easily recognized the moves in your example. BTW, in order to understand the code comments you should read the original publication.

Cacycle (talk) 21:46, 10 May 2011 (UTC)[reply]

Thanks.
Do you mean this paper? Looks very interesting. I will check it out.

Yaris678 (talk) 08:18, 11 May 2011 (UTC)[reply]

wikEdDiff broken with MediaWiki 1.18 update[edit]

Hi, it seems that User:Cacycle/wikEdDiff.js is broken, because new MediaWiki don't use className="diff" anymore. New className is "diff some_another_class" so diff table detection with rule tables.item(i).className == 'diff' always fails. --91.153.53.216 (talk) 07:02, 8 October 2011 (UTC)[reply]

I'm glad someone figured out the error. This is a tremendously useful tool, and I miss it. (Something like it should be added to the gadget list.) Will Beback talk 07:17, 8 October 2011 (UTC)[reply]

It's working again. Life is good. Will Beback talk 20:19, 10 October 2011 (UTC)[reply]

Hmm, and it's again not working: see User talk:Cacycle/wikEdDiff.js. -- seth (talk) 20:34, 6 November 2011 (UTC)[reply]

Yeah, i can confirm this. Though i think that current problem is with ResourceLoader upgrade and they are just dropping backwards support for old stuff. --Zache (talk) 07:14, 8 November 2011 (UTC)[reply]

Sorry. It's now fixed in version 0.9.15c, it was a minor stupid wikEdDiff bug. Cacycle (talk) 19:47, 8 November 2011 (UTC)[reply]

Great! Thx! -- seth (talk) 21:32, 10 November 2011 (UTC)[reply]

fails to load in Commons[edit]

I import it via importScriptURI('//en.wikipedia.org/w/index.php?title=User:Cacycle/wikEdDiff.js&action=raw&ctype=text/javascript'); in my monobook.js in Commons. Since some (maybe 2) days a error is displayed on top of diffs "Error: https://commons.wikimedia.org/w/undefinedw/index.php?title=User:Cacycle/diff.js&action=raw&ctype=text/javascript at line 1: Error loading script" The Delta is shown but has no function. No JS errors in the console. Use FF 3.6 and German monobook skin. Thanks! :) Cheers --Saibo (Δ) 21:42, 6 November 2011 (UTC)[reply]

Similar (but no error banner) for someone with the same import but firefox 7.0.1 de ubuntu 11.10, monobook. But works in Chrome. --Saibo (Δ) 21:54, 6 November 2011 (UTC)[reply]

Here in enwp I get this JS error on diff load and no WikEddiff function (enabled via gadgets → WikEd):

Fehler: uncaught exception: [Exception... "Component returned failure code: 0x80630002 [nsIDOMStorage.setItem]"  nsresult: "0x80630002 (<unknown>)"  location: "JS frame :: https://en.wikipedia.org/w/index.php?title=User:Cacycle/wikEd.js&action=raw&ctype=text/javascript :: anonymous :: line 14559"  data: no]

But works in Opera 11.5. Strange.. --Saibo (Δ) 22:02, 6 November 2011 (UTC)[reply]

Sorry. It's now fixed in version 0.9.15c, it was a minor stupid wikEdDiff bug. Cacycle (talk) 19:46, 8 November 2011 (UTC)[reply]

Great, thanks! :-) Works again since yesterday. Cheers --Saibo (Δ) 15:00, 9 November 2011 (UTC)[reply]

Hmm, seems to happen again:

Fehler: uncaught exception: [Exception... "Component returned failure code: 0x80630002 [nsIDOMStorage.setItem]" nsresult: "0x80630002 (<unknown>)" location: "JS frame :: https://en.wikipedia.org/w/index.php?title=User:Cacycle/wikEd.js&action=raw&ctype=text/javascript&smaxage=21600&maxage=86400 :: anonymous :: line 14552" data: no]

But I haven't double checked yet - just in case someone else also has the problem. ;-) Cheers --Saibo (Δ) 04:21, 13 November 2011 (UTC)[reply]

Works again.. maybe just a cache regression? ;-) --Saibo (Δ) 17:15, 15 November 2011 (UTC)[reply]

Highlighting of moved text[edit]

Hi,

I was looking at this diff with wikEdDiff. Around the area of the inserted section "Concept of Entrepreneurship" the word "an" is highlighted in yellow, indicating some text has moved from the "Further reading" section. There isn't really any moved text. However, the mistake is understandable since there is added and removed text both contain the unique word "real".

The important question for me is: Why is the word "real" also not in yellow?

Taking this further, I would have thought that there should have been a yellow box around the whole of the moved text, with the red and green boxes appearing inside the yellow box. This could be achieved by having the moved-text boxes being one or two pixels bigger above and below the text than the added-text and removed-text boxes.

I love using wikEdDiff. These comments are just me trying to help you make it even better.

Yaris678 (talk) 13:20, 11 January 2012 (UTC)[reply]

I reported this bug several time ago: User talk:Cacycle/wikEd#Bug in diff.js. I wrote my own script which looks almost like the original but displays the changes correctly. If you want to use this instead of wikEdDiff, just put

mw.loader.load('//de.wikipedia.org/w/index.php?title=Benutzer:Schnark/js/diff.js&action=raw&ctype=text/javascript');

into your common.js. --Schnark (talk) 11:23, 12 January 2012 (UTC)[reply]

Thanks. I don't get the same problem with your diff... but then your diff doesn't identify any moved text!

Obviously that is correct in this case... but it indicates that the difference isn't purely a matter of highlighting. How is your algorithm different? Does it seeks to discount falsley identified segments of moved text?

Yaris678 (talk) 16:14, 12 January 2012 (UTC)[reply]

Well, there isn't any moved text, apart from "an" and "real", which are too short to be marked as moved by my script. wikEdDiff has a problem, when a moved block is directly followed by a deletion or insertion. If you look at the HTML source of the diff you will find some interesting nesting: the deletion and the insertion after the moved "an" are both inside the moved block (which you can't see, since they have their own background-color), but then the moved block is closed, though the following "real" actually should be inside the moved block. Instead it looks like it wasn't changed. The following deletion should be inside the moved block, too (but again, even if it were, the color wouldn't indicate a move, since it is already colored red). --Schnark (talk) 09:51, 13 January 2012 (UTC)[reply]

Yeah my example probably isn't the best one to go with... so how about this:

Test 1 illustrates your diff being better than wikEdDiff... although arguably "dog" should be after "quick brown" on the second line". Is it worth having a rule that added and remvoved blocks should be presented next to each other if that is possible?

I assume that there is a minimum size that a moved block of text must be to be recognised by your diff. It recognised some of the moved words but not others.

Test 2 better illustrates the problem with rendering moved text in wikEdDiff. Your version seems to be better... but there is the possibility of a version that is better still... which relates to what I was getting at in my original post... It would be good if "that lasted" was presented within a single block of moved text. This would be similar to the wikiEdDiff, but without the graphical problems. As I said in my original post, you could show this by having the coloured box for the moved text extending slightly above and below the red and green boxes.

Yaris678 (talk) 13:20, 13 January 2012 (UTC)[reply]

Your first test case is quite interesting: If you change the configuration settings in the third tab (they are not localized, but I don't think it would be much help if they were, all you can do is changing the numbers and look if something interesting happened) you can get different variants of the diff, but not the one you really want to get. The main problem is that every word occurs twice, so it's difficult for the algorithm to find out which should be paired.

If I find time I will try to implement your suggestion for the second test case. --Schnark (talk) 09:02, 14 January 2012 (UTC)[reply]

Mock up of an image of Schnark's diff interface, with the colours for the box and border taken from the Wikimedia Monobook interface. These colours are less obtrusive, making the diff easier to use.

In terms of the algorithm never getting exactly the right thing in test 1... one approach would be to look for unique pairs of words... However, I think the best algorithm would start by looking for unique sentences, then maybe go on to unique terms between commas, before finally looking for unique words.

I have another suggestion for the graphics. See the image to the right.

Yaris678 (talk) 13:16, 22 January 2012 (UTC)[reply]

Your second test now works as expected, and the script now has an English localization. --Schnark (talk) 09:33, 11 February 2012 (UTC)[reply]

Brilliant! Loving the insertions and deletions inside moved blocks. Any thoughts on my idea for the colour scheme (right)? I think doing it that way will be less obtrusive and so easier to use. Yaris678 (talk) 16:24, 11 February 2012 (UTC)[reply]

That yellow color looks too much like the Monobook skin to me (I'm using Vector), but I changed the colors a bit highlight the selected tab a bit better. Highlighting the other tab at the bottom is a bit more difficult, perhaps I find the time to look at this after the deployment of MediaWiki 1.19. If you still prefer a yellow border for the selected tab, you can override the default CSS by putting

body .enhanced_diff_button_selected {
    border-color:yellow;
}

into your common.css. --Schnark (talk) 09:56, 14 February 2012 (UTC)[reply]

Not sure if I made myself clear. The big thing for me is the brown box around the whole diff, with the black border around that. I think you may have changed the colour for that to something more yellow, which is an improvement. However, for me, the box and border should be pale grey colours, similar to the rest of the wiki interface. Using brown and black clashes with the neutral colour scheme. If it blended in, it would all look a lot slicker. Yaris678 (talk) 12:37, 14 February 2012 (UTC)[reply]

OK, this means I really have to use different CSS for different skins, at least for Monobook and Vector. --Schnark (talk) 08:27, 15 February 2012 (UTC)[reply]

The brown box is present on the both Vector and Monobook. However, there is more of it on the standard diff in Monobook. Either way, I'd just not have it. Is it there to improve readability within the coloured boxes in your diff? Can you make it present in one and not the other? Either way, softening the black border would help. Make it grey? Yaris678 (talk) 18:28, 15 February 2012 (UTC)[reply]

Most of the time I'm working on public computers, where the screen isn't calibrated correctly, so I can't really see whether the background color is too obtrusive or not. I now changed it to white, and changed the colors to match the user interface (at least in Monobook and Vector). --Schnark (talk) 09:51, 16 February 2012 (UTC)[reply]

That's brilliant, thanks.

BTW, do you have a page somewhere about your diff? I'm thinking of an explanation of the algorithm and what the different parameters mean. I'm guessing such a page, if it exists, only exists in German. But I could help you translate it into English, if you'd like. It would also be good to know where to post future comments on it. I don't want to keep bugging Cacycle by putting them on here!

Yaris678 (talk) 19:24, 16 February 2012 (UTC)[reply]

The algorithm is explained on de:Benutzer:Schnark/js/diff/core and already is in English. You can put comments on my talk page here or at de.wikipedia. --Schnark (talk) 09:44, 17 February 2012 (UTC)[reply]

Cool. Thanks. Yaris678 (talk) 10:34, 17 February 2012 (UTC)[reply]

[BUG] wikEd.DiffSetup is never executed[edit]

I've noticed a problem when running the code

mw.loader.load('//en.wikipedia.org/w/index.php?title=User:Cacycle/wikEdDiff.js&action=raw&ctype=text/javascript&smaxage=21600&maxage=86400');

on Google Chrome console, in a diff page such as this. Although the script gets imported, and

wikEd.AddEventListener(window, 'load', wikEd.DiffSetup, false);

is executed, the function "wikEd.DiffSetup" is never called (maybe because the page is already loaded and the script "didn't notice it").

Would it be possible to fix the wikEd.AddEventListener so that it executes the eventHandler in case it is called after the page is already loaded? Maybe that function could be replaced by jQuery(document).ready(handler)?

PS: the same problema happens if I try to create a portlet link which I would use to import the script only when I need it. Helder 13:47, 29 March 2012 (UTC)[reply]

This now works under wDiff 1.0.5/wikEdDiff 0.9.28. Cacycle (talk) 22:06, 26 August 2014 (UTC)[reply]

Weblink: script error or user error (or both)?[edit]

Hello Cacycle,

at first, thank you very much for your script, which is indeed very useful for displaying differences in WP edits. I like it very much and I'm using it for many months now, in this way. Furthermore I use Firefox 11.0 under Windows Vista.

Here a little "Ooops...":

Yesterday evening I made this edit, which as you can see contains the following weblink (#1):

http://www.totalepmediacentre.com/index.cfm?encstrg=D%3E*F06%40R0B4%2FZC\E9BR^%3AC%25I%3BV%3CSI%23-%5D%3AG8Q6%3D_QPZ0%3A%28Q!%23%27%0A

But when performing a click on the red marked weblink within the diff display, I reach a different (!) location, this one (#2):

http://www.totalepmediacentre.com/index.cfm?encstrg=D%3E*F06%2540R0B4%252FZC%5CE9BR%5E%253AC%25I%253BV%3CSI%2523-%5D%253AG8Q6%253D_QPZ0%253A(Q!%2523%27_

Weblink #1 is the correct and desired one, which is also correctly (!) reached when clicking here on reference #8 at the page's bottom.

However, weblink #1 contains a backslash "\" and a "roof" "^", maybe that's the reason for the incorrect behaviour? So this had been my personal fault (as I should have "escaped" the link much better than I already did). Or is it a problem of the script? Or of both of us - the script and me myself?

Would be nice, if you could have a look at this, when you find some time (it is not an urgent case).

Thank you and kind regards, ---WolliWolli- (talk) 15:03, 30 March 2012 (UTC)[reply]

Works under wDiff 1.0.0/wikEdDiff 0.9.26. Thanks, Cacycle (talk) 23:59, 25 August 2014 (UTC)[reply]

Suggestion for enhancing diffs within lists[edit]

wikEdDiff, like many other diff tools, tends to slightly mis-place diffs within lists, or where other common prefixes are used on each paragraph, from where they should ideally be shown. A (not very concise) example can be seen at [8]. Look for The Name Of The Game in the diff. The highlight should ideally begin with *''[[ and end with Hoover Dam. instead of beginning with The Name Of The Game and ending after the following paragraph's *''[[.

There's a better example further down. Look for Category:American Jews. In this case, what was actually done was insertion of [[Category:American Jews]] above [[Category:American male singers]] instead of the "half-and-half" that is highlighted.

It seems that this could be implemented by, after finding the diff, see if the last char of the diff matches the first character before it. If so, move the diff back by one char. Repeat until the last char does not match the first char before the diff, e.g.:

// nStartPos is the starting position of the diff in buf[]
// nEndPos is the ending position of the diff
while (buf[nEndPos] == buf[nStartPos - 1])
{
    nStartPos--;
    nEndPos--;
}

(with bounds checking, etc.) — AlanM1 (talk) 07:07, 16 April 2012 (UTC)[reply]

This has been added to wDiff 1.0.5/wikEdDiff 0.9.28. Cacycle (talk) 22:02, 26 August 2014 (UTC)[reply]

Broken diffs[edit]

The script is breaking some diffs. I've noticed this problem here, and managed to replicate the bug on this smaller version. The HTML generated by the script for the right hand side is:

<div> <a href="//en.wikipedia.org/wiki/Template:foo_bar" style="text-decoration: none; color: inherit; color: expression(parentElement.currentStyle.color)" title="Template:foo bar">{{</a> <span class="diffchange diffchange-inline"> <a href="//en.wikipedia.org/wiki/Template:foo_bar" style="text-decoration: none; color: inherit; color: expression(parentElement.currentStyle.color)" title="Template:foo bar">foo bar</a> </span> <a href="//en.wikipedia.org/wiki/Template:foo_bar" style="text-decoration: none; color: inherit; color: expression(parentElement.currentStyle.color)" title="Template:foo bar"></a> |1=$1|2= <span class="diffchange diffchange-inline"> <a href="//en.wikipedia.org/wiki/b_c/$1" style="text-decoration: none; color: inherit; color: expression(parentElement.currentStyle.color)" title="b c/$1">[[b</a> </span> <a href="//en.wikipedia.org/wiki/b_c/</span>" style="text-decoration: none; color: inherit; color: expression(parentElement.currentStyle.color)" title="b c/</span>"> </a> <span class="diffchange diffchange-inline"> <a href="//en.wikipedia.org/wiki/b_c/<span class=" diffchange="" diffchange-inline"="">" style = "text-decoration: none; color: inherit; color: expression(parentElement.currentStyle.color)" title="b c/ <span class="diffchange diffchange-inline">">c/$1|test]] </span> </a> </span>}} </div>

Helder 18:55, 25 June 2012 (UTC)[reply]

Fixed in wDiff 1.0.0/wikEdDiff 0.9.26. Thanks - Cacycle (talk) 23:55, 25 August 2014 (UTC)[reply]

Templates with “-“ in the name[edit]

At https://en.wikipedia.org/w/index.php?title=Box-drawing_character&diff=521329567 we have an HTML code:

<div><span class="diffchange diffchange-inline">
	<a href="//en.wikipedia.org/wiki/Template:Box"
	 style="text-decoration: none; color: inherit; color: expression(parentElement.currentStyle.color)"
	 title="Template:Box">{{Box</a></span>
	-<span class="diffchange diffchange-inline">drawing</span>
	 <span class="diffchange diffchange-inline">sample}}</span>
</div>

Namely, it generates wrong /wiki/Template:-link and title for “{{Box-drawing sample}}”. Incnis Mrsi (talk) 11:25, 18 January 2013 (UTC)[reply]

Incnis Mrsi: seems to work for me under wDiff 1.0.0/wikEdDiff 0.9.26. Thanks for reporting. Cacycle (talk) 23:52, 25 August 2014 (UTC)[reply]

Version 0.9.18 broken in Safari[edit]

While investigating Wikipedia:Help desk#Show Improved Diff View not working I found that the update to wikEdDiff 0.9.18 broke it in Safari. Safari is not listed at User:Cacycle/wikEdDiff#Supported browsers but it might be nice if it worked anyway. I tested the former version by copying it to User:PrimeHunter/wikEdDiff 0.9.17.js and it works in Safari. PrimeHunter (talk) 22:57, 10 June 2013 (UTC)[reply]

Thank you for that note. I'd loved wikEdDiff while it worked for me, but it hadn't been working for some months. Hadn't thought to try a different browser. Finally became sufficiently frustrated to search for this documentation. Sminthopsis84 (talk) 21:12, 18 August 2013 (UTC)[reply]

Some diffs broken in Chrome[edit]

In [9] with the current Google Chrome version 28.0.1500.72 I see the whole old revision in red followed by "undefined" in green. See Wikipedia:Village pump (technical)#User:Cacycle/wikEdDiff. PrimeHunter (talk) 22:17, 15 July 2013 (UTC)[reply]

PrimeHunter: Works fine under wDiff 1.0.0/wikEdDiff 0.9.26/Chrome, thanks for reporting. Cacycle (talk) 23:39, 25 August 2014 (UTC)[reply]

Mobile[edit]

Hi, I use wikediff on my desktop, but just found out diffs look really premitive on mobile browsers. Is Wikediff disabled here, and is there a way to fix this? BTW do you know of a full app for mobile editing? trespassers william (talk) 12:48, 17 September 2013 (UTC) [Moved to buttom of page] trespassers william (talk) 14:01, 17 September 2013 (UTC)[reply]

Reminder: color legend and symbol map[edit]

Excellent feature. I recall User talk:Cacycle/wikEdDiff#Color legend and symbol map. The diff should have a heading with a short color legend and symbol map. Yet it is only available by searching this user page via the preferences. --Wickey-nl (talk) 11:14, 8 October 2013 (UTC)[reply]

In wDiff 1.0.5/wikEdDiff 0.9.28 moved elements now have popup explanations. In general, I think it is pretty much self-explanatory. Cacycle (talk) 21:57, 26 August 2014 (UTC)[reply]

Not working on IE8[edit]

Hi. wikEdDiff isn't working on IE8. For some time now, it has just given the shaded box with 3 dots inside. It's working fine on Chrome. Cheers, --Stfg (talk) 17:13, 6 November 2013 (UTC)[reply]

Stfg: wDiff 1.0.0/wikEdDiff 0.9.26 works for me under IE 11. Will check IE 8 later. Cacycle (talk) 23:34, 25 August 2014 (UTC)[reply]

@Cacycle: Oh dear, I went to sleep on this one. Sorry. I'm now on IE11 too, and it works fine. Back then, I still had an XP system and couldn't get past IE8. When XP became unsupported, I moved. IE8 may not be worth your time any more, since all supported versions of Windows can get beyond IE8. Thanks, --Stfg (talk) 00:01, 26 August 2014 (UTC)[reply]

wDiff 1.0.5/wikEdDiff 0.9.28 now works under IE 8 (only move indicator symbols are displayed as unknown characters, this could be fixed by user configuration). Cacycle (talk) 21:53, 26 August 2014 (UTC)[reply]

Links to "null" subpages[edit]

The script is creating a link to null/subpage when we use the simplified syntax [[/subpage|example]]. See this example. Helder 18:14, 25 June 2012 (UTC)[reply]

This still happens on this link. Helder.wiki 20:00, 16 May 2014 (UTC)[reply]

Works now under wDiff 1.0.5/wikEdDiff 0.9.28. Cacycle (talk) 22:01, 26 August 2014 (UTC)[reply]

Problem on Firefox 30.0[edit]

For the last week or so I've been getting bizarre results when clicking on the advanced difference function. I've pasted the results of a recent compare below (between the pre labels:

<script src="//bits.wikimedia.org/en.wikipedia.org/load.php?debug=false&lang=en&modules=user&only=scripts&skin=vector&user=SteveMcCluskey&version=20131213T214105Z&*"></script>
<script src="//bits.wikimedia.org/en.wikipedia.org/load.php?debug=false&lang=en&modules=user.groups&skin=vector&user=SteveMcCluskey&version=20140627T160741Z&*"></script>
<script>if(window.mw){
mw.config.set({"wgBackendResponseTime":45635,"wgHostname":"mw1067109"});
}</script>
</body>
</html>

SteveMcCluskey (talk) 20:23, 28 June 2014 (UTC)[reply]

In the output the string 45635 the 56 is highlighted in red, the 35 in green. Similarly in the string mw1067109 the 067 is highlighted in red, the 109 in green. Hope this helps you debug the problem. I'm sorry that the string above seems to have done a nasty bit on your page; delete as necessary. SteveMcCluskey

SteveMcCluskey: do you still have these problems under wDiff 1.0.0/wikEdDiff 0.9.26? Cacycle (talk) 23:31, 25 August 2014 (UTC)[reply]

The problem seems to have been resolved. Thanks. --SteveMcCluskey (talk) 13:04, 26 August 2014 (UTC)[reply]