User talk:Cacycle/wikEd

Please support wikEd

Please support wikEd by helping to fix the following browser and MediaWiki issues.

• Firefox:
  • 579763, 579760 Cursor/caret disappears (07-2010)
  • 1016372 Space lost when deleting text (05-2014)
  • 926230 Space at end of line not styled (10-2013)
  • 543204 Focus after search (01-2010)
  • 926164 Editor deletes blank before inserted block element when converting to text (10-2013)
  • 458524 Automatic syntax highlighting would interfere with undo/redo. The only reason why wikEd does not have automatic syntax highlighting. (10-2008)

• Webkit/Chrome:
  • None.

This is the discussion page for wikEd, a full-featured in-browser text editor that adds enhanced text processing functions to Wikipedia and other MediaWiki edit pages. Feel free to leave your comments, suggestions, and bug reports at the end of this page.

Archives

Archived discussions from this page: 1 2 3 4 5 6 7 8

wikEd Bug reports

In order to help you with problems, I need as many details and informations as possible:

• Your wikEd version (hover over the wikEd logo on top of every page close to the logout link). Does the bug persist if you update to the latest version (Shift-Reload or Ctrl-Shift-R)
• Your browser id (in your browsers's main menu under Help → About) (something like "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.2) Gecko/20070219 Firefox/2.0.0.2")
• Error console errors (in your browsers's main menu under Tools → Error console; push clear, reload the page, and copy and paste the error messages)
• Which browser add-ons have you installed (in your browsers's main menu under Tools → Add-ons)
  • Optional: What happens if you disable your add-ons and restart the browser (close the quick start and the error console too)
• Which user scripts have you installed on your monobook.js page
• Which operating system do you use
• Describe the problem, please be as specific as possible about what is wrong (including when it happens, what happens, what is broken, and what still works)
• Steps to reproduce
• What exactly happens if you follow these steps
• Please add your bug report at the bottom of this page

Bug - Bullets embedded in table

My config -

• wikEd: 0.9.43
• Browser: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.7) Gecko/20070914 Firefox/2.0.0.7

Steps -

• Create a table in Word 2007 that contains bullets nested inside a table cell.
• Paste into wikEd.
• Select all.
• Click "Convert pasted content to wiki code..."

Actual wiki code:

| * Bullet 1
* Bullet 2

Required wiki code:

|
* Bullet 1
* Bullet 2

Tom.ngo 15:49, 22 September 2007 (UTC)

I will fix this as soon as I find the time. Thanks, Cacycle 04:34, 25 September 2007 (UTC)

Works in 0.9.69a. Cacycle (talk) 03:02, 30 January 2009 (UTC)

Request - Pipes and Bangs

Frequently we prefer that the first row (and, less frequently, the first column) of a table to be wiki-ized as headers, i.e., with '!' delimiters instead of '|'. Do you have a way to make this happen by editing the rich text appropriately? If not, here are some suggestions:

1. If a cell is all bold, give it header style.
2. If the variable wikEdWikifyTableHeaderRow = true then header-ize first row
3. If the variable wikEdWikifyTableHeaderCol = true then header-ize first column

I like #1 the best, but of course this is your wikEd invention!

Tom.ngo 03:16, 2 October 2007 (UTC)

Thanks for the suggestion. I am thinking about a "if the first row or the first cell is bold" rule. Cacycle 12:19, 2 October 2007 (UTC)

I would personally prefer #1 - if a cell is all bold, give it header style. Tom.ngo (talk) 21:55, 19 December 2007 (UTC)

WikEd Preview vs Standard Preview

Hitting the WikEd preview (the one with the icon and that loads below the edit section) and later the Standard Preview button will force a Return on the previewed page.
That's bad when you edit a page with a Submit form or an inputbox. When you preview by hitting the preview icon and later hit the standard preview button, it will submit the form and you will be taken to the submit destination page. God bless it only works in Firefox so browsing back won't lose the data ;) Either fix it or remove the standard preview when WikEd is used, cos the WikEd preview feels much better. --Subfader (talk) 20:21, 16 March 2008 (UTC)

Sorry, but I cannot understand your problem, please could you reword your text. Thanks, Сасусlе 03:34, 6 April 2008 (UTC)

Edit a page that includes a submit form like the inputbox. Preview with WikEd preview, then hit the MW preview button. This will cause the form to be submitted and you're taken to the form's destination page. --77.135.30.91 (talk) 16:18, 25 May 2008 (UTC)

Has been fixed. Cacycle (talk) 03:04, 30 January 2009 (UTC)

Change-highlighting bug?

As my browser (Firefox 2.0.0.14) is loading this diff, it highlights (in red) the newly added text. But as the page finishes loading, the highlighting disappears. Does this happen with anyone else? --zenohockey (talk) 21:35, 31 May 2008 (UTC)

Seems to work now. Cacycle (talk) 03:36, 24 November 2008 (UTC)

Freezes on image tag

Version is 0.9.62g. See this diff. Apparently it's related to this. GregorB (talk) 19:44, 13 June 2008 (UTC)

Shit, this looks like difficult one. Thanks, Cacycle (talk) 20:08, 18 June 2008 (UTC)

Firefox 3.0

wikEd Version: 0.9.62g GM (April 25, 2008)

Fx/OS Version: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9) Gecko/2008052906 Firefox/3.0 on Microsoft XP

Error: Component returned failure code: 0x80070057 (NS_ERROR_ILLEGAL_VALUE) [nsIDOMXPathEvaluator.evaluate]

Source File: file:///C:/Documents%20and%20Settings/Gentry/Application%20Data/Mozilla/Firefox/Profiles/lfgmobjb.Stability%20Test/gm_scripts/lyricwikicleanerv2.user.js Line: 32

Error: [Exception... "Security Manager vetoed action" nsresult: "0x80570027 (NS_ERROR_XPC_SECURITY_MANAGER_VETO)" location: "JS frame :: http://lyricwiki.org/index.php?title=User:Kingnee1114lyrics&action=edit :: anonymous :: line 0" data: no]

Source File: http://lyricwiki.org/index.php?title=User:Kingnee1114lyrics&action=edit Line: 0

Installed addons: [1]

Monobook installs: None

Description: Currently, none of wikEd's buttons work. All I did was install the new Firefox 3.0 as my primary browser. Now wikEd works for Wikipedia, but not LyricWiki. So I reverted to 2.0.0.14 and everything was fine. I could edit and there was no problem. The next step was to test on a different computer (basically one with no addons/modifications) but that was the same thing.

To reproduce: just try to use wikEd (GM version, I think) on lyricwiki.org, with 3.0 installed

King_Nee1114 (talk page • contributions • deletions) 17:34, 18 June 2008 (UTC)

The error message complains about lyricwikicleanerv2.user.js. Cacycle (talk) 20:11, 18 June 2008 (UTC)

Please update your Greasemonkey add-on under https://addons.mozilla.org/en-US/firefox/addon/748. Cacycle (talk) 02:59, 19 June 2008 (UTC)

Cacycle (talk) 02:45, 19 June 2008 (UTC)

Unfortunately, updating Greasemonkey and any other attempted fix failed. In Firefox 3.0, I can only use wikEd on Wikipedia, and none of the other MediaWiki sites.

71.82.148.8 (talk) 06:20, 19 June 2008 (UTC)

Did you install the new Greasemonkey version (0.8.20080609.0) and restart the browser and disable that lyricwikicleanerv2 script in Greasemonkey? Cacycle (talk) 22:19, 19 June 2008 (UTC)

Yes, I have the most current version, disabled the other scripts, and tried at 4 different wikis. The only place wikEd works is at Wikipedia. All the rest, the buttons appear, but do nothing.

King_Nee1114 (talk page • contributions • deletions) 06:12, 21 June 2008 (UTC)

Also: every time I click a button on wikEd, I get hit with this:

Error: [Exception... "Security Manager vetoed action"  nsresult: "0x80570027 (NS_ERROR_XPC_SECURITY_MANAGER_VETO)"  location: "JS frame :: http://lyricwiki.org/index.php?title=User:Kingnee1114lyrics&action=edit :: anonymous :: line 0"  data: no]
Source File: http://lyricwiki.org/index.php?title=User:Kingnee1114lyrics&action=edit
Line: 0

King_Nee1114 (talk page • contributions • deletions) 06:15, 21 June 2008 (UTC)

It seems to be a Firefox 3.0 problem, I have filed a bug report [2]. You might want to use an older and stable Firefox version (2.0.0.12) until they fix it. Cacycle (talk) 05:21, 22 June 2008 (UTC)

Thanks for the help. Good thing I kept fx2 and fx3 separate installations.

One question though: why does wikEd work at Wikipedia, but not any MediaWiki site?

King_Nee1114 (talk page • contributions • deletions) 07:16, 22 June 2008 (UTC)

I have added a workaround for this Firefox/Greasemonkey bug in 0.9.63d. Cacycle (talk) 02:03, 23 June 2008 (UTC)

problem still persists

• wikiEd 0.9.63e GM (June 25, 2008)
• Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9) Gecko/2008062414 Firefox/3.0
• no JS errors in error console
• addons: CustomizeGoogle (0.72), Delicious Bookmarks (2.0.64), Extended Statusbar (1.2.8), FireFTP (0.98.1), Flashblock (1.5.6), Googlepreview (3.11), Greasemonkey (0.8.20080609.0), Web Developer (1.1.6)
• description: While i'm writing this report in wikiEd, on my wiki site wikiEd doesn't work. I tried all install types, now i'm using greasemonkey.

193.93.72.82 (talk) 12:44, 26 June 2008 (UTC)

Edit cursor lost on preview

WikEd version 0.9.62g

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.1.14) Gecko/20080404 Firefox/2.0.0.14

Whenever you click Preview and then scroll back to the edit box, you find that your cursor position has been lost. When you're editing a long article and frequently want to do previews, this is rather inconvenient, as you then have to spend time finding your place again so as to be able to continue with the editing. You don't get this problem with the standard MediaWiki editor. —Preceding unsigned comment added by 195.188.254.61 (talk) 11:39, 19 June 2008 (UTC)

That was an annoying Firefox bug that has been fixed in the new version, please update your browser under http://en-us.www.mozilla.com/en-US/. Cacycle (talk) 12:33, 19 June 2008 (UTC)

I've now upgraded to Firefox 3.0, but the problem remains. Could it be something to do with the transcluded text I have on the page? —Preceding unsigned comment added by 195.188.254.61 (talk) 10:08, 20 June 2008 (UTC)

Oh, sorry, I misread your report. I will see if I can focus the edit box after pushing the buttons. Thanks for the suggestion, Cacycle (talk) 13:08, 20 June 2008 (UTC)

Implemented in 0.9.63. Cacycle (talk) 05:31, 21 June 2008 (UTC)

One of our technical guys upgraded wikiEd.js to 0.9.64g, but the problem is still there. As before, on a preview, the edit box insists on scrolling its text back to the beginning and losing the cursor position. —Preceding unsigned comment added by 195.188.254.61 (talk) 12:20, 18 September 2008 (UTC)

Is there a chance of this ever being fixed? There's not much point in having a preview if you lose your place in the edit box every time. Such a pity about this glitch - it spoils an otherwise excellent extension. —Preceding unsigned comment added by 195.188.254.61 (talk) 11:20, 11 November 2008 (UTC)

It works for me. Maybe I do not understand what you mean, please describe your problem as detailed as possible, please see the top of this page for relevant information. Thanks, Cacycle (talk) 03:31, 24 November 2008 (UTC)

I've just discovered the "Show preview below" button (the small one with the magnifying glass, next to the main Preview button). If you use this, then there is no problem - the edit cursor position is not lost. It seems that you only get the problem if you use the main Preview button. —Preceding unsigned comment added by 195.188.254.61 (talk) 12:30, 5 January 2009 (UTC)

Bug - <blockquote> does not work as expected

My config:

• wikEd: 0.9.64b

When copying rich text with many paragraphs left-indent, wikEd adds a <blockquote> section.

But <blockquote> needs the <p> mark to break paragraphs. And itallic or bold applies only to the first paragraph instead of the whole section.

The solution would be not to replace <p> marks with <br> marks within <blockquote>.

Another solution would be to use the Poem extension (it adds <br> after each end of line).

To get the left-indent, add this code to poem.php:

    // Add a margin-left "style" attribute.
    if( isset( $attribs['style'] ) ) {
        $attribs['style'] = 'margin-left: 40px; ' . $attribs['style'];
    } else {
        $attribs['style'] = 'margin-left: 40px;';
    }

If you put a '' before the <poem> mark (as wikEd acutally does with blockquote), then the whole quote is itallic. For instance:

''<poem>
Au clair de la lune,
Mon ami Pierrot:

Prête-moi ta plume,
pour écrire un mot.
</poem>

would give:

Au clair de la lune,
Mon ami Pierrot:

Prête-moi ta plume,
pour écrire un mot.

Gabuzo (talk) 11:16, 22 July 2008 (UTC)

Fixed in 0.9.96. Thanks, Cacycle (talk) 04:56, 26 January 2009 (UTC)

Request-JavaScript&CSS syntax highlighting

Could you add syntax highlighting for .js & .css pages in edit mode? The code can be found on one of wikipedias common js pages. Thanks, ManishEarth^Talk 15:13, 14 August 2008 (UTC)

Regular expressions, please

When will WikEd's find/replace feature support regular expressions? I really need to be able to add new lines in replaces). (And I don't have access to a computer upon which I can load AWB.  :( The Transhumanist    19:05, 18 November 2008 (UTC)

Maybe tonight? Cacycle (talk) 19:57, 18 November 2008 (UTC)

I have fixed it, you can use \n for newlines. Cacycle (talk) 04:43, 19 November 2008 (UTC)

Custom settings do not work after latest gadget update

My custom settings used for wikEd do not work anymore after the latest wikEd update, even after a hard refresh. Gary King (talk) 15:08, 17 November 2008 (UTC)

I see you have renamed most of the variables. Do realize that this will break a lot of existing scripts. Gary King (talk) 15:20, 17 November 2008 (UTC)

Sorry for that, I will add a temporary compatibility fix later today so that you have time to change your settings. All you have to do is to consistently change the 'e' in 'wiked' from lowercase to uppercase 'wikEd'. Cacycle (talk) 16:04, 17 November 2008 (UTC)

Yeah I already did it, but I'm just noting that it will probably affect some scripts out there run by people who aren't as familiar with JS. Gary King (talk) 16:16, 17 November 2008 (UTC)

The wikEdWiki class is not working correctly anymore. Some text is wrapped in the class when they shouldn't be. It happens after a reference that closes itself, such as <ref name=test />. Gary King (talk) 17:58, 17 November 2008 (UTC)

I'm using this as a temporary fix, but hopefully it doesn't have to be permanent: wikEdFrameCSS['.wikEdWiki'] = 'color: #000;';. Gary King (talk) 04:04, 19 November 2008 (UTC)

Please could you explain this in more detail with an example text or page so that I can reproduce it. Thanks, Cacycle (talk) 04:54, 19 November 2008 (UTC)

Here Gary King (talk) 15:29, 19 November 2008 (UTC)

I have tested the latest SeaMonkey, Firefox, Safari, and Chrome and in none of them does the text show up in any markuped way, it is just normal unformatted text (the only very minor problem I see is the second ref formatting which should not be wikEdWiki and I will fix that). Which browser are you using? Cacycle (talk) 01:19, 20 November 2008 (UTC)

I am using Firefox 3.0.4 on Mac OS X. The entire text in that link uses the wikEdWiki class, which as set by your script is colored with #0000E0. Gary King (talk) 03:28, 20 November 2008 (UTC)

I think I have fixed it and I am in the process of uploading the new version 0.9.67d. It happened only with the ref hide button pushed. Cacycle (talk) 03:31, 20 November 2008 (UTC)

Alright thanks. My apologies, I forgot to mention that I had the ref hide button enabled because I almost always have it turned on. Gary King (talk) 03:42, 20 November 2008 (UTC)

Spontaneous spaces removal

Hi. I use wikiEd 0.9.67d G with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.0.3) Gecko/2008092417 Firefox/3.0.3. When I click on the edit this page (while editing Kīlauea article) button and then click on Changes button, there are mutliple removed spaces from the beginning of the line between paragraphs and in infobox. In error console are a few tens of errors

Warning: Error in parsing value for property 'color'. Declaration dropped.

Source File: http://en.wikipedia.org/enwiki/w/index.php?title=K%C4%ABlauea&action=submit

Line: 0

and one

Warning: Expected ':' but found '='. Declaration dropped.

Source File: http://en.wikipedia.org/enwiki/w/index.php?title=K%C4%ABlauea&action=edit

Line: 0

--Tomaxer (talk) 22:00, 22 November 2008 (UTC)

This is somewhat strange because the version you edited did not contain those empty lines in the first place. Maybe you actually introduced these lines by pushing the button? The css error messages are not caused by wikEd. Cacycle (talk) 01:57, 24 November 2008 (UTC)

Beyond wikiEd

Today I had time to evaluate the gadget version of wikiEd.

The good news is that it implements highlighting of the embedded citations that make extensively referenced articles very difficult to read in edit mode. I made this suggestion unnoticed last year on an unrelated talk page, so thank you.

The bad news is that wikiEd doesn't solve my fundamental time-wasting problem of constantly reloading a rendered preview so that I can see what I get.

I read the wikiEd help page and the link to What you see is Wiki - Questioning WYSIWYG in the Internet Age (PDF) by Christoph Sauer. He has many good points, but the central notion of deprecating WYSIWYG is not one of them. While formatting may not be durable, it matters locally. It's also an unnecessary dichotomy. WYSIWYG Corel WordPerfect still has the Reveal Codes feature. Why accept less (unless one is a monopoly victim of MS Word)?

The inverse of Reveal Codes is code folding requested above at #Feature request: code folding – but too difficult to implement for wikiEd.

So let's plan beyond wikiEd to the next editing tool – to what I (and many others it appears) really need for "concentrating on the content" in Sauer's words. I need to:

• Usually see the wikified preview when I open the editor.
• Click anywhere and start typing changes, with dynamic format update just like any other WYSIWYG editor.
• Type inline wikicode without a mode shift. When it's complete the code should dynamically fold. (There are several preferences for how exactly how and when it should autofold, but clicking or scrolling away should make it fold immediately. The key issue is how to display a longer unfolded line so that it doesn't jump while typing on it.)
• See and edit wikicoded markups by clicking them to unfold. They should fold after clicking or scrolling away. An option to unfold on mouseover could be useful if the unfolding is by horizontal scroll.
• See and edit wikicoded markups on several lines by Ctrl-clicking them, which makes them stick unfolded for viewing or editing, until they are toggled to fold by again Ctrl-clicking them.
• Have buttons for fold and unfold of all wikicodes, with a preference default for either at opening. The Unfold All button should also reveal hidden text for editing.

Milo 08:12, 23 November 2008 (UTC)

Hi Milo. thanks for your comments, they were a nice opportunity to think about this in more detail... These are the thoughts I came up with:

WYSIWYG does not work smoothly for wiki editing because of the powerful and complex syntactic constructs such as images, tables, templates, parser directives, references, and, actually, any element with an opening tag/closing tag structure. These have long-range non-local effects on the final document that might result in the disappearance of large portions of the text inside such a construct. Therefore, WYSIWYG would only be feasible when you absolutely hide and encapsulate any existing wikicode from editing, e.g. by using separate editing frames or popup forms for non-trivial constructs that require parameters such as images, tables, template, and even simple span or div tags, and guarantee a correct and complete syntax for rendering.

Your proposal to mix WYSIWYG and WYSIWYM (i.e. wiki code with syntax highlighting) does intentionally not encapsulate the code and can therefore not work and will probably result in a confusing visual and conceptual mishmash between two fundamentally different and incompatible approaches. I am almost certain that you will end up with something less user friendly and efficient than using either pure approach alone.

Then we have the technical limitations: Your suggestions are well beyond the current capabilities of JavaScript (e.g. see Mozilla bug 458524 in the orange box on top of this page). It would instead require a locally installed browser-independent external program or a cross-browser capable applet. In either case you would have to program and maintain a huge and powerful editor application from scratch which sounds like a major project, nothing one person alone could possibly do in his spare time.

BTW, you can already see the wikified content by checking "Show preview on first edit" in your editing preferences.

Cacycle (talk) 01:49, 24 November 2008 (UTC)

Possible to use wikEd only when explicitly invoked?

Hi! I love wikEd, the syntax markup makes it so much easier to edit text, especially with a lot of in-line refs. Unfortunately, I guess my computer is a bit too slow – when editing a big page with wikEd, the whole computer freezes for a long while. Therefore, I normally keep wikEd disabled, and enable it when I need it. However, every now and then, I forget to disable it, open up some big edit and there we go... sometimes I have to kill the browser. It would be so cool if you'd be able to make it scale better for big pages, but until then – would it be possible to have an option to always have wikEd disabled, unless explicitly enabled for a specific edit? Is this already possible? Thank you for this very useful tool. /skagedal^... 19:58, 26 November 2008 (UTC)

There are no configuration settings to do that yet, but I will add this to the next release. The slow down is caused by syntax highlighting (?), so disabling this would probably help you without sacrificing the rest of wikEd. I could also try to tweak the code. Please could you provide more background information and details about your speed problem (see top of this page), especially you browser, your type of computer (speed, CPU, age...), and Wikipedia articles where you experience the problem. Thanks in advance, Cacycle (talk) 23:05, 26 November 2008 (UTC)

Of course.

• wikEd version: I use the gadget on English Wikipedia.
• Browser ID: Mozilla/5.0 (Windows; U; Windows NT 5.1; sv-SE; rv:1.9.0.4) Gecko/2008102920 Firefox/3.0.4
• Error messages: (my translations)
  • Varning: Okänd egenskap (unknown property) ”column-count”. Ignorerad deklaration. (Ignored declaration). Källkodsfil (Source code file): http://en.wikipedia.org/enwiki/w/index.php?title=MediaWiki:Common.css&usemsgcache=yes&ctype=text%2Fcss&smaxage=2678400&action=raw&maxage=2678400 ; Rad (line): 33
  • Varning: Okänd egenskap ”word-wrap”. Ignorerad deklaration. Källkodsfil: http://en.wikipedia.org/enwiki/w/index.php?title=MediaWiki:Common.css&usemsgcache=yes&ctype=text%2Fcss&smaxage=2678400&action=raw&maxage=2678400 ; Rad: 50
  • Varning: Väntade sig ”:”, men fann ”=”. (expected ":", found "=") Ignorerad deklaration. Källkodsfil: http://en.wikipedia.org/enwiki/w/index.php?title=Major_depressive_disorder&action=edit ; Rad: 0
  • Varning: Okänd egenskap ”column-width”. Ignorerad deklaration. Källkodsfil: http://en.wikipedia.org/enwiki/w/index.php?title=Major_depressive_disorder&action=edit ; Rad: 0
  • Varning: Väntade sig en deklaration, men fann ” ”. (Expected declaration, found " ".) Hoppar till nästa deklaration. (Jumping to next declaration). Källkodsfil: http://en.wikipedia.org/enwiki/w/index.php?title=Major_depressive_disorder&action=edit ; Rad: 0
• Addons: ChatZilla 0.9.84, Greasemonkey 0.8.20080609.0, Zotero 1.0.7
• Nothing in monobook.js. Gadgets: Navigation popus, wikEd, Twinkle, "Display an assessment..."
• Operating system: Windows XP SP3
• An example of a big enough page to cause the problem is usually Major depressive disorder. It always takes a long time to load the edit, but I do not always experience the "whole computer freezes" thing. I suppose it depends on how much other stuff I have going on.
• Computer is a HP Pavilion (laptop), IIRC 2.5 years old. CPU is "AMD Turion 64 Mobile", 1.79 GHz, 384 MB of RAM.

Thank you for listening, looking forward to the next version then! Disabling syntax highlighting is not really an option for me, since that's pretty much the "killer feature" I use wikEd for. /skagedal^... 09:33, 27 November 2008 (UTC)

The maximal time wikEd uses for syntax highlighting is now 2 s with wikEd 0.9.68 and highlighting will be canceled if it takes longer. It is possible to manually highlight text in smaller chunks. Cacycle (talk) 21:13, 28 December 2008 (UTC)

Wonderful! /skagedal^talk 15:31, 30 December 2008 (UTC)

Installation on another wiki

Greetings,

I want to use WikEd on a mediawiki installation that I have. I have installaed Gadgets on my wiki, however I am unclear on how to make the code for WikEd availabel on my site that users may select it as a Gadeget in their preferences. Can anyone offer me a little help here with the installation?? --Shannara Fan (talk) 02:35, 1 December 2008 (UTC)

The page Wikipedia:Gadget has good instruction on how to install gadgets. Feel free to contact mew if you have more questions. You can copy the code from the the Wikipedia wikEd gadget page. Good luck - Cacycle (talk) 02:53, 1 December 2008 (UTC)

Newbie question: Shortcut keys

I just installed WikEd today, and it seems to work great. I'm only wondering why there are no shortcut keys for the most common functions, such as wikilinks or bold. (At least they're not displayed in the tool tips.) I feel these are so useful for everyone that they should be there by default, especially since it is more ergonomic while your typing than having to navigate (with the touch pad) to the button, and then back to the place you were working at. For that reason, I would also like to have shortcuts for the increase headline and related buttons and for #R, or, come to think of it, for almost all of the in-text buttons. if you feel that not everybody would appreciate it, maybe there is a way I can add shortcuts for myself?

PS: This is strange: Just now I tried alt-shift-o, and it inserted a wikilink. Then I clicked the [T] button, and it selected the whole text (which is not what I would expect from the tooltip), and after that, alt-shift-o does the same. (I'm using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.4) Gecko/2008102920 Firefox/3.0.4.) — Sebastian 20:50, 3 December 2008 (UTC)

I have just fixed the bug that interfered with these access keys. The fix will become available with the next update. Thanks for reporting this. You can define your own access keys but you will lose the Wikipedia predefined ones. Add the following to your monobook.js page:

// define accesskeys for edit buttons (wikEd button number: [key string, JS key code])
var wikEdButtonKey = {
  26: ['b', 66], // wikify
  32: ['g', 71]  // scrolltoedit
};

Check the wiked source code for the required codes and check the wikEd_customization page for more details. Cacycle (talk) 00:10, 4 December 2008 (UTC)

Thank you - that's great! I'll have to look into that. What do you mean by "lose the Wikipedia predefined ones"? Will I not be able anymore to preview with shift-alt-p, or does "Preview" double as WikEd button, and I can repredefine it? Would you, by any chance, have a template that contains all the existing predefined shortcuts? That would save me quite a bit of typing and research work, it seems. — Sebastian 05:41, 4 December 2008 (UTC)

Just check the source code of a Wikipedia edit page for acceskey=" to see the current accesskeys. wikEd uses b, g, and o (the only free ones when I implemented this). Cacycle (talk) 17:21, 4 December 2008 (UTC)

Cool, thanks! — Sebastian 04:00, 5 December 2008 (UTC)

Coding assistence sought: plugin for date delinking and adding metric units

I have a date delinking script: User:Lightmouse/monobook.js/script.js. It has the following options:

• Change linked dates to 'dmy' format. Unlink dates.
• Change linked dates to 'mdy' format. Unlink dates.
• Change all dates to 'dmy' format. Unlink dates.
• Change all dates to 'mdy' format. Unlink dates.
• Add metric conversions.

I would like to turn it into a WikEdit plugin, but it is outside my current skills. Would anyone be willing to help me with the coding? Lightmouse (talk) 10:12, 4 December 2008 (UTC)

Another newbie question: Syntax coloring

I just ran into an unclosed ref tag, and because the syntax seemed correct, I asked at HD. The edit diff is here. I had thought such an important difference would be obvious thanks to the syntax coloring, but it seems to me that this looks normal. Maybe it's that you're using different shades of bluish-gray to express different things? — Sebastian 04:07, 5 December 2008 (UTC)

As far as I can see the syntax coloring works just fine - the unclosed ref tag is treated as normal text. Cacycle (talk) 05:30, 7 December 2008 (UTC)

BUG? - WikiEd not working (version 0.9.67d G (November 19th, 2008)

Hello, my WikiEd does not seem to be working. I was about to send a warning message user:72.148.61.160 for vandalizing this page, however, the WikEd just seems to stop at "data loaded..." with no message added. What should I do? Prowikipedians (talk) 03:15, 7 December 2008 (UTC)

Adding: Time 03:15, 7 December 2008 (UTC)

Browser: Mozilla Firefox, Safari, Internet Explorer

Please describe your problem in more detail, I am not sure what exactly your problem is (see the top of this page for the required infos). Thanks, Cacycle (talk) 05:23, 7 December 2008 (UTC)

Updated Bug Report by Prowikipedians (talk) 05:47, 7 December 2008 (UTC)

Version: WikiEd 0.9.67d G (November 19th, 2008) Safari Version 3.2.1 (525.27.1) Cleared all cache as a user suggested, but nothing worked. All browsers (Mozilla Firefox, Internet Explorers, Safari) all have shockwave/flash installed. No user scripts installed on my monobook.js page Windows XP (and Ubuntu 8.10) Cannot use the warn/arv/etc buttons. 1) Clicked "warn" on user talk page. 2) Only shows "data loaded..." and freezes there. Nothing. Just freezes there.

This sound like a problem with a gadget, please check your Wikipedia preferences -> Gadgets and find out which gadget is responsible for these buttons. Thanks, Cacycle (talk) 18:11, 7 December 2008 (UTC)

Currently working. Hey. It's working now under Linux. Was able to warn this user. Prowikipedians (talk) 12:02, 8 December 2008 (UTC)

WikED produces an unwanted space in the comments field on uploading images, forcing a 'blank' comment

Config:
WikED version: 0.9.67d
Browser: Firefox 3.0.4
Addons installed: Adblock, Flashgot, Greasemonkey, Noscript, Stylish
Using Monaco.js, the only script installed is the install for wikED

Problem encountered:
On uploading an image with WikED enabled, if no comment is inserted in the Summary field, WikED automatically sends a single space as the comment. This results in the parentheses appearing in the recent changes, enclosing a single space.

I tested this with 3 image uploads, and produced the following:

Uploaded image and added a comment in the Summary produced: Username uploaded "Image:filename.png" (comment)
Uploaded image with no comment in the Summary produced: Username uploaded "Image:filename.png" ( )
Disabled WikED
Uploaded image with no comment in the Summary produced: Username uploaded "Image:filename.png"

To make things interesting, with WikED enabled, I went into the upload image window, then clicked on "toggle to standard edit window". This produced the expected standard edit window and put a space followed by a carriage return in the window!

I realize that this is a minor thing, but one of the sysops brought it to my attention, so I thought I'd pass it along. The community involved is wiki.ffxiclopedia.org

Thanks! Ffxiclopedia Catrinm (talk) 04:52, 10 December 2008 (UTC)

Fixed in upcoming release. Thanks, Cacycle (talk) 01:05, 26 December 2008 (UTC)

Fixed in 0.9.68. Cacycle (talk) 19:30, 28 December 2008 (UTC)

Killing leading whitespace

Using the gadget version (0.9.67d G). Reproduce open page (like James Bond (character)) with the HTMLarea and syntax highlighting enabled, then disabled syntax highlighting (leave HTMLarea enabled). Click the diff and notice the leading whitespace is gone now. — Dispenser 19:11, 22 December 2008 (UTC)

Fixed in upcoming release. Thanks, Cacycle (talk) 01:05, 26 December 2008 (UTC)

Fixed in 0.9.68. Cacycle (talk) 19:30, 28 December 2008 (UTC)

When following the steps listed above it continues to remove the leading whitespace using 0.9.68 in Firefox 3.1 Beta 2. — Dispenser 06:38, 7 January 2009 (UTC)

Finally fixed in 0.9.68a. Thanks, Cacycle (talk) 13:49, 9 January 2009 (UTC)

Things from User:Dispenser

• WP:AWB/FR#External to Interwiki for converting those pasted in URLs

  This is problematic because it is Wikipedia-specific. Cacycle (talk) 19:29, 28 December 2008 (UTC)

  Should you be able to use wgServer + wgArticlePath ? Also the regexes at the end are shorter and might be a good inclusion for the fixes button. — Dispenser 06:11, 29 December 2008 (UTC)

• Using [#R] should no longer blank the edit summary since we now have WP:AES

  This is also Wikipedia-specific and there is no reason to use that fallback instead of the wikEd-generated summary. Cacycle (talk) 19:29, 28 December 2008 (UTC)

  No, just MediaWiki specific. Since wikEd fills it automatically in and fails to trigger the blank summary warning when a user hasn't touched it. — Dispenser 06:11, 29 December 2008 (UTC)

  It is a new addition and most MediaWiki installations do not have it yet. Beside that I do not see a reason to use that empty summary fallback mechanism when we can automatically fill in the summary. Cacycle (talk) 08:40, 29 December 2008 (UTC)

• WP:AWB/FR#Regex checker, so I don't constantly do /| cell/

  I will think about an error flag, but this will not help you with syntactically correct regexps.

  I was think just coloring the back of the text box #F6DFE0 for errors and #FFF8DC for warning. Sample idea code:

function checkRegexp(text) {
    window.status = "No error detected"
    try {
        if(text == '')
            return 0
        re = new RegExp(text)
        if(''.match(re)){
            window.status = "Empty string matches";
            return 1
        }
        if(' \r\n\t'.match(re)){
            window.status = "Matches white space";
            return 1
        }
        return 0;
    }catch(e){
        window.status = "Compiling error"+e;
        return 2;
    }
}

• http://www.pml.ac.uk/biomare/sites/Darß-Zingst.htm is incorrectly highlighted (listed at WP:linkrot) as I tried to point out before character \u007f-\uffff are valid in URLs. I use three regexes in my Checklinks tool: brackted link, free link, free link contain '('.

  Fixed in 0.9.68. Cacycle (talk) 19:29, 28 December 2008 (UTC)

  Isn't it a little excessive to define every character, for reference here's the MediaWiki regex

// Line 133-134, Parser.php
        $this->mExtLinkBracketedRegex = '/\[(\b(' . wfUrlProtocols() . ')'.
            '[^][<>"\\x00-\\x20\\x7F]+) *([^\]\\x0a\\x0d]*?)\]/S';

• The table button should be producing class="wikitable" border="1" per Wikitable borders without CSS

  Added in 0.9.68. Cacycle (talk) 19:29, 28 December 2008 (UTC)

Mostly fixed in upcoming release. Thanks, Cacycle (talk) 01:06, 26 December 2008 (UTC)

Fixes and suggestions added to in 0.9.68. Cacycle (talk) 19:29, 28 December 2008 (UTC)

does not work with other wikipeida preferences page serif pref

If you choose serif (or is it sans?) in your preferences page wikied is still monospace. how can i change the font from monospace?

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.0.5) Gecko/2008120122 Firefox/3.0.5 latest version from wikipedia pref page

Add the following code to your monobook.js and change to your preferences: Cacycle (talk) 01:04, 26 December 2008 (UTC)

var wikEdFrameCSS = {};
wikEdFrameCSS['.wikEdFrameBody'] = 'background: #FFFFFF; margin: 0px; padding: 0.2em; overflow: -moz-scrollbars-vertical; overflow-x: auto; font-family: monospace;';

Documentation bug

On User:Cacycle/wikEd.js, it says: "5. Optional: customize the program by adding user settings to your ''''' page". This should be monobook.js, no? /skagedal^talk 15:31, 30 December 2008 (UTC)

Yes, it should be monobook.js, I will change that for the next release. Thanks, Cacycle (talk) 16:12, 30 December 2008 (UTC)

Fixed in 0.9.68a. Thanks, Cacycle (talk) 13:48, 9 January 2009 (UTC)

xcen > de

Insertion of "xcen > de" on each "save page", "preview"

I'm using wikEd via Greasemonkey on my local mediawiki. Each time I press the Save Page or Preview button when editing a page somebody inserts automatically a line containing xcen > de on the top of the edited page (the more I press the buttons the more lines will be inserted) Disabling wikEd by disabling greasemonkey, the standard Save or Preview buttons of Mediawiki work as expected: no unwanted lines are inserted ...

What's going on? Who inserts those unwanted lines and why? Probably you will see those lines on top of this page due this behaviour ... ;-)

I cannot reproduce this. Please could you fill out a full bug report (see top of this page). Thanks, Cacycle (talk) 15:02, 7 January 2009 (UTC)

a bug about followLink ? and a suggestion

i am in korean translation. while editing, for example, when i put a mouse on the

[[Image:filename|thumb|150px|explain]]

then popup shows "Imagefilename (ctrl-click)" i think "Image:filename" is right than "Imagefilename" check it please. and it would be nice that HighlightSyntax could be always being updated. --Ilovesabbath (talk) 19:48, 8 January 2009 (UTC)

I have fixed this in the current release (0.9.68a). Unfortunately, automatic syntax highlighting is not possible at the moment, please see User:Cacycle/wikEd_help#Automatic_syntax_highlighting. Thanks, Cacycle (talk) 13:47, 9 January 2009 (UTC)

What i hate most about my wonderful WikEd

1. Hides a cue i've spent 5 years getting used to using: when the Subject/headline pane is above the edit one, anything you add after the section heading changes the heading, but when it's below, you can put lots of info that appears only in the edit history. (Or rather, that's how i'm used to it working, so i get reminded bcz i've saved a verbose & unsuitable hdg.)
   --Jerzy•t 07:06, 13 January 2009 (UTC) Late sig
   

   Please could you explain this in more detail, I do not recognize this feature. Is it a non-native user script function? Cacycle (talk) 14:30, 13 January 2009 (UTC)

   • Surely i've just described it badly. The situation is creating a new section with the "new section" tab on a talk page, which with my prefs appears as a "+" tab. With the WikEd gadget absent from my prefs, this produces in relevant part (using a handy talk page [wink]):

   Editing User talk:Cacycle/wikEd (new section)
   From Wikipedia, the free encyclopedia
   This is a talk page. Please respect the talk page guidelines, and remember to sign your posts by typing four tildes (~~~~).
   Subject/headline (Single-line editing pane)
   (Good-sized
   
   rectangular
   
   editing
   
   pane)
   Content that violates any copyright will be deleted. Encyclopedic content must be verifiable. You irrevocably agree to release your contributions under the terms of the GFDL*.
   (Check box) This is a minor edit (what's this?) (Check box) Watch this page
   ("Save page", "Show preview", and "Show changes" buttons ) Cancel | Editing help (opens in new window)
   Do not copy text from other websites without a GFDL-compatible license. It will be deleted.

   Adding something to each pane and hitting Preview adds something like

   Preview
   

   Remember that this is only a preview; your changes have not yet been saved!
   

   test
   

   aksfjasfjdaklj ljkdflaksfj; lksdfjl;askdfj ljkslf;djka

   above the one-line pane, and a line like

   Subject/headline preview: (→test: new section)

   between the two panes.

   With the WikEd gadget pref'ed on (and even with its toggle set to "classic text area"), the + or "start new section" tab has the same result, except that the WikEd 5x2 set of buttons above the good-sized pane at the right, and i think a few other buttons below it appear. But when text is added to both boxes and a preview is requested,

   1. the non-WikEd layout as previously described briefly appears (including the one-line pane replacing the 5x2 set of buttons), then
   2. the 5x2 set replaces the one-line pane, and
   3. a "Subject/headline" one-line pane appears below the good-sized pane, and
   4. the "Subject/headline preview: (→test: new section)" line is now below both the good-sized pane and the "Save..., Preview,..." row of buttons.

   I consider this a design fault bcz the wording difference ("Subject/headline" vs. "Edit summary (Briefly describe the changes you have made)) quickly becomes invisible to a regular editor, while the difference in position remains a highly visible and effective cue of the difference between the "Subject/headline" and "Edit summary" panes.
   That difference is: The contents of the former become both the section heading and (i think suffixed by "new section") the edit summary. The latter begins with the existing section heading which (if not edited or removed) becomes the intro for the edit-specific summary that courteous editors add. A long contrib on a talk page with WikEd gadget-selected invites the editor to put the desired section name in the box, but later (despite the absence of the similarly invisible /* ... */ formatting) construe it as an existing section being updated and deserving an edit-specific summary. (The result of this error is creating a heading that looks like an edit summary. IMO, the normal positioning should be the default; of course i will be delighted to use any config param (whether well or under-documented) to restore normal positioning.
   --Jerzy•t 23:57, 16 January 2009 (UTC)
   

Fixed in upcoming release 0.0.73. Cacycle (talk) 05:09, 7 February 2009 (UTC)

• If your own completion of edit summaries is more structured than mine, you may find dramatic evidence, in my preceding one on this page, of how visual a summarization style some experienced editors may develop: not being sure how far i would get in that edit, i acknowledged the pseudo-forgery i was doing (i.e., i supplemented the section title with "Remedy insertions into signed contrib"), which had the result that my eye was satisfied that i'd entered a summary, and i saved without noticing i'd made no mention of the substantial part of the edit, namely providing you the further info you requested.
  --Jerzy•t 19:45, 17 January 2009 (UTC)
  

1. Navigation popups' edit-pane lk'd-article previews don't work, so i have to click preview and hover in the page preview links to preview the lk'd articles.
   

   What is "lk'd-"? Cacycle (talk) 05:09, 7 February 2009 (UTC)
   

2. If i start typing as soon as the edit pane opens, it disappears from where i put it (and then may show up in an unexpected place, maybe not to be noticed until after i've saved, even if i preview with attention to the part that i intended to change). And the delay until it's safe is frustrating. (Even when i have WikEd suppressed via the edit page control.)
   --Jerzy•t 07:06, 13 January 2009 (UTC) Late sig
   
   • Does this still happen with the newest version? Cacycle (talk) 14:30, 13 January 2009 (UTC)
     • I de-pref'd WikEd today, did some experiments, and re-pref'd it, which i would assume suffices to ensure it's the newest. I saved a long chunk of text (bcz my first attempts didn't give enuf delay to position the cursor & type in. I clicked edit, positioned the mouse cursor where the middle of the edit box would open, clicked once only on the edit box and immediately after, hit the space bar. The result was a blank inserted at the start of the edit box, and the last half of one line and first half of the next highlighted, indicating to me either an unsolicited change of cursor position or mis-sequencing of the mouse click and keystroke. However, i think i have seen such mis-sequencing on this hardware & Win-version, when the system was otherwise responding to input slower than i could input (perhaps virtual-memory bound?) but not during an edit-window "load-up", and it may be a matter of WikEd being the thing that most reproducibly exercises a weakness that it is not responsible for. Could the old Win have such a vulnerability?
       --Jerzy•t 23:57, 16 January 2009 (UTC)
       
3. Altho the case-change button works better than Navigation popups' magnifying-glass/cC-buttons case-change button, the mag-glass button stops working and the WikEd search/repl facility has never made me confident enuf that i'm using it right that i rely on it (rather than switching WikEd off to search & repl).
   --Jerzy•t 07:06, 13 January 2009 (UTC) Late sig
   

   What's the problem with wikEd search and replace? Cacycle (talk) 14:30, 13 January 2009 (UTC)

   • I'll continue to investigate whether i'm just still in the initial overwhelm-ment phase of responding to unfamiliar icons & a large set of intimidating surrounding icons. But in using it more, in an attempt to become more articulate abt it, i do note that the default seems to be selecting the first or next occurence of the from-string -- and thus treating change-all as "change next instance" when "Replace all matches in whole text or selection" is used, unless user clicks the good-sized pane again to de-select.
     --Jerzy•t 23:57, 16 January 2009 (UTC)
     

4. Switching WikEd on (or off?) clears the selection of text within the edit pane.
5. Hmmm, nagging worry that the wiki-page i originally created (to get Pop-up tools before it was a gadget) is screwing things up now that i have the gadget turned on.
   --Jerzy•t 07:06, 13 January 2009 (UTC) Late sig
   

   Try to empty your now useless User:Jerzy/monobook.js page and see if things get better. Cacycle (talk) 14:30, 13 January 2009 (UTC)

   • Done, and that may have at least speeded things up. But i'm not yet willing to treat the Zocky tool as "useless", in light of my tendency to alternate between automated replacements and viewing lk'd pages (via Pop-ups, which remain functional when WikEd is pref'd but toggled off, and thus save need for intervening preview refreshes).
     --Jerzy•t 23:57, 16 January 2009 (UTC)
     

• And is it WikEd that makes long-summary previews fail to word-wrap?
  --Jerzy•t 07:20, 13 January 2009 (UTC)
  
  • Please explain in more detail. Thanks, Cacycle (talk) 14:30, 13 January 2009 (UTC)
    • Will do, tho not before the pending save.
      --Jerzy•t 23:57, 16 January 2009 (UTC)
      
    • It is indeed WikEd (or combining it with "A clock in the personal toolbar...", which feels too far-fetched to explicitly test!) that has this effect, which i now describe in detail:
      Immediately below the single-line pane labeled "Edit summary" there appears the wording "Preview of edit summary" which is followed, usually on the same line, by a representation of how the summary will be rendered in edit histories and the like. With WikEd un-Pref'd, a long summary (i presume any that when preceded by "Preview of edit summary" renders wider than the good-sized edit pane) is "word wrapped" into a two-line form that can be read without scrolling to the right. With WikEd in my prefs (whether the WikEd toggle is set to "classic text area" or not), a sufficiently long rendering instead extends in the window further right than anything else (except for the monobook "wallpaper-like" background graphic).
      It may be important to mention that while my Prefs page is exactly the width of the screen, my edit page is wider than the screen (which barely accommodates the good-sized edit pane), even tho what is off the screen to the right (with the window maximized in the default state where the left edge of the page is at the left edge of the screen) is normally only the wallpaper. With WikEd Pref'd, the wallpaper is overlaid by any excess length of the rendering of the summary. If the edit summary renders wider than the minimum edit-page width (which as stated is more than the screen width), it controls the width of the page: the close-paren in that rendering is against the right edge of the page.
      --Jerzy•t 19:45, 17 January 2009 (UTC)
      

The summary preview is not a standard feature on the English Wikipedia. Please could you tell me which wiki you use or which extension, user script, or gadget is responsible for it. Thanks, Cacycle (talk) 13:42, 2 February 2009 (UTC)

Globally relevant details

1. Thanks for the quick response to my casual kvetching, which shifts me into a much more serious attempt to optimize all of this; sorry i'm so slow in responding.
2. Plz accept my restatement: i am very pleased to be a WikEd user, whether or not the above gets fixed, bcz what i dislike is easily worth the current downsides.
3. I've now blanked my monobook.js, which had the Pop-ups (redundant to Gadget installation), and Zocky SearchBox (even tho it has some small advantages).
4. User:Cacycle/wikEd gadget version seems to say i'd been on 0.9.68a for several days before i left my note, and i presume on 0.9.68 for a week and a half preceding. Observations i henceforth report here are as of the timestamped UTC day unless stated otherwise. I'll be surprised if i ever use other than the gadget installation on :en: WP, and i'll mention it if i give you any observations from other wikis.
5. I am currently using Firefox 3.01 on Win 2000 v. 5.0 SP4. If Win version matters, say so, bcz it is presently subject to promiscuous change.
   --Jerzy•t 23:57, 16 January 2009 (UTC)
   

Color highlighting

How would I go about changing the colors used to highlight the text? That's a really nice program that you made!

WriterHound (talk) 03:13, 14 January 2009 (UTC)

Please check User:Cacycle/wikEd_customization and the top of the source code. Cacycle (talk) 04:21, 14 January 2009 (UTC)

Bug - probably fix space before punctuation

There is a bug, probably in the fixing of spaces before puncuation. I'm using the latest version of the program and the latest version of Firefox. When there is an image, it puts a space before ".jpg" or ".gif". It also puts a space before ".html" in external references. Example, see my recent edit to My 60 Memorable Games. Bubba73 (talk), 04:25, 14 January 2009 (UTC)

I might improve this sooner or later. Until then, make sure to check your changes :-) Thanks, Cacycle (talk) 02:56, 26 January 2009 (UTC)

I have now improved this fixing function in version 0.9.71 so that punctuation characters in article titles, file names, web links, and character entities are not changed. Cacycle (talk) 03:18, 2 February 2009 (UTC)

Request for script audit as a potential Gadget

Hi, I've proposed a script I wrote as a potential Gadget at Wikipedia:Gadget/proposals#Add_the_.22Localize_Comments.22_script. As a Gadget writer, could you check it out when you have time and audit the script, and post your thoughts on whether it should be a Gadget or not? Thanks in advance! Gary King (talk) 16:54, 16 January 2009 (UTC)

Inserting/deleting newlines spuriously

It appears that wikEd sometimes inserts or deletes a newline in the edit window. Typical scenario is as follows:

1. you copy and paste something in the edit window
2. you see that there is e.g. one empty line in the edit window
3. after you save the changes and edit the article again, you find out that there are two empty lines (or no empty lines) where there used to be one

This happens in Google Chrome, never in Firefox. Do you know what might be the reason? I'm suspecting a Webkit bug... GregorB (talk) 22:38, 18 January 2009 (UTC)

Funny, it happened without a copy/paste, just as I was writing this. See the diff to the previous edit. GregorB (talk) 22:40, 18 January 2009 (UTC)

When pasting rich text it is not always easy to see the number of line breaks. Push the or button to remove the original formatting of your pasted text. I could not reproduce your problem in Chrome, please provide a detailed how-to so that I can reproduce it. Thanks, Cacycle (talk) 00:26, 19 January 2009 (UTC)

Here's what "works" for me:

1. Open e.g. this page in a new tab.
2. Type #<Enter>#<Enter>#<Enter>
3. Click on "Preview" (or on ).
4. "#" characters from the step 2 are now separated by empty lines

The same happened with the numbered list items from my edit as I was writing it. :) GregorB (talk) 17:01, 19 January 2009 (UTC)

Confirmed -- this also reproduces the bug on Safari. Viktor Haag (talk) 13:29, 22 January 2009 (UTC)

I also echo the suspicion that this may be a WebKit issue: this behaviour also happens to me when using wikEd on Safari (Safari 3.2.1/5525.27.1 running on Mac OSX 10.5.6 on a Dual2 PPC G5). This is not limited to pasting rich text for me. This happens to me during the normal course of editing a page, and usually seems to be clustered around lines with headings and/or templates in them. Unfortunately, it doesn't seem to me to be entirely reproducible or predictable. Viktor Haag (talk) 13:54, 19 January 2009 (UTC)

Maybe it is a Mac-only problem. GregorB: please could you fill out the bug report form on the top for your system information. Thanks, Cacycle (talk) 14:46, 22 January 2009 (UTC)

Here it is:

• WikEd version: 0.9.68a
• Browser id: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/525.19 (KHTML, like Gecko) Chrome/1.0.154.43 Safari/525.19
• Console errors: none (hope I'm getting it right: ctrl-shift-J window)
• Add-ons: none
• User scripts: none
• OS: Windows XP SP3

• Problem and steps to reproduce: as described above

Apparently not Mac-related... GregorB (talk) 15:29, 22 January 2009 (UTC)

Thanks, I can now reproduce this and will try to fix this as soon as I find the time. Cacycle (talk) 02:55, 26 January 2009 (UTC)

Safari and Chrome use <div>...</div> tags for linebreaks instead of <br>. I have no idea why they do this. It seriously messes things up and there is no easy workaround for it other than using browser detection as far as I can see :-S Cacycle (talk) 04:29, 27 January 2009 (UTC)

Divs are inserted indeed; this behavior can be seen at e.g. http://www.kevinroth.com/rte/demo.htm. I could not find this reported at http://code.google.com/p/chromium/issues/list - which is a bit odd, since one would expect this to hurt other rich text editors too. It's probably a some sort of WebKit misfeature. I'm currently doing 25% of editing in Chrome, 75% in Firefox. This could force me back to 100% Firefox - no big deal perhaps, but still... GregorB (talk) 09:36, 27 January 2009 (UTC)

I have probably fixed this with browser detection in 0.9.71. Please report back if you still experience problems related to this. Thanks, Cacycle (talk) 03:15, 2 February 2009 (UTC)

Just found this thread. This is still happening to me (Feb 4, Chrome/WinXP). First it deletes the breaks[3], then inserts too many.[4] I've turned off wikEd and it works fine. Incidentally, in Chrome misspelled words are only highlighted when wikEd is turned off... don't know if you aware of this or not. NJGW (talk) 07:08, 5 February 2009 (UTC)

It works fine for me with Chrome >= 1.0.154.43 / WinXP. Please could you fill out the full bug report form on top of the page so that I can reproduce your problems. Missing spellcheck is a browser problem not related to wikEd. Thanks in advance, Cacycle (talk) 04:53, 19 February 2009 (UTC)

Unfortunately, the problem persists for me in 0.9.73a (i.e. I can still reproduce it from steps given above). My version of Google Chrome is now 1.0.154.48, and the rest is the same (Win XP SP3, etc.). GregorB (talk) 09:07, 19 February 2009 (UTC)

I still have the problem here as well. Using Safari 4 5528.16, with default user agent (which I assume is Safari Public Beta - Mac), with 0.9.76b (built Mar 29/09). If I insert a new line in front of a paragraph (on the same line just before its first character), the newline seems to stick around. If I try to insert a newline by adding it to the end of the preceeding paragraph, it appears to get deleted. Viktor Haag (talk) 15:54, 30 March 2009 (UTC)

The problem still seems to exist with same version of Safari as my last report, and with 0.9.78G (build April 26/2009). Viktor Haag (talk) 16:31, 28 April 2009 (UTC)

Please be as specific as possible so that I can reproduce your problem - what do you mean by "sticking around" and when does it "appear to get deleted"? Do you also experience the Safari bug that turns the text blue after pushing the [T] button? Cacycle (talk) 20:53, 28 April 2009 (UTC)

The first thing I tried in the new Google Chrome (2.0.172.28) was the four-step process to reproduce the problem described above. WikEd is 0.9.78 at the moment. Unfortunately, the behavior is the same... GregorB (talk) 09:52, 22 May 2009 (UTC)

I too have tried 0.9.79c with the four-step process above with Safari (v4 Public Beta on Mac), and the behaviour is still the same, as with Google Chrome. Here is a process to describe the problem I'm seeing on Safari in addition to the test listed above:

1. Open e.g. thispage in a new tab.
2. Type "== This is a heading ==" on the top line of the text box (line one).
3. Type "This is some plain text following the heading." on the very next line (line two).
4. Click "Preview" : the text in the editing window changes so that there's a newline inserted above the heading text and between the heading text and the line of plain text.

This is what I mean by "spurious newlines". Viktor Haag (talk) 14:20, 27 May 2009 (UTC)

With WikEd 0.9.80 G, running on Safari Version 4.0 (5530.17), this behaviour is partially fixed; from the immediately preceding example, now there's a newline inserted between the heading text and the line of plain text, but no extra line inserted above the heading text. Viktor Haag (talk) 19:32, 15 June 2009 (UTC)

Ditto for Chrome 2.0.172.33 (Win XP), wikEd 0.9.83a. Unfortunately this is still enough for me to refrain from using Chrome. GregorB (talk) 09:22, 29 June 2009 (UTC)

2 vars not working?

I'm using 0.9.68a on FF3 - Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.0.5) Gecko/2008120122 Firefox/3.0.5

I don't have any other JS tools in my monobook.js nor using Gadgets.

I've been using wikEd ever since I registered for wikipedia and it's a great tool. Only today did I learn that I could customize it so I read the manual and made a few changes.

Most of the tweaks in my monobook.js worked, but 2 of them didn't:

var wikEdButtonsOnTop = false; var wikEdButtonBarFindHidden = true;

The toolbars are still above the edit box and the find bar isn't hidden.

Is this a bug or am I doing something wrong?

Thanks. This is a really useful tool! --Armchair info guy (talk) 02:39, 19 January 2009 (UTC)

The two variables no longer exist. I am curently preparing a complete and updated list. Thanks, Cacycle (talk) 02:50, 26 January 2009 (UTC)

Thanks for replying. I should've searched the code first. I see that cookies are used for the Hidden and that the Top feature no longer exists. Just curious - why is the top feature gone? --Armchair info guy (talk) 09:04, 11 February 2009 (UTC)

can wikEd automatically scroll to the preview/change box and move focus out of edit box?

Me again. I'm wondering if wikEd can automatically scroll to the preview/changes box when I press either button. I know I can do it with the separate buttons on the tooblar at the right side of the screen, but it'd be more convenient to do so automatically.

Also, it'd be great if the browser focus switches out of the edit box and onto the page when I press preview/changes, so that when I hit spacebar it's a browser page down scroll instead of adding an undesired text space. Probably been dozens of times I've had this happen and then I have to click outside the edit box to change focus.

Thanks again. --Armchair info guy (talk) 02:52, 19 January 2009 (UTC)

I have fixed the intelligent scrolling function in 0.9.71, depending on your window scrolling position it will scroll to the buttons, the edit field, or the preview field. Unfortunately, changing the focus would come surprising for most users and would probably cause more problems than leaving it as it is. Thanks - Cacycle (talk) 03:04, 2 February 2009 (UTC)

The new rev doesn't properly scroll down to the preview/changes box. It only scrolls down a fraction of an inch. So it appears to be doing some sort of scroll down but effectively it's nothing. What I'd like it to do is basically a standard "page down" scroll, since wikEd & toolbars fit nicely within the screen.

And if this "page down" scroll is implemented, I need to reiterate that window focus should transfer out of the edit box. Most sections/pages I edit are longer than an entire screen, so I need to scroll down even further to verify my edits. And to take it one step further, using the existing scroll buttons on the right-side toolbar should also transfer window focus: pressing "down" should transfer focus to the main page but "up" should put the focus in the edit box. It would make wikEd cleaner and more efficient. I suppose existing users would be "surprised" by this new feature but I'm confident most/all would prefer it.

Thanks again for your active maintainance of wikEd and responses here. --Armchair info guy (talk) 04:23, 10 February 2009 (UTC)

The final scrolling position depends on were your current scrolling position is. If you are lower than the middle of the edit box it will scroll down to the preview/diff box. Focusing into the preview/diff box is not a good idea as you will lose the caret (cursor) position. Most people would not want that for the small benefit of being able to use the space bar shortcut that most people are not even aware of. But thanks for the suggestions! :-) Cacycle (talk) 20:05, 10 February 2009 (UTC)

Thanks for explaining the design decision. I definitely take spacebar scrolling for granted. But, could you add this feature with a var default to false? Those of us who use spacebar scrolling would surely appreciate it ;)

Also, I'd like to know more about how wikEd looks at "current scrolling position". If it's variable (which I hope) I'd like to set it to the top of the screen to always snap to the preview/changes box. Otherwise, if hardcoded, where/how can I tweak it? (I know very little about DOM,javascript,etc. so the newbie version is appreciated) Thanks! --Armchair info guy (talk) 09:02, 11 February 2009 (UTC)

bug with AWB's RegExp - capitalizing every word beginning with "th"

My 3rd topic in a row. I also added AWB's RegExp button (one of the monobook.js var additions that worked properly, in reference to my first topic). I tried it out and it capitalized every word beginning with "th" - the, them, they, etc. Obviously a bug since most shouldn't be. I assumed it was a bug with RegExp and filed a bug over there but one of them replied that the problem was likely in wikEd.

I have no idea one way or the other. Just reporting it here so you guys can get to the bottom of it. Thanks! --Armchair info guy (talk) 04:08, 19 January 2009 (UTC)

ThaddeusB was right about the case sensitive thing. I will correct this in the next release. Thanks, Cacycle (talk) 13:02, 19 January 2009 (UTC)

Fixed in 0.9.69a. Cacycle (talk) 04:55, 26 January 2009 (UTC)

Paste from Word?

Perhaps this isn't a bug and I'm doing something wrong or my system isn't fully supported, but I can't discern that from the documentation.

• WikiEd v0.9.68a (appears to be latest)
• Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.0.5) Gecko/2008120121 Firefox/3.0.5
• FF Error Console is has no errors or warnings
• AddOns: FlashBlock, AllInOne Gestures, GMail notifier, Web Developer
• User scripts: none
• OS: Mac OS X 10.4.11
• Word X for Mac Service Release 1

I'm trying to get copy from Word to MediaWiki with formatting intact. I'm trying an extremely minimal test case: in the Word document are three words, each on their own line. One is normal, one is bold, and one is italic. When I copy/paste into WikiEd, I get the three words with no formatting. When I click the [W] button, the text I just pasted is selected but otherwise nothing happens.

Am I missing a step, is my software combination unsupported, or did I actually find a bug? —Preceding unsigned comment added by 209.240.239.188 (talk) 17:20, 19 January 2009 (UTC)

Strange, after pasting the formatting should remain as in Word. Maybe something is still strange on Mac. Unfortunately, I do not have an Apple and cannot test this. Do you see the normal syntax highlighting? Cacycle (talk) 23:36, 19 January 2009 (UTC)

I get syntax highlighting on wiki-formatted text (like if I edit the main page). I do not get syntax highlighting on what I paste from Word. I can verify two possibly useful bits of information: when I copy text in Word for Mac, it does go to the OS level clipboard rather than an internal, app-specific one, and formatting is preserved.

I also found formatting - at least the basics that I've tested - are preserved in Safari. I suspect the problem has more to do with FF's handling of the OS X clipboard than anything WikiEd is doing. If you can point me in the right general direction where clipboard handling is in the code (and how to run a local copy instead of sourcing it off wikipedia), I'd be willing to look for a Firefox workaround. —Preceding unsigned comment added by 209.240.239.188 (talk) 15:29, 20 January 2009 (UTC)

wikEd completely relies on the browser's internal editor and I have no idea about that Firefox code. Here is a rich text editor on the web (good for testing such issues): http://www.kevinroth.com/rte/demo.htm. On User:Cacycle/wikEd_development there is a description for setting up a local test environment for wikEd (somewhat complicated). Thanks, Cacycle (talk) 05:29, 21 January 2009 (UTC)

Could you please file a bug report at http://bugzilla.mozilla.org/ stating that under Os X only plain text, not rich text is pasted from Word into the Firefox editor Midas. Thanks, Cacycle (talk) 13:26, 21 January 2009 (UTC)

There is already a Firefox bug report: bug 428096. Cacycle (talk) 14:25, 27 January 2009 (UTC)

Spacing and punctuation at references

I have a suggestion for a new feature. Could you program wikEd to repair spacing and punctuation placement at references? Some examples below:

• Wikipedia is an encyclopedia<ref>reference</ref>. (punct. at end)
  
• Wikipedia is an encyclopedia. <ref>reference</ref> (extra space)
  
• Wikipedia is an encyclopedia <ref>reference</ref>. (extra space and punct. at end)
  
• Wikipedia is an encyclopedia.<ref>reference</ref>. (duplicate punct.)

It should read:

• Wikipedia is an encyclopedia.<ref>reference</ref> It is really thorough.
• Wikipedia is an encyclopedia;<ref>reference</ref> it is a wiki.

See: Manual of Style.

This feature could detect certain end of sentence punctuation . ? ! and place it before the reference(s), then remove any extra space(s). It would also remove extra spaces before references in the middle of a sentence; none before and only one space after the reference. One space would be preserved or added as necessary at the end of each reference. Duplicate punctuation at the end of a reference would be removed.

Thank you for your consideration and nice work here. ~ All is One ~ (talk) 00:52, 20 January 2009 (UTC)

Thanks for the suggestion, I will probably add this when I find the time. Cacycle (talk) 02:46, 26 January 2009 (UTC)

But then, this is probably an English Wikipedia specific convention, it might be different in other languages and other wikis. Cacycle (talk) 13:30, 29 January 2009 (UTC)

Creating tables

Will this WYSIWYG editor allow for an easy method of creating tables? I'm trying to find an editor for my wiki that will help users create tables easier than the standard wiki markup. Thanks! --Brandon (talk) 16:04, 21 January 2009 (UTC)

Let me take the liberty of answering the question... A single click on the wikEd's "Table" toolbar button produces this:

caption

heading	heading
cell	cell
cell	cell

It beats typing. :-) GregorB (talk) 16:49, 21 January 2009 (UTC)

wikEd is also almost set up to switch between WYSIWYG-like table editing and wikicode... Cacycle (talk) 00:02, 22 January 2009 (UTC)

Try var wikEdShowTableModeButton = true; on your monobook.js page... Cacycle (talk) 14:43, 22 January 2009 (UTC)

(Works currently only with pasted html tables). Cacycle (talk) 03:00, 2 February 2009 (UTC)

EditEnhancements conflicts with WikEd

Config:
WikED version: 0.9.68a
Browser: Firefox 3.0.4
Addons installed: Adblock, Flashgot, Greasemonkey, Noscript, Stylish
Using Monaco.js

Recently, wiki.ffxiclopedia.org installed a new extension "EditEnhancements" from MediaWiki. The expected result is that the "Save", "Preview" etc. buttons now appear on a bar which sits at the bottom of the view area, and scrolls up and down as the view area changes so as to always sit at the bottom of the view area. The Special:Version lists this as: EditEnhancements (Version 1.0) Christian Williams and Maciej Brencz

With WikEd enabled, it doesn't work as expected. The result is that directly below the edit window I only have the "save" button. I have to drop out of full page edit mode to find the preview button which, along with several other bits and pieces, are now in a fixed position further down the page. There is all sorts of unexpected behaviour from this. As one example, on the FFXI site, the space below the "save, preview, changes" buttons is used for a table containing some commonly used wiki markup shortcuts. Closing the preview pane from the WikEd button simply toggles this on and off and doesn't affect the prefiew pane at all! With WikEd enabled, "save" button remains in place while the "preview" and "Changes" buttons are moved to below that table, so I have to hit ctrl-end (end of page) to get to them!

A preview of this can be achieved on this page by editing the text, then scrolling below the edit box. Imagine the "preview" and "Changes" buttons now appear below the line that starts "Once you click the Save button..." and the "Do not copy text from other websites without ...." line has moved down there with them, leaving the "Copy and Paste" table in place. I can provide screenshots if required, just let me know!

Thanks for your attention to this :) Ffxiclopedia Catrinm (talk) 08:14, 22 January 2009 (UTC)

As a workaround add var wikEdNoRearrange = true; to your monobook.js page. Cacycle (talk) 02:45, 26 January 2009 (UTC)

can't insert non-breaking-space correctly in German Wikipedia

steps to reproduce:

1. switch to German Wikipedia, this bug does not occur on en.wikipedia
2. enter text, example: 22 km
3. place cursor (|): 22|km
4. click &nbsp; and you get &22kmnbsp; instead of 22&nbsp;km

using

• wikEd 0.9.68a Deutsch
• Firefox 3.0.5

Matthias M. (talk) 18:26, 28 January 2009 (UTC)

There is neither a &nbsp; button in wikEd nor is there such an extension on your monobook.js page. Please could you specify what button one has to push. Thanks, Cacycle (talk) 18:50, 28 January 2009 (UTC)

Hello, I hope you understand my bad english: The Button &nbsp; is part of the normal edit window for Articles und discussions in the german wikipedia. If wikEd is switched on, then the malfunction, discribed by Matthias M., happens. I myself reported this malfunction to Matthias M., he is the translator of the german GUI. Nice day --Astrobeamer (talk) 19:17, 28 January 2009 (UTC)

Ah, I see, it is one of the links  under the edit  area. Cacycle (talk) 22:08, 28 January 2009 (UTC)

It has to do with this workaround at the German Wikipedia: de:MediaWiki_Diskussion:Edittools/Archiv#nbsp-Probleme. Please tell them to switch to the MediaWiki:Edittools.js system that is used on the English Wikipedia. Cacycle (talk) 23:07, 28 January 2009 (UTC)

As far as I can tell, somebody was working on it but did not make the final edit: de:MediaWiki_Diskussion:Edittools/Archiv#Edittools_durch_dynamisch_ladbares_Skript_ersetzen. Cacycle (talk) 13:26, 29 January 2009 (UTC)

I put a message to de:MediaWiki_Diskussion:Edittools#zu_en:MediaWiki:Edittools.js_wechseln to inform the German Wikipedians about this issue. Matthias M. (talk) 16:18, 29 January 2009 (UTC)

wikEd in Wikisource

Hi, I work on Wikisource fr and I would realy appreciate wikEd to work properly in proofreading mode (for example). The edit window goes to the bottom of the page instead of next to the image, where the textarea normally stands. With wikEd 0.9.69a, on Firefox 3.0.5. —Preceding unsigned comment added by Aroche (talk • contribs) 12:52, 31 January 2009 (UTC)

I have added Proofread Page extension compatibility to the newest release 0.9.70. Thanks for the suggestion - Cacycle (talk) 21:45, 31 January 2009 (UTC)

Fix Unicode

When I use button for fix Unicode in it.wiki, it doesn't works anymore and now appears a window: Uknown function wikEdFixUnicode. Moreover, in some pages some wikEd buttons don't appear. What can be the problem? I don't understand. Script is called here, and these problems started I think not more than few weeks ago. Thank you Lenore (talk) 14:58, 1 February 2009 (UTC)

This has been fixed in the latest release, Shift-Reload to update. Cacycle (talk) 15:25, 1 February 2009 (UTC)

Ok thank you Lenore (talk) 17:07, 1 February 2009 (UTC)

Problem with the Firefox extension "WOT" and your script

Hello, Cacycle. Since some months I have a problem, if i upload an image using your script on the upload page with my firefox.

• Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.0.5) Gecko/2008120122 Firefox/3.0.5
• WOT (from http://www.mywot.com/de)

Always the following lines apear on the upload page, but not until storing of the image.

Vertrauensw.:
Händlerzuverl.:
Datenschutz:
Jugendschutz:

The lines not apear in the editing box, but during the preview (of your script) in the lower part of the page and after the storing. I would be glad, if you could find a solution. Greetings --Tlustulimu (talk) 17:04, 2 February 2009 (UTC)

I will fix this for the next release. Cacycle (talk) 04:50, 3 February 2009 (UTC)

Fixed in wikEd 0.9.72. Cacycle (talk) 04:20, 16 February 2009 (UTC)

Thank you very much. --Tlustulimu (talk) 16:43, 16 February 2009 (UTC)

fr translation

Hi, there's a problem with the translation of theses lines :

			'wikEdFixUnicode alt':         'Fix Unicode',
			'wikEdFixUnicode title':       'Fix Unicode character representations',
			'wikEdFixRedirect alt':        'Fix redirects',
			'wikEdFixRedirect title':      'Fix redirects',

All the others translation lines work here, but not theses four. Any idea ?

Can you update your example ? Thanks Leag (talk) 12:33, 5 February 2009 (UTC)

Hi Leag, sorry, I will update the translations and the example as soon as possible. BTW, please always use the French translation on en.wikipedia as I cannot edit the fr.wikipedia version. Cacycle (talk) 13:32, 5 February 2009 (UTC)

I'm sorry too, I had forgotten this file. I've translate your updates in french but Redirect, Unicode and Sort don't work anymore. I don't know why. Leag (talk) 08:58, 6 February 2009 (UTC)

The casing of the names has changed (wikEdfixUnicode to wikEdFixUnicode). I will fix that in all translations as soon as I find some time. Cacycle (talk) 13:23, 6 February 2009 (UTC)

"Sort" and "Unicode" translation work correctly now, but not "Redirect". Thanks Leag (talk) 14:20, 6 February 2009 (UTC)

wikEdFixRedirect works now, thanks. Leag (talk) 09:28, 21 February 2009 (UTC)

I will add the missing translations of the most recent version this weekend for translation. There is also a new option to check for missing translations (var wikEdShowMissingTranslations = true;) Cacycle (talk) 17:56, 21 February 2009 (UTC)

Why is it the various translations (not just the French) are not on translatewiki.net? Urhixidur (talk) 17:36, 16 July 2009 (UTC)

Wikia link suggest

I know that this is supposed to be available for all MediaWiki wikis, but the requests I'm asking now is specific to Wikia. Wikia has a link suggest feature described at wikiasite:help:Help:Link Suggest. However, this feature doesn't work while widEd is on. I was wondering if there's any way that you could allow link suggest to work in Wikia; it would be very helpful. Thanks. --Michaeldsuarez (talk) 01:37, 10 February 2009 (UTC)

Tricky, but I'll try... Cacycle (talk) 13:44, 11 February 2009 (UTC)

Feature request - dashes

I'm always replacing casual use of the ASCII '-' (hyphen-minus) with the correct typesetting mark, typically em-dash but sometimes em-dash and occasionally the minus character. These show up as different in a proportional font like the normal web page, but all look the same in the edit window!

I think that simply coloring them differently would do the trick. For example, if regular text is black, make the em-dash blue, the en-dash green, and the minus red. To serve as a key of sorts, color-code the "insert" hyperlinks to match.

—Długosz (talk) 17:42, 12 February 2009 (UTC)

P.S. Some time ago I tried the "fix dashes" button, but it didn't do anything useful. That was years ago, so I'll try it again.

On this page (permanent link to version), the "fix dashes" button does not handle the first paragraph:

The technological singularity is a theoretical future point of unprecedented technological progress -- typically associated with advancements in computer hardware or the ability of machines to improve themselves using artificial intelligence.

It changes this to an EN-dash and leaves the spaces around it. The correct fix is an EM-dash and delete the spaces.

On this page (permanent link to version), select the paragraph:

There has also been speculation that a large tsunami in the Mediterranean Sea caused by the Thera eruption dated ca. 1630-1600 BC geologically…

The fix-dashes button did nothing. I expected it to change the hyphen-minus in the range "1630-1600 BC" to an EN-dash.

On editing this section (permanent link to version), the first paragraph contains a range and the second contains a parentetical thought. I expected the "fix dashes" button to change the first to an EN-dash and the second to EM-dashes without surrounding whitespace. It did nothing.

Unconventional dashes and spaces are now highlighted with a small blue indicator and hover-over popup in version 0.9.73. I have changed the -- fix to em space. Unortunately, there is no automatic way to differentiate between range and minus between numbers. Cacycle (talk) 04:15, 16 February 2009 (UTC)

I saw the minus signs. The Testing→(− – — -)Cool! The difference in bullet, n, and m is visible, and not intrusive. Where can I see the rules/logic for dash fixing? At the very least I'll know what to expect. But perhaps I can offer further improvement. —Długosz (talk) 19:29, 18 February 2009 (UTC)

Search the code for "WikEdFixDashes", currently line 6501. Please feel free to suggest more or better rules. Cacycle (talk) 14:38, 19 February 2009 (UTC)

wikEdRegExTypoFix

I tried to load typos in it.wiki from this page, but doesn't work, button doesn't appear. The function in it.wiki is enabled from this page (at the bottom). Thank you for support Lenore (talk) 19:31, 13 February 2009 (UTC)

It works for me. Please could you post a full bug report (see top of this page). Thanks, Cacycle (talk) 02:12, 14 February 2009 (UTC)

Now it works for me too, but only after a total cleaning of FF3 data (cookies, recent, password etc.), cache purge wasn't sufficient. I don't know if this is a bug, but this is the first time that happens something like that for me. I'm sorry to have wasted your time anyway Lenore (talk) 14:34, 14 February 2009 (UTC)

Broken in Google Chrome?

When attempting to edit any article, wikEd displays a red "X" icon in the top right corner ("Loading error"). Edit window is empty.

WikEd version is 0.9.73, user agent is Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/525.19 (KHTML, like Gecko) Chrome/1.0.154.48 Safari/525.19, JavaScript console message is Uncaught TypeError: Cannot call method 'charCodeAt' of undefined http://en.wikipedia.org/enwiki/w/index.php?title=User:Cacycle/wikEd.js&action=raw&ctype=text/javascript (line 8591), OS is Windows XP SP3. On the same machine Firefox 3.0.6 appears to works fine with wikEd 0.9.73. GregorB (talk) 13:03, 17 February 2009 (UTC)

I will fix this as soon as I find the time (tonight?). Cacycle (talk) 17:37, 17 February 2009 (UTC)

Fixed in 0.9.37a, please SHIFT-Reload to update. Cacycle (talk) 04:09, 18 February 2009 (UTC)

Looks good, thanks! GregorB (talk) 08:01, 18 February 2009 (UTC)

Ndash/mdash display bug

Here's a way to reproduce it (Firefox 3.0.6):

1. Click e.g. here
2. Click on the ndash on the area under the edit window
3. An ndash is inserted in the edit box (minus with the small "n" above)
4. Position cursor to the left of the just inserted character
5. Type something
6. The small "n" gets misaligned, i.e. it is rendered above the text typed in the step 5

BTW I really like this new feature. I wish there was a way to custom-render the nbsp character entity in a user-friendlier way. Would this be possible? GregorB (talk) 21:29, 17 February 2009 (UTC)

Now mostly fixed in 0.9.73a... Cacycle (talk) 04:09, 18 February 2009 (UTC)

It still does that for me. 0.9.73a

And I second the suggestion for displaying non-breaking spaces, and extra space in general. &nbsp; is not replaced with U+00A0 by the purple Unicode button. But it certainly could use the same technology, to show a space with a small indicator in it. But you could also use ␢, ␣, or ␠. You could also show extra spaces besides the single space needed to separate words. —Długosz (talk) 19:47, 18 February 2009 (UTC)

wikEd is not (and cannot?) be compatible with non-breaking spaces in the text, it converts them no normal spaces (please see also Wikipedia:Manual of Style (dates and numbers)#Non-breaking_spaces). Długosz: Which OS and browser do you use? It works for me in Firefox and Chrome under Windows. Cacycle (talk) 22:43, 18 February 2009 (UTC)

The only problem with the current solution occurs when you delete the dash/space and do not move the caret (cursor) before continuing to type and the cursor disappears (Firefox bug). Then the first char of the new text has the marker above it until you push . Cacycle (talk) 14:44, 19 February 2009 (UTC)

Insertion of "unknown" character

Hi Cacycle, For a while, i have been mystified by the appearance in some of my edits of these characters. I have finally figured out where they came from. They are inserted when wikEd is on and I try to use the javascript accesskeys for; save, preview, content page, main page etc... It is fully reproducible, though i have no idea why wikEd feels the need to interfere with these keys. My specific env. is Safari 3.2.1 (5525.27.1) for Mac OS X (this is a nightly build, but earlier versions have it as well) wikEd 0.9.73 G. The key combo in that case would be ctrl-alt-s for saving for instance. --TheDJ (talk • contribs) 13:57, 18 February 2009 (UTC)

Unfortunately, I do not have a Mac to test this. Please could you check if this also happens in other rich text editors such as http://www.kevinroth.com/rte/demo.htm. Thanks, Cacycle (talk) 14:32, 18 February 2009 (UTC)

It does not. On Safari Windows, the key combo's should be alt-? if i remember correctly. --TheDJ (talk • contribs) 14:44, 18 February 2009 (UTC)

The characters appear to be EF BF BD, and to quote: "If we assume UTF-8 and convert UTF-8 "ef bf bd" to its Unicode code point, we get U+FFFD [3]. If we look up U+FFFD we see that it is the "REPLACEMENT CHARACTER"" --TheDJ (talk • contribs) 14:49, 18 February 2009 (UTC)

I also note that these characters are not visible in WikEd mode. Only when i disable WikEd after the edit, or when viewing the page after saving, the problem becomes visible. --TheDJ (talk • contribs) 15:12, 18 February 2009 (UTC)

The "replacement character" is used when conversion of the character fails, either because there is no such character in Unicode, or more likely because of a syntax error in the encoding. Reading a page with the wrong encoding (e.g. viewing Windows-1252 as UTF-8) shows those. So, I assume a bad byte sequence got inserted into the text stream there. —Długosz (talk) 19:33, 18 February 2009 (UTC)

This sounds like a browser bug. I can try to filter that character before submitting the text. What happens if you do the same procedure with wikEd toggled off (wiked logo button above the text area)? Cacycle (talk) 22:48, 18 February 2009 (UTC)

It correctly processes the action. The problem only occurs when wikEd is activated, and only when converting from WikEd -> submitted text. --TheDJ (talk • contribs) 22:58, 18 February 2009 (UTC)

I think it is the browser that erroneously inserts the ctrl-alt-s acceskey as a character into rich text editors as a strange combination of bytes. These then get converted to the � character (U+FFFD) at a later stage in the browser or on the server side. It would be interesteing to figure out the invisible bytes inserted by these actions: Could you try if this also happens with ctrl-alt-i (minor edit) and then use a hex-capable editor an copy and paste the unsubmitted text. If you see something, try the same on http://www.kevinroth.com/rte/demo.htm to see if it is Wikipedia only. Then we should probably file a (WebKit?) bug report. Cacycle (talk) 14:29, 19 February 2009 (UTC)

I think you are right.... It seems as though these keys are linked to some "standard" editor functions that are also available/show the same behaviour in TextEdit (our wordpad :D ). I will file a bugreport on this. (and I hope they don't decide to change the accesskey combo AGAIN). --TheDJ (talk • contribs) 15:35, 19 February 2009 (UTC)

bug filed. The current talk in IRC seems to be that each document has it's own accesskey domain. An iframe is a separate document, and thus does not respond to acceskeys defined in it's parent's view. The specific keycombination however is linked in the standard US keyboard layout on Macintosh to a range of characters that are hardly used. Apparently some of these characters are either no longer valid in utf-8, or possibly there is an error in on of the conversion routines that the wikEd javascript uses. --TheDJ (talk • contribs) 21:20, 19 February 2009 (UTC)

Version 0.9.74

Hi Cacycle. I saw in Upper Sorbian version wikEd_international_hsb.js that you added the following strings:

• wikEdFixRedirect alt
• wikEdFixRedirect title

and

• wikEdTableMode alt
• wikEdTableMode title

But those 4 strings have already been part of the file. They are double now. Is it correct? Regards, --Michalwiki (talk) 18:55, 23 February 2009 (UTC)

Thanks for catching that. I will fix it tonight. In the meantime it will not hurt. :-) Cacycle (talk) 19:18, 23 February 2009 (UTC)

Maybe that it was because of the different script versions that the languages are using. I'd propose that you better provide a changelog page informing all script translators that there are new changes and every script translator should update his script himself. Regards, --Michalwiki (talk) 21:01, 23 February 2009 (UTC)

So far I have just added the new additions in English so that translators only have to check their watchlist or check if there are new English strings. With a growing number of translations it becomes a bit more work for me, but it keeps the translations in a 'defined state' for easier maintenance. Cacycle (talk) 13:43, 25 February 2009 (UTC)

Works G r e a t under Safari 4 Beta (Tiger). Congratulations!

Hi, long time no comment. Kudos! wikEd runs fast under the new Safari beta (so far). Very quick load; will report any anomalies.
- - - Schweiwikist (talk) 08:07, 25 February 2009 (UTC)

Thanks, good to hear :-) Cacycle (talk) 13:45, 25 February 2009 (UTC)

Apparently it caches the script! Clicking to add this reply, there was zero load-time: all the tools are ready immediately. What a difference. Another thing I wanted to mention is that this is running on a Titanium PBG4 @ 1MHz with only 512MB RAM, and OS X Tiger. Will wikEd move toward supporting the resizeable edit box? ;) - - - Schweiwikist (talk) 14:36, 25 February 2009 (UTC)

I have to agree. Enabling WikEd on the edit page of Barack Obama has never been this lightning quick. --TheDJ (talk • contribs) 20:49, 28 February 2009 (UTC)

I have added a cool new input box resizing grip to the rich text frame in the next release. Cacycle (talk) 15:42, 1 March 2009 (UTC)

As of version 0.9.75 (Shift-Reload to update) the edit area now has a resize grip in the bottom right corner. A double click on it resets to initial dimensions. This does not work in the current Google Chrome (1.0.154.48) and possibly older Safari and WebKit versions due to a browser bug (frame body innerHeight is erroneously scrollHeight). Cacycle (talk) 15:53, 2 March 2009 (UTC)

Small rendering bug under Safari 4 beta (Tiger/PowerPC & Leopard/Intel):Edit summary text entry box

Hi, I can report a small rendering/interface glitch for the current version when running inside Safari 4 public beta (4528.16). This occurred under Leopard (10.5.6 with the security update, of course) on a MacBook (unibody) and also under Tiger (10.4.11 with the current Java version) on a Titanium Powerbook. Specifically, when going into edit mode while wikEd is enabled, or toggling wikEd (master switch by my live clock) while in edit mode, the edit summary text box/interface "drops out" (i.e., hides) until and unless the window is resized (just by a single pixel does it, so it redraws the contents) or fullscreen mode is invoked/uninvoked (producing the same redrawing and unhiding). This doesn't happen in Firefox. - - - Schweiwikist (talk) 01:30, 28 February 2009 (UTC)

I cannot replicate this under Windows XP using the same version. Therefore it is difficult to find a fix or workaround. But I'll try. Cacycle (talk) 15:40, 1 March 2009 (UTC)

Works OK on OS X 10.5.7 & Safari 4 (build 5530.17) for me. UncleDouggie (talk) 07:00, 20 July 2009 (UTC)

bug: disabling and reenabling wikiEd

i found an annoying bug with wikiEd, if i edit a page, then i disable the gadget and reenable it, all the changes in the edit field made after this will not be saved or previewed.

here are the exact steps:

• the wikiEd gadget is enabled
• click "edit this page" button to start editing a page
• add some text (for example: "123")
• click the gadget's icon on the top of the page to disable it
• click again to enable it
• add other text (ex: "456")
• save or preview the page, you'll see that only the "123" text will appear

the wikiEd version is 0.9.74 G (February 21, 2009) and i'm using Firefox 3.0.6: Mozilla/5.0 (Windows; U; Windows NT 6.0; ro; rv:1.9.0.6) Gecko/2009011913 Firefox/3.0.6 (.NET CLR 3.5.30729) i have this problem both on english and romanian wikipedia. Dany 123 (talk) 12:57, 28 February 2009 (UTC)

Thanks for reporting, I was not aware of this and are currently trying to fix it. BTW, it does not happen if you use the button bar button to temporarily switch to the standard input box. Cacycle (talk) 15:38, 1 March 2009 (UTC)

Fixed in version 0.9.75. Cacycle (talk) 15:48, 2 March 2009 (UTC)

Bug in diff pages

In diff pages wiked makes links lickable right? But there's a bug for which external links work wrong (see for example this) Lenore (talk) 19:21, 28 February 2009 (UTC)

It seems to work for me. Which link are you talking about and what happens? Cacycle (talk) 15:36, 1 March 2009 (UTC)

Try for example http://www.minsocam.org/ammin/AM75/AM75_1290.pdf: only http://www.m is active, and brings to http://www.m. I use FF3 Lenore (talk) 19:13, 1 March 2009 (UTC)

That is actually a Firefox 3 bug and they do not care enough to fix it (it is bug 440926). Feel free to vote for it - see the big box on top of this page. Cacycle (talk) 06:14, 2 March 2009 (UTC)

I'll vote it on the confidence (I don't understand nothing of HTML), but take a look at this, it works for me (even if has some bugs I don't know how to fix) Lenore (talk) 12:56, 2 March 2009 (UTC)

I will add a workaround. Cacycle (talk) 14:42, 2 March 2009 (UTC)

Has been fixed a while ago. Cacycle (talk) 02:33, 30 March 2009 (UTC)

How can I color text (not synthax highlighting!)

I would like to add a text marker to a custom button. How can I achieve this? —Preceding unsigned comment added by 91.50.191.41 (talk) 12:22, 1 March 2009 (UTC)

That needs changes in the program, e.g. in the highlighting code. You cannot do it with a plug-in alone. Can you give some background? Theoretically, I could add support for it in one of the upcoming releases if it is really important. Cacycle (talk) 15:35, 1 March 2009 (UTC)

Way too slow for minor corrections

It takes many seconds before I can make a simple spelling correction. Disabling. DCDuring (talk) 17:54, 5 March 2009 (UTC)

It should not be that slow, maybe something is wrong or incompatible. It would be a big help if you could provide some information to track this down. Most importantly, what kind of computer, operating system, and browser do you use. Is it a slow and/or old computer? Which other gadgets, userscripts, and addons are you running? (Please also see the top of this page for important informations). Does it happen on all pages? what happens if you disable syntax highlighting ( button)? Your help would be greatly appreciated. Thanks in advance, Cacycle (talk) 03:36, 6 March 2009 (UTC)

Firefox 3.0.7: Problem with edit-box resizing widget (the little corrugated square thingy)

Well, Firefox just got incremented to 3.0.7, and your recent update broke. Here's my info:

Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.0.7) Gecko/2009021906 Firefox/3.0.7

The quad-pointers pointer that used-to-appear when hovering over the resize square no longer appears, and now the best way to describe the response is that the resizer is slow and slippery: edit-box refresh is very slow, and once the pointer leaves the grab box (and crosses another interface element), refresh halts. Very weird. Obviously Firefox made some major change under the hood, because it used to work just fine. More info once I test on the other Mac, where we haven't updated Firefox. - - - Schweiwikist (talk) 19:15, 7 March 2009 (UTC)

UPDATE: Found source for "downgrading" back to FF 3.0.6. Will report results shortly. Schweiwikist (talk) 19:28, 7 March 2009 (UTC)

UPDATE: Same problem with FF 3.0.6 running, so it's not FF's problem. Apparently this interface bug might have to do with the initial edit box row/column setting in a logged-in user's prefs. Mine are recently set to 20 rows, thanks to your widget. Only enlarging the edit box (down-and/or-right) exhibits this bug. Up and/or left is fine (i.e., into the edit area). Will test ASAP with higher row setting. Schweiwikist (talk) 19:50, 7 March 2009 (UTC)

UPDATE: Nope, doesn't matter what the user prefs are (sorry, my rows setting was 12, not 20!). Confirming the bug in the resize grip is present under FF. Safari, you get a quad pointer which responds fine in all directions. Schweiwikist (talk) 19:59, 7 March 2009 (UTC)

Cursor changing bug fixed in next release. Cacycle (talk) 04:24, 11 March 2009 (UTC)

It only happened with short texts that did not fill the whole edit area. I have also fixed the resizing problems in 0.9.75a. Cacycle (talk) 04:47, 13 March 2009 (UTC)

Yup, it’s okay now even with the Firefox 3.1 beta. - - - Schweiwikist (talk) 21:42, 15 March 2009 (UTC)

Why?

Why did you remove the feature that puts the tabs at the top of the page that lets me easily put CSD, AFD, or other tags on the page? That's all I used WikED for, and now it's gone! No warning, no changelogs, no nuthin. Vistro (talk) 23:42, 7 March 2009 (UTC)

I am not sure what kind of feature you are talking about, it does not sound like a wikEd feature. Please could you explain this in more detail? Thanks, Cacycle (talk) 05:07, 8 March 2009 (UTC)

Are you talking about Twinkle? Cacycle (talk) 05:22, 8 March 2009 (UTC)

Fixing Tools

I have some questions and problems with the Fix tools. Why does Fix HTML or Fix All sometimes insert (-- and --) into pages? Also, Fix Caps seems to act on the entire page instead of just the paragraph as the help page describes. Fix Caps and Fix All often break the behavior of templates such as {{infobox}} by capitalizing the parameters. —Ost (talk) 15:51, 9 March 2009 (UTC)

Hi Ost, please could you try to find a page where (-- and --) are inserted, I cannot find an obvious reason and without an example I cannot fix this. I will check into the other problems later. Thanks in advance, Cacycle (talk) 01:44, 10 March 2009 (UTC)

Thanks for replying to my question and I think fixing the scope of Fix Caps to match the documentation. Most recently I noticed (-- and --) inserted into Muhammad Ali around the infobox, making the characters visible at at the top of the lede. Fix All also breaks the awards table at the bottom of Ali's page by capitalizing the parameters; the achievements table remains intact. —Ost (talk) 20:48, 12 March 2009 (UTC)

Thanks for your help, I have fixed the (-- and --) insertions in 0.9.75a. For me Fix Caps works on the current paragraph as stated (the current "paragraph" can be long if an article has no no empty lines...). The simple logic behind the fix buttons cannot distinguish between table cells and template dividers for lines starting with "|". Never use these buttons on the whole text and check with the diff button before submitting. Cacycle (talk) 04:45, 13 March 2009 (UTC)

Thank you for the fix and for answering my questions. I'm a big fan of the tool and I appreciate your work. —Ost (talk) 12:44, 16 March 2009 (UTC)

Removing buttons

What is the right way of removing some of the default buttons (to make the page less cluttered and faster to load)? Using a custom wikEdButtonBar is not reliable because the script expects the id of some buttons to exist, and dies if the getElementById call returns null. --Tgr (talk) 20:13, 10 March 2009 (UTC)

Click the grips on the left side of the button bars to semi-hide the bar. Completely removing buttons wold not have any effect on page load times. Disable syntax highlighting if you want to speed it up a bit. Cacycle (talk) 04:22, 11 March 2009 (UTC)

Disabling certain buttons should be possible. Not for page loading reasons but for usability. Lots of buttons the editor doesn't need scares the editor. It should be possible to keep the editor simple :) I guess disabling buttons is the first thing ppl check on the customization page. In case you care it would be cool to build the sections yourself e.g. remove all buttons from the fixing buttons section and move WikEd_fix_caps to the main section. --Subfader (talk) 21:14, 17 March 2009 (UTC)

WikEd_fix_caps is only for advanced users, therefore I will keep it in the fixing section. How should users know about the more advanced features when they become more experienced if the buttons are removed? Cacycle (talk) 02:21, 30 March 2009 (UTC)

Incremental find in Google Chrome

Incremental find does not work right in Google Chrome (wikEd 0.9.75, Chrome 1.0.154.48). Here's how to reproduce:

1. Go to e.g. this page
2. In the wikEd search box, type letter by letter: wiked
3. Notice that with each keypress the focus jumps to the next word matching the entered string, instead of staying on the same word. So, typing "wiked" gets you to the fifth instance of the word in the edit window, instead of the first.

This works as expected in Firefox 3. GregorB (talk) 14:13, 11 March 2009 (UTC)

Thanks for reporting, I will check into this (might be a tricky one...) 23:36, 12 March 2009 (UTC)

Lag

WikiED, along with other extra editing tools, causes the edit page to lag, at least for me it does.

-Axmann8 (Talk) 22:25, 12 March 2009 (UTC)

It should not be too slow, maybe something is wrong or incompatible. It would be a big help if you could provide some information to track this down. Most importantly, what kind of computer, operating system, and browser do you use. Is it a slow and/or old computer? Which other gadgets, userscripts, and addons are you running? (Please also see the top of this page for important informations). Does it happen on all pages? what happens if you disable syntax highlighting ( button)? Your help would be greatly appreciated. Thanks in advance, Cacycle (talk) 23:35, 12 March 2009 (UTC)

how to remove buttons?

(Moved here from User_talk:Cacycle/wikEd_customization)

How can I remove edit buttons (as I do not need them)? Loading of buttons is very very slow.... I use only the syntax-highlight function which is very useful. 88.209.142.83 (talk) 21:06, 13 March 2009 (UTC)

You cannot disable the loading of the button images, but that should not be a problem as they are loaded only once and are then kept in the cache. Other than the loading of the actual button images they do not slow down page loading. Please see also the above question. Please could you give some more informations about your system, your connection, and other details (see the top of this page for relevant information) - maybe there is something I can do to improve wikEd. Thanks in advance, Cacycle (talk) 03:57, 14 March 2009 (UTC)

---

1. wikEd version - 0.9.75b G March 14, 2009
2. browser id - Mozilla/5.0 (Windows; U; Windows NT 5.1; hu; rv:1.9.0.7) Gecko/2009021910 Firefox/3.0.7
3. Error console errors - (nothing relevant)
4. browser add-ons - (all disabled now): AutoPager, Calculator, ColorfulTabs, DownThemAll, FEBE, Flagfox, Forecastbar Enhanced, Googlepedia, GooglePreview, Hungarian dictionary, NoScript, SecurePasswordGenerator, StumbleUpon, SunCult, WOT

• Optional: What happens if you disable your add-ons and restart the browser - WikEd works as intended: the buttons are loaded just once!

1. user scripts in monobook.js - (nothing relevant)
2. operating system - Windows XP SP3
3. Describe the problem - the buttons were loaded at every page
4. Steps to reproduce - opening for edit a Wikipedia page

It seems the problem is gone with one of my Firefox add-ons (I try to narrow it to one add-on with enabling them one-by-one) 88.209.143.46 (talk) 11:24, 15 March 2009 (UTC)

I enabled all of the add-ons in Firefox and WikEd works well! Maybe you did something beneficial during the last couple of days? 88.209.143.46 (talk) 11:36, 15 March 2009 (UTC)

---

Strange things again... For a while all worked well, but today I noticed that WikEd loads again the buttons at every page I open for editing.

I disabled all the Firefox add-ons, then enabled them all, and everything goes well again with WikEd (I suppose: for a while). Maybe yesterday it was OK, I don't remember exactly, so 1 or 2 days passed without this failure.

What can I do now to find the cause? 88.209.147.7 (talk) 18:38, 17 March 2009 (UTC)

I have no idea. It could be a cache or proxy problem. Do you have enough local cache space and what happens if you clear it? Do you use a proxy server? I have recently fixed wikEd to work with WOT and WOT manipulates the pages in strange ways - does it still happen when you disable it? Cacycle (talk) 02:30, 27 March 2009 (UTC)

Firefox "Security Error"

1. Steps to reproduce:
   1. Follow site-wide installation instructions
      1. Edit MediaWiki:Common.js
      2. Paste in installation code
         1. <// install User:Cacycle/wikEd in-browser text editor
         2. document.write('<script type="text/javascript" src="'
         3. + 'http://en.wikipedia.org/enwiki/w/index.php?title=User:Cacycle/wikEd.js'
         4. + '&action=raw&ctype=text/javascript"></' + 'script>');
      3. Refresh page in browser
      4. Error console shows following two errors
         1. Security Error: Content at http://www.xyz.com/wikidev/index.php?title=MediaWiki:Common.js may not load data from http://en.wikipedia.org/enwiki/w/index.php?title=User:Cacycle/wikEd_current_version&action=raw&maxage=0.
         2. Error: [Exception... "Access to restricted URI denied" code: "1012" nsresult: "0x805303f4 (NS_ERROR_DOM_BAD_URI)" location: "http://en.wikipedia.org/enwiki/w/index.php?title=User:Cacycle/wikEd.js&action=raw&ctype=text/javascript Line: 10540"]
            1. Source File: http://en.wikipedia.org/enwiki/w/index.php?title=User:Cacycle/wikEd.js&action=raw&ctype=text/javascript
               
            2. Line: 10540
2. Browser version:
   1. Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.9.0.5) Gecko/2008121622 Ubuntu/8.10 (intrepid) Firefox/3.0.5

--JonnyIncognito (talk) 05:00, 18 March 2009 (UTC)

You have to set up a local version page similar to User:Cacycle/wikEd current version and point wikEd to it (var wikEdAutoUpdateUrl = 'http://www.xyz.com/enwiki/w/index.php?title=wikEd_current_version&action=raw&maxage=0';) or disable auto-update (var wikEdAutoUpdate = false;, see User:Cacycle/wikEd installation#Wikis without internet connection). Cacycle (talk) 02:38, 27 March 2009 (UTC)

IE6 "Expected identifier, string or number"

IE6 throws "Expected identifier, string or number" on WikEd.js line 326 because of the last line of the above object ends with a comma. (That is only allowed for arrays and not for objects according to ECMAScript, though every other browser seems to understand it.) --Tgr (talk) 09:20, 26 March 2009 (UTC)

Fixed in 0.9.76 - not that this makes it run under IE unless they start supporting the standard range object in a future version. Cacycle (talk) 00:15, 30 March 2009 (UTC)

Tab order broken for new sections

FF3 (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.7) Gecko/2009021910 Firefox/3.0.7), wikEd 0.9.75b G. Steps to reproduce:

• start new section
• focus cursor in "Subject/headline" field
• press tab; focus should pass to the main edit area but some invisible element is focused instead.

A related, more peculiar bug:

• start new section
• focus cursor in "Subject/headline" field, enter some text
• focus on the main edit area
• press shift-tab; focus should pass to the "Subject/headline" field but some invisible element is focused instead.
• press shift; focus returns to the main edit window, and some random text is appended to the the "Subject/headline" field (probably the previous edit summary).

--Tgr (talk) 09:27, 26 March 2009 (UTC)

I have fixed the tab order in 0.9.76b. Cacycle (talk) 02:16, 30 March 2009 (UTC)

Template in edit window

If you try to embedd a code like {{/Archive 001}} in this page, and you Ctrl-cl on it, you'll go in the page Template:/Archive_001 instead of the right one (User_talk:Cacycle/wikEd/Archive 001). wikEd 0.9.76, Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.9.0.8) Gecko/2009032609 Firefox/3.0.8 (.NET CLR 3.5.30729) on win XP Lenore (talk) 17:04, 31 March 2009 (UTC)

Short question

I'm using a costum skin on my Wiki and the Button for turning wikEd on and off does not appear. What needs to be in the skin to display the button? --DaSch (talk) 22:51, 31 March 2009 (UTC)

If your skin differs from common skins (especialy by missing or renamed element id's) then wikEd cannot install itself. Please could you give me a link to your wiki so that I can check into this (you may use email). Cacycle (talk) 00:00, 1 April 2009 (UTC)

http://www.wecowi.de here you can see it. wikEd is installed as a Gadget. --DaSch (talk) 10:20, 1 April 2009 (UTC)

I have fixed the support for Cavendish and Gumax skins in 9.9.77. It is also possible to customize this using the wikEdMediaWikiSkinIds setting (see source code). Cacycle (talk) 04:00, 2 April 2009 (UTC)

How to move wikEd Enable/Disable button for GumaxDD

I just want to know how to move the enable/disable button up or down the page. It's currently in a non-aesthetic place in the GuMaxDD skin that puts it below the navigation toolbar and above the edit toolbar. —Preceding unsigned comment added by 67.169.137.199 (talk) 06:51, 1 April 2009 (UTC)

• Basically, how do you move the wikEdLogo elsewhere? Or how do you not show the logo at all and it, by default, enables wikEd? Fader05 (talk) 16:30, 1 April 2009 (UTC)

I have fixed the support for Cavendish and Gumax skins in 9.9.77. It is also possible to customize this using the wikEdMediaWikiSkinIds setting (see source code). Cacycle (talk) 03:59, 2 April 2009 (UTC)

Chinese translation of wikEd

The current Chinese translation of wikEd, User:Shibo77/wikEd international zh.js, is actually in Simplified Chinese. I have made a Traditional Chinese translation for wikEd. Please take a look at User:Quest for Truth/wikEd international zh-hant.js. --Quest for Truth (talk) 09:52, 16 April 2009 (UTC)

Thanks a lot! wikEd automatically detects the wiki's language by checking the the variable wgContentLanguage = "xyz" in the page source where xyz is the language code. I am somewhat confused which Chinese translation should be used for which Wikipedia. Is there a Wikipedia that uses traditional Chinese as its official language? Which translation should be the default and which an option for which some code has to be added to monobook.js. Cacycle (talk) 02:48, 17 April 2009 (UTC)

The Chinese Wikipedia (zh:) is "bilingual". At the top of every page you can find tabs for users to select Simplified Chinese or Traditional Chinese. The variable wgContentLanguage always equal to "zh" but ueser can specify their preference in wgUserLanguage. There are 7 options: zh, zh-hans, zh-hant, zh-cn, zh-hk, zh-sg, zh-tw. You may like to set that zh, zh-hans, zh-cn, zh-sg use Simplified Chinese and zh-hant, zh-hk, zh-tw use Traditional Chinese. --Quest for Truth (talk) 15:24, 19 April 2009 (UTC)

I have added support for this in version 0.9.78. Please could you test if it works correctly? Thanks, Cacycle (talk) 03:26, 27 April 2009 (UTC)

Google Chrome problem

WikEd is checked in my preferences, but it's not showing up on my navbar as normal. There's no WikEd symbol at all I mean; it's not just the red X. Chrome is version 1.0.154.53, Windows XP, Modern skin. — Levi van Tine (t – c) 14:11, 17 April 2009 (UTC).

It works fine for me under the modern skin using the same Chrome version. Please could you go through the bug report checklist at the top of this page to pin this down? Thanks, Cacycle (talk) 21:53, 17 April 2009 (UTC)

Default: disabled

There is extra code that lets the WikEd disabled by default so I can activate it later? HyperBroad (talk) 20:03, 17 April 2009 (UTC)

Just click the logo at the top of the page once to disable wikEd. This setting is permanently stored in your browser. Does this address your problem? Cacycle (talk) 21:48, 17 April 2009 (UTC)

Not resolved. I set it in my monobook.js. HyperBroad (talk) 22:51, 17 April 2009 (UTC)

Please could you try to explain your problem in more detail, I am not sure what you need :-) Cacycle (talk) 03:45, 18 April 2009 (UTC)

What I need is a command to leave the wikEd disabled as default so I can activate it by clicking the top of the page when I need it. I always clear the browser cache before closing it. HyperBroad (talk) 16:32, 18 April 2009 (UTC)

You can add "var wikEdDisabledPreset = false;" to your monobook.js page and then click the logo to turn wikEd on and off during the session. Cacycle (talk) 17:30, 18 April 2009 (UTC)

Thanks! HyperBroad (talk) 18:44, 18 April 2009 (UTC)

Internet Explorer

Why don't you add suppor for Internet Explorer. I beleive the codes for internet explorer has changed with the onset of IE8, and it is now up to the Standards. --Tyw7‍ ‍‍ (Talk ● Contributions) Leading Innovations >>> 17:46, 19 April 2009 (UTC)

IE 8 does not support the standard range object that is heavily used in wikEd for functionality that could not (or only very difficultly) be simulated in IE. It is a shame that they are still not able to support web standards. Cacycle (talk) 18:27, 19 April 2009 (UTC)

Case sensative support for other lanquages

First off all thank you for the great Extension (I use greasemonkey version).
The problem is that the "Toggle between lowercase, uppercase first, and uppercase" doesn't support non-English Alphabet characters, like German "ä,ü,ö" or the whole Cyrillic alphabet(my case). I thought, that it wasn't a big deal and tried to fix it by myself: I replaced all *"a-zA-Z"* strings in the source with *"a-zA-Zа-яА-Я"* and it worked... well halfway (or 2/3way to be precise) - It only works with words, that begins with upper case and if the word begins with a capital letter - it converts it to full-upper case, than to full lower case, but than the cycle breaks. It looks like this: "Арбуз" -> "АРБУЗ" -> "арбуз" -> stays lower case. What should I do?
Thanks. —85.176.25.24 (talk) 01:36, 22 April 2009 (UTC)

I will try to fix this in the next release. Cacycle (talk) 12:47, 22 April 2009 (UTC)

Fixed in version 0.9.78. Cacycle (talk) 03:24, 27 April 2009 (UTC)

Wiked breaks wikimedia secure connection

Using/enabling wiked breaks wikimedia's encrypted connection at Secure Wikipedia. Is there a solution?Smallman12q (talk) 21:47, 22 April 2009 (UTC)

The gadget seems to use document.write instead of importScript() --TheDJ (talk • contribs) 15:47, 23 April 2009 (UTC)

WikEd loads other helper scripts dynamically (providing diff, RegExpTypoFix, and live preview functions) through unencrypted connections, that is what triggers the warning. This does not break any wikEd functionality. You could change the respective URLs to the secure server, see User:Cacycle/wikEd installation#Wikis without internet connection. We can actually add some code to the gadget page to do that. TheDJ: wikEd must not be loaded through importScript(), it has its own loading mechanism. Cacycle (talk) 22:49, 23 April 2009 (UTC)

I still see no reason why wikEd cannot use importScript (and uses the documented broken document.write), but that is beside the point. importScript has detection for the secure server and corrects local links of scripts when needed. That is more the point that I was trying to make. --TheDJ (talk • contribs) 23:57, 23 April 2009 (UTC)

Oh wait, we didn't actually commit that in MediaWiki I just remember. Well, with a wgScript check, It would still be fairly easy to load from a different URL. Especially in the case of the gadget loader. --TheDJ (talk • contribs) 00:12, 24 April 2009 (UTC)

wikEd loads helper scripts/content dynamically, so there is no way that importScript can correct these URL's. Also, wikEd uses its own loader so that it can initialize during page load to shorten startup time. It is also necessary for Greasemonkey compatibility. And document.write is NOT broken in any way for wikEd, trust me, I have invested quite some thought into this extremely complex matter. Cacycle (talk) 01:29, 24 April 2009 (UTC)

I have just added https / secure server support to the upcoming version of wikEd. Cacycle (talk) 01:29, 24 April 2009 (UTC)

Fixed in version 0.9.78. Cacycle (talk) 03:24, 27 April 2009 (UTC)

Expanding Editing Field

• 0.9.77
• Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.0.9) Gecko/2009040821 Firefox/3.0.9
• Error: WikEdEvent is not defined

Source File: http://en.wikipedia.org/enwiki/w/index.php?title=User:Cacycle/wikEd.js&action=raw&ctype=text/javascript Line: 3332

• dAmn XPCOM, dAmnAutoJoin, Greasemonkey, Japanese-English Dictionary for rikaichan, Raikaichan, Speed Dial, TwitterFox, Xmarks, Zotero
• User:Mr.Z-man/refToolbar.js,User:AndyZ/peerreviewer.js, User:Lightmouse/monobook.js/script.js,User:Dr pda/prosesize.js, User:Dr pda/prosesize.js, User:Cameltrader/Advisor.js, and this one.
• Windows Vista
• The entire toolbar still works. It's just that when I open an editing window, the edit field expands to take up the entire screen. To reduce it to its original size, I have to double click the gray box used for sizing the edit field. I believe its a problem with the script as I disabled it and this problem did not occur.
• Open any editing window

~Itzjustdrama ^{? C} 01:48, 25 April 2009 (UTC)

What do you mean by "the edit field expands to take up the entire screen" - the wikEd fullscreen mode? By "... I have to double click the gray box used for sizing the edit field." are you talking about the fullscreen button ? But wikEd buttons do not need double clicks?! Cacycle (talk) 02:23, 25 April 2009 (UTC)

Sorry for being unclear. But I meant to say that it would automatically go to fullscreen mode without me doing anything. It seems to have resolved itself though. Sorry for taking up your time. ~Itzjustdrama ^{? C} 15:35, 25 April 2009 (UTC)

Possible bug with the ' key.

I don't know if this is a wikEd bug or not, but I occasionally get the quick find feature in Firefox when hitting the ' (straight single quotation mark) button. It comes and goes, but I cannot pinpoint the source or cause, but as far as I can tell it's only happened to me within editing a MediaWiki website with wikEd enable. For instance, I was just editing Wikinews and I kept getting this bug, but reporting here it is fine. I then went back to check Wikinews and it's not happening anymore. Thanks. Calebrw (talk) 04:53, 27 April 2009 (UTC)

Edit summary hidden in Google Chrome Beta

Edit summary hidden in Google Chrome Beta YayaY (talk) 19:58, 1 May 2009 (UTC)

I cannot replicate this in Chrome beta 2.0.172.30. Cacycle (talk) 20:53, 23 May 2009 (UTC)

Component returned failure code

On http://de.wikipedia.org I recieve the following error using Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.10) Gecko/2009042523 Ubuntu/9.04 (jaunty) Firefox/3.0.10.

Fehler: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIDOMNSHTMLDocument.queryCommandEnabled]" nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: "JS frame :: http://en.wikipedia.org/enwiki/w/index.php?title=User:Cacycle/wikEd.js&action=raw&ctype=text/javascript :: anonymous :: line 6223" data: no] Quelldatei: http://en.wikipedia.org/enwiki/w/index.php?title=User:Cacycle/wikEd.js&action=raw&ctype=text/javascript Zeile: 6223

Matthias M. (talk) 13:28, 2 May 2009 (UTC)

Thanks for reporting this. Does it cause any problems and when does it happen (see the bug form on top of this page). Cacycle (talk) 15:43, 2 May 2009 (UTC)

The error-message is logged every time when you have a look at the firefox console, but there is nothing visibly broken. Matthias M. (talk) 19:15, 2 May 2009 (UTC)

Font slection

Can WikEd be extended with more formatting options like fonttype and coulor? Columbus56 (talk) 07:42, 5 May 2009 (UTC)

Sure, see User:Cacycle/wikEd customization. Cacycle (talk) 19:39, 12 May 2009 (UTC)

List-friendly feature

Can WikEd sort lists?

If not, would you add this incredibly useful feature?

Sorting lists manually is a real pain, and cutting/pasting them into 3rd-party sorters is very inconvenient.

The Transhumanist    18:50, 14 May 2009 (UTC)

I think I added the button just for you a while ago... :-) Cacycle (talk) 13:32, 15 May 2009 (UTC)

RegEx ^ and $

The regular expression used in find and replace should always execute in multi-line mode. This would make it more useful. I can't think of any cases where it is useful to restrict ^ to matching only at the very beginning of the page. For example, this would simplify the replace-all of (^|\n)(.+) → $1* [[$2]] to the more straight-forward ^(.+) → * [[$1]]   —GregU (talk) 05:50, 15 May 2009 (UTC)

Good idea! It will go into the next release. Cacycle (talk) 13:31, 15 May 2009 (UTC)

Added to version 0.9.79a. Cacycle (talk) 20:25, 24 May 2009 (UTC)

Size limit on syntax highlighting

What is the size limit for an article’s wikitext above which syntax highlighting doesn’t work? It’s definitely less than 32K, since Standard electrode potential (data page) is only 32,014 bytes, and it doesn’t work even when doing a section edit on the main section. Hgrosser (talk) 13:32, 19 May 2009 (UTC)

The preceding note was on Firefox Windows, on Safar1 3.1.2 the limit is definitely greater, somewhere between 82 and 109 kilobytes as reported at the top of the preview Hgrosser (talk) 21:35, 19 May 2009 (UTC)

It is a time limit of about 2 s. You can still highlight fragments. The upcoming release has a way to force highlighting by pushing Shift-[T}. Cacycle (talk) 03:17, 20 May 2009 (UTC)

Shift-[T] added to version 0.9.79a. Cacycle (talk) 20:24, 24 May 2009 (UTC)

Special extension tags

A wiki I'm on uses special parser extension tags that WED whines about. Solutions?--Ipatrol (talk) 19:06, 23 May 2009 (UTC)

If it still happens after updating (Shift-Reload) then please give me a link to that wiki and the name of that extension. Thanks, Cacycle (talk) 16:29, 24 May 2009 (UTC)

What happened?

The way wikEd highlights the text changed suddenly. What happened? mynameinc^{Ottoman project} 00:19, 24 May 2009 (UTC)

Updated text style and ref highlighting

This morning it worked fine, but now, after the update, it is different. I am unable to use wikEd in the default monospace font. When I have it enabled, i.e. letting it highlight things, it forces the sans-serif font, but I prefer the monospace. I would like this option. Also, the previous choices to highlight reference text were either gray background or gray words. Now it is gray background or gray words with superscript. I really hate the superscript so I'd rather have just the light colored words. Thanks, Reywas92^Talk 00:23, 24 May 2009 (UTC)

I wanted to say the same thing about monospace. I want my monospace, dammit :P Circeus (talk) 01:54, 24 May 2009 (UTC)

Monospace is back as well as well as some other changes. I might remove the ref superscript soon. Please Shift-Reload to update. Cacycle (talk) 16:31, 24 May 2009 (UTC)

Fixed in 0.9.79a. Cacycle (talk) 20:23, 24 May 2009 (UTC)

Edit summary area

I'm somewhat new to wikiEd, and your page about costomization is very confusing. My concern is about the edit summary and save page region below the edit box. I significantly prefer the dafault Wikipedia format of having the save page/preview/changes buttons directly under the minor edit checkbox, which is directly under the edit summary box. I think that's dumb to have them all separate with the minor edit checkbox below the save page and the edit summary being way on the right. How can I customize to have the standard layout there? Thanks! Reywas92^Talk 00:27, 24 May 2009 (UTC)

If you can live without the summary combo box and the additional space that the rearrangement frees you up for editing then you could add "var wikEdNoRearrange = true;" to your monobook.js. Cacycle (talk) 20:34, 24 May 2009 (UTC)

Popups with wikEd

I am a devout user of WP:POPUPS here. Normally when in the edit page, I can highlight a wikilinked word with my cursor and I get a popup like on articles. But wikEd does not allow me to do that. The ctrl-click works, but I don't want to open a new page for it, just see a preview with popups. How can I do this? Thanks! Reywas92^Talk 00:31, 24 May 2009 (UTC)

I will try to implement this, it might take a while though. Cacycle (talk) 17:56, 24 May 2009 (UTC)

New Code

Hello Cacycle,

I am a German Wikipedian, we are using directly the code from wikEd.js from your Page as a Gadget. I've seen that you've changed the display of the code in the Textarea. Personally I think the old code was much better, but thats not the main reason I am talking to u. At previously deleted Pages there is shown the deletion log in top of the textarea. With your code update, the deletion log is shown twice. (Compare e.g. [5] with activated Gadget). Could you please have a look at it please. Thank you -- Joschi90 (talk) 01:00, 24 May 2009 (UTC)

wikEd now copies messages from the page top to above the edit area so that can see them when jumping straight to editing. This is obviously confusing when the message is the only content... I will think about it... Thanks, Cacycle (talk) 15:36, 24 May 2009 (UTC)

Fixed in 0.9.79a. Cacycle (talk) 20:21, 24 May 2009 (UTC)

Thank you! -- Joschi90 (talk) 23:15, 24 May 2009 (UTC)

New text area layout

I like it :) Matthewedwards :  Chat  05:48, 24 May 2009 (UTC)

Sadly, I really don't and I think it might introduce issues for users with some forms of colour blindness. treelo _radda 11:50, 24 May 2009 (UTC)

Please point me to the problems and we can improve it. Cacycle (talk) 15:28, 24 May 2009 (UTC)

Studying it a little further it's not really a colour blindness issue that I'm seeing, just one where the grey text on grey background for wikilink markup might be too similar to each other for some to see easily. For the rest though, that's merely personal inclination towards the previous scheme. I think I might be alone in disliking the new style but a "classic" CSS could be thrown together so people can just paste it into their monobook.js should they prefer the other markup style. Really do miss that blue... treelo _radda 16:21, 24 May 2009 (UTC)

I am still making changes. Please try the new scheme on articles (after a Shift-Reload) for a while and report back :-) Cacycle (talk) 18:32, 24 May 2009 (UTC)

Ah, you're still listening to me! I like the changes done but I think it's the drabness of it which is making me cold towards it. Another thing is the new style given to items in the File: namespace (as a note, the image button still creates a link to the old Image: namespace) which I don't get as it throws me off because it doesn't feel like it fits in anymore. I think that's probably all the issues I have really, nice to know you're still receptive to comments. treelo _radda 19:50, 24 May 2009 (UTC)

The image is still there for compatibility with older Mediawiki installations. Cacycle (talk) 12:24, 26 May 2009 (UTC)

Ah, I know what I'm missing! Wikilinks and template markup used to be bold and now they're not making everything for my blue and red accustomed eyes to ignore those parts rendering it useless to me. Call it an odd form of blindness if you like but for the mehness the new scheme brings it really would benefit from the bold elements. Given all the problems only I seem to have with the new things, any chance of some CSS I can use to get some of the old scheme back? treelo _radda 21:51, 26 May 2009 (UTC)

You can set up any color scheme by customization. I suggest you wait until the new scheme has stabilized (plus you might get used to it...). One problem with the old scheme was for users without display anti-aliasing/ClearType where the bold red links where massive. It should now be more intuitive for beginners as all links are blue as in the final article text. The displayed link is bold, the hidden target article is normal. Non-mainspace links are dark-background non-bold. This scheme is optimized for articles where the only non-mainspace links are the interlanguage links at the end. And I am always open for constructive (and preferably tested) suggestions. Cacycle (talk) 22:25, 26 May 2009 (UTC)

Guess I'll have to sit and wait, like you say I might get used to it but right now I get less benefit from it than I did before and that's purely down to the colours utilised. I'm aware of the customisation ability hence why I've been requesting for some CSS to replicate the previous look, I'd do it myself but my CSS skills aren't that good. I fully don't expect any changes to be made on the basis of one lone voice but I do have a suggestion, the markup for images and other file: namespace content doesn't sit right because of the outline which makes it feel incongruous with the other markup, might consider removing it. treelo _radda 23:14, 26 May 2009 (UTC)

JavaScript error when starting with IE7

1. Microsoft Internet Explorer 7 on Vista SP1 i386

window.wikEdProgramVersion = window.wikEdProgramVersion || '0.9.79';
window.wikEdProgramDate    = window.wikEdProgramDate    || 'May 23, 2009';

Hello, there is a small glitch - one gets a Javascript error in line 845 when starting up in IE7 (tried with Vista). This happens before wikEd has a chance to shut itself down in the unsupported browser mode.

This fixed this for me:

diff -r cb639c56fc30 plwiki/sk/wiked.js
--- a/plwiki/sk/wiked.js        Sun May 24 16:38:46 2009 +0200
+++ b/plwiki/sk/wiked.js        Sun May 24 16:50:36 2009 +0200
@@ -841,7 +841,7 @@
                        67: ['g', 71], // scrolltoedit2
                        72: ['g', 71], // scrolltoedit3
                        74: ['g', 71], // scrolltoedit4
-                       32: ['g', 71], // scrolltoedit, overwrites previous wikEd buttons for same key
+                       32: ['g', 71]  // scrolltoedit, overwrites previous wikEd buttons for same key
                });
        }

 « Saper // @talk »  14:53, 24 May 2009 (UTC)

Thanks, fixed in the shortly upcoming next release. Cacycle (talk) 15:27, 24 May 2009 (UTC)

Fixed in 0.9.79a. Cacycle (talk) 20:20, 24 May 2009 (UTC)

Use old syntax highlighting

How can I use the old syntax highlighting? The new version have a bug by editing references.--Video2005 (talk) 17:34, 24 May 2009 (UTC)

Use the gray button on the top right after Shift-Reload. Cacycle (talk) 19:34, 24 May 2009 (UTC)

Thanks, but how can I use the better OLD syntax highlighting?--Video2005 (talk) 20:09, 24 May 2009 (UTC)

Wait until the new scheme and the changes required for it has stabilized, the check User:Cacycle/wikEd customization to create a custom css scheme. Cacycle (talk) 20:19, 24 May 2009 (UTC)

So is there no way to use custom CSS at the moment? My custom CSS at User:Gary King/config.js doesn't work anymore. Gary King (talk) 03:43, 31 May 2009 (UTC)

Bump, can I just get a confirmation on this? Gary King (talk) 01:11, 4 June 2009 (UTC)

Custom CSS should work, please use the new source code definitions for changes as some classes and schemes have changed. Cacycle (talk) 15:39, 10 June 2009 (UTC)

Very odd Ctrl-click issue

Thanks to WWGB for catching this. I logged in tonight and started doing my disam work. WWGB caught that for whatever reason (Ctrl-click)" is being added to my edits in random places. Here is an example. Anyone else seeing this issue? --User:Woohookitty ^{Diamming fool!} 05:52, 25 May 2009 (UTC)

And I know that WikEd is the culprit because I turned it off and the issue went away. Of course, I don't WANT that. :) WikEd makes disamming much, much easier. --User:Woohookitty ^{Diamming fool!} 05:54, 25 May 2009 (UTC)

Well upgrading to the newest version of Chrome seems to have resolved the issue for now. --User:Woohookitty ^{Diamming fool!} 06:17, 25 May 2009 (UTC)

I have reverted wikEd to the previous version until this is fixed. Please update with Shift-Reload. So far, I cannot replicate the problem. It would help a lot if users experiencing this problem (insertion of "Ctrl-Click" before external links) could report their browser type and version as well as additional gadgets they have checked under My preferences - Gadgets here. Sorry and thanks in advance, Cacycle (talk) 13:21, 25 May 2009 (UTC)

I think it's worth noting that the bug may have existed in some form in the past, as I found this discussion from March 2008 talking about exactly the same thing: [[6]] Soap ^Talk/_{Contributions} 20:04, 25 May 2009 (UTC)

Yes, I have found several of these. I currently think it is caused by the use of a rare broken browser version (maybe Chrome or Safari (beta)?). Therefore it is important to find out the browser that causes this in order to implement a work-around. Cacycle (talk) 21:17, 25 May 2009 (UTC)

Mine stopped today. I even have WikiEd on. (I checked) --Abce2|AccessDenied 19:41, 25 May 2009 (UTC)

Thanks for your reply. Please could you report your browser name and version and possible other gadgets that you might have checked on User talk:Cacycle/wikEd#Very odd Ctrl-click issue. This is essential to locate the problem in order to fix it - even if it now works for you. Thanks, Cacycle (talk) 21:17, 25 May 2009 (UTC)

Likely caused by Chrome it seems. —TheDJ (talk • contribs) 21:13, 25 May 2009 (UTC)

I am running Chrome v. 1.0.154.65. I use Friendly, refTools, and Twinkle. TallNapoleon (talk) 21:26, 25 May 2009 (UTC)

I too run chrome, same version, all of the same scripts as TallNapoleon plus wikiED. Bizarre. Anyway, I also started a thread on Wikipedia:Village pump (technical) Valley2city^‽ 21:30, 25 May 2009 (UTC)

I run Twinkle, Friendly, Wikied, and reftools. I don't know if this helps, but after I asked for my monobook to be deleted and it got deleted the problem went away. Does that have any connection? --Abce2|AccessDenied 23:49, 25 May 2009 (UTC)

Possibly. Unless you also upgraded Chrome. It's either that specific Chrome version, or Chrome icw another gadget/script. If you can clarify if you also updated Chrome, then that might help Cacycle pinpoint the issue further. —TheDJ (talk • contribs) 00:09, 26 May 2009 (UTC)

The WikEd extension is really annoying.. it's all screwy. At the same time it's too useful to really disable though, for me at least. Someone should really take a look at it. Disable text formatting while editing in the text box for example, and strip the formatting when pasting. That would help tremendously. Anyway, for my settings and browser and such, see here: Click Rocknroll714 (talk) 01:23, 26 May 2009 (UTC)

I have found the possible cause and will put the 'new' wikEd (0.9.79c) back online. Chrome/Safari users, please click Shift-Reload to update! Sorry and thanks for the help, Cacycle (talk) 02:41, 26 May 2009 (UTC)

Awesome. Yeah I am using 2.0.172.28 for Chrome. The version I was using was the one right before that...I'm not sure what the version # was. --User:Woohookitty ^{Diamming fool!} 04:10, 26 May 2009 (UTC)

I use Safari Version 3.2.1. Wiked is the only gadget I'm using. Smatprt (talk) 04:56, 26 May 2009 (UTC)

Safari syntax highlighting

When I enable, and then disable syntax highlighting, the following is left for my supposedly "unhighlighted" editor view. <font class="Apple-style-span" color="#0000E0">. It's a while since I used WikEd last, so i'm not sure how long this problem exists. —TheDJ (talk • contribs) 20:23, 25 May 2009 (UTC)

I'm not 100% sure, but I think the return values before "if (isRemove.pop() == true)" in the Apple-style-span removers, need to be removed... —TheDJ (talk • contribs) 21:07, 25 May 2009 (UTC)

Thanks, I will fix this. Cacycle (talk) 21:09, 25 May 2009 (UTC)

I cannot reproduce this with the current Safari beta. Can you describe exactly what you do to see those tags? Thanks, Cacycle (talk) 01:14, 26 May 2009 (UTC)

I have this issue with both Safari 4 beta2, and nightly builds. I enter the edit view with wikEd disabled and syntax highlighting off (trough the wikEd controlbuttons toolbox). I enable WikEd mode, I enable syntax highlighting mode, I disable syntax highlighting mode. And then I have the problem. —TheDJ (talk • contribs) 09:14, 26 May 2009 (UTC)

Works OK for me on OS X 10.5.7 & Safari 4 (build 5530.17). UncleDouggie (talk) 07:07, 20 July 2009 (UTC)

Copy-pasting

I love Wik-Ed, but I would like to suggest 1 minor improvement. When I copy-paste text from another page, the original formatting is retained in the edit window—a copy-paste of a header appears really big, for example. I can put up with this, although I would rather it were corrected.

The bigger issue is that some copy-pastes (usually of multi-line template code), have dodgy line breaks in. For example, a copy-paste of:

{{Template:Example
 |1=abc
 |2=def
 |3=ghi
 }}

would come out with an extra line break above it. Deleting this line break causes the formatting to change to the following:

{{Template:Example
  
 |1=abc
 |2=def
 |3=ghi
 }}

If I delete that line break, it moves between the |1=abc and the 2=def. With larger chunks of code, this gets rather annoying.

I don't know if this is deliberate, or if it has been addressed before, but I thought I'd suggest it in case it was annoying anyone else. Dendodge _T\^C 21:56, 25 May 2009 (UTC)

Those extra "linebreaks" are actually margins around the pasted block. You have to push the [T] button to get rid of that space. Cacycle (talk) 22:10, 25 May 2009 (UTC)

That simple? Thanks! Dendodge _T\^C 22:12, 25 May 2009 (UTC)

Fixes problem

Just a small problem, when highlighting text that includes an image, pressing either the Fix Caps or Fix all buttons changes File: to the older Image: namespace. While this doesn't break anything, if there's the time it would be nice if this was fixed.

On another note, I prefer the new colouring, it is much clearer and less distracting. QueenCake (talk) 21:31, 26 May 2009 (UTC)

Fixed in next release. Thanks, Cacycle (talk) 02:01, 29 May 2009 (UTC)

Fixed in 0.9.80. Cacycle (talk) 15:35, 10 June 2009 (UTC)

Font too big!!

My edit box, both the main edit area and the subject line, have become "large print". It's about twice the size of normal text on the page, and almost as big as header text.

This is the May 25 edition, and I suppose the problem may have occurred when I picked up that edition.

If I reset the page zoom, it's still larger than the body text.

Długosz (talk) 15:38, 28 May 2009 (UTC)

Which browser and operating system are you using (including versions). Cacycle (talk) 01:59, 29 May 2009 (UTC)

I'm using Windows, Firefox 3.0.10.

If there's a way to read out the settings it took and tell you, let me know. Regular content I can examine the DOM and the "generated CSS" for it. But that doesn't show up for the workings of the edit control.

Długosz (talk) 22:25, 1 June 2009 (UTC)

Długosz: You can use the "DOM inspector" which comes with the "Web developer" Firefox addon (under Tools:Web developer:Tools:DOM inspector) on an edit page to check CSS rules and to see the calculated CSS properties. It would be of enormous help if you could check the font-size properties and see where their large size originates. The strange thing is that I have not made any changes to the CSS of the summary or anything outside the edit window :-S Thanks in advance, Cacycle (talk) 00:43, 3 June 2009 (UTC)

I didn't know that the DOM inspector would show inside the rich edit control But it looks like it is a separate document. With the normal text box, there are 26 lines displayed. With yours, in the same size it displays 20. The normal TEXTAREA is the built-in font-size of "medium" and a computed size of 17.2833. With WikEd, the various SPANs that show up for the rich edit has a computed size of 22.98. The only CSS in an enclosing element is that mentions text-size is the BODY, which has 17.28 as a style attribute of the element.

There does not seem to be any CSS that makes it jump 33%. It is not in the DOM Node. It seems that the size is set directly in the style of the BODY node. It has a Computed Style of 22.98, when the style="font-size:17.2833px" would seem to indicate otherwise.

Thanks, Długosz (talk) 17:03, 8 June 2009 (UTC)

June 10 edition of WikEd, and it's still bothering me greatly.

I am really sorry, but I do not have a Mac and I cannot figure out myself what leads to the large font size. Please could anybody with a Mac try to figure out where the style for the large font size originates? Thanks, Cacycle (talk) 23:10, 19 June 2009 (UTC)

"I'm using Windows, Firefox 3.0.10." Not Mac.

Use the following in your monobook.js page to fix the problem: wikEdFrameCSS['.wikEdFrameBodyNewbee'] = 'font: .75em;'; Gary King (talk) 00:40, 20 June 2009 (UTC)

Gary King: Thanks for your help! The really really strange thing is that this style is only applied to the editing frame, not to anything else on the page. It is beyond my understanding how this could "bleed" into the rest of the page such as the subject field! BTW, the font size is currently set to medium, which probably uses your browser preferences - have you set your default browser font to something very large? Cacycle (talk) 01:31, 20 June 2009 (UTC)

It is strange in that the applied CSS shown does not agree with the "computed values". Are you sure the script isn't changing them somehow? E.g. applying the "text zoom" command for Huge? Anyway, still doing it with 0.9.81G. Długosz (talk) 17:07, 22 June 2009 (UTC)

In 0.9.81 the script now sets the font size to the same pixel size as that of the standard textarea. There is no longer a CSS definition for the font size. Does it work for you? Cacycle (talk) 17:26, 22 June 2009 (UTC)

(Hopefully) fixed in 0.9.81. Cacycle (talk) 04:49, 22 June 2009 (UTC)

Looking at the main document, the DIV wikEdTextareaWrapper has a computed style font-size 16.8833px. This matches the Copyright paragraph later on the page. The wpTextbox1 TEXTAREA I suppose is the original input control and you are hiding it. The CSS is applying the built-in browser style font-size:medium to that, and computed is 17.2833px. Your IFRAME wikEdFrame has a computed font-size of 16.8833px.

Diving in, the contained document HTML wikEdFrameHtml has a computed size of 21.2667px, and BODY wikEdFrameBody has a computed size of 22.9833px. There is nothing in the CSS (according to DOM browser) that would make the HTML larger, and the BODY has an explicit font-size:17.2833px, so the computed style directly contradicts that.

Adding the JS as suggested by Gary King does not have any visible effect. Długosz (talk) 17:31, 22 June 2009 (UTC)

Does it work with 0.9.82? Do the classical textarea and the wikEd editing frame the exactly same text size when you toggle wikEd on and off? If not, then you might have another script (Greasemonkey?) or plugin changing the textsize after wikEd set them to exactly the same size in pixels. Or is a read pixel size not the same as a set pixel size on Macs? Cacycle (talk) 13:44, 26 June 2009 (UTC)

Toggling off, this window shows 26 lines. Toggling wikEd 0.9.83a G back on, 19 whole lines show. See the paragraph above after the red highlighting for more details. Again, nothing to do with Macs (confusing me with someone else?) I don't have Greasemonkey installed, and Stylish is not applying anything. Is there a way to enable logging, so I could see what pixel size it is reading and writing, on my machine? Have you tried it on Firefox with "Zoom Text Only" turned (back) on and some zoom value other than 100%? As I reported earlier, I don't know the exact value without any plug-ins.

Have you turned the [1] button off? Cacycle (talk) 22:50, 2 July 2009 (UTC)

Font too small

I just realized that my problem is different from the one that the thread starter is having. The font is too small for me on a Mac in Firefox; setting a custom font size of 0.75em makes it just the right size for me. This still occurs in the latest version of wikEd FYI. Gary King (talk) 18:21, 22 June 2009 (UTC)

Which version is "the latest"? Cacycle (talk) 13:44, 26 June 2009 (UTC)

It happens only if you zoom the page by default with "Zoom Text Only" selected. Cacycle (talk) 05:09, 3 July 2009 (UTC)

Bug - Find/Replace text box overflow into editing area

• My wikEd version : 0.9.79c (May 25, 2009)
• My browser id : Safari Version 3.2.3 (4525.28.3)
• Error console errors : Couldn't find an error console on Safari's Menu list
• Which browser add-ons have you installed : Couldn't find this info either
• Which user scripts have I installed on my monobook.js page: None
• Which operating system do you use: Mac OS X 10.4.11 (8S165)

• Problem: The Find/Replace window is bleeding into the wikEd edit area. A screenshot of the problem is found at - commons:File:WikEd Gui Problem Safari 3.2.3 5 30 2009.tiff. I can eliminate the problem by using the "Make Text Smaller" selection on the View menu several times, but then the text in the edit box becomes unreadable. Dnessett (talk) 18:46, 30 May 2009 (UTC)

• Steps to reproduce: Just enable the wikEd gadget and use it. —Preceding unsigned comment added by Dnessett (talk • contribs) 18:11, 30 May 2009 (UTC)

Thanks for reporting this. Unfortunately, I cannot reproduce this under Windows with Safari 3.2.3 (525.29). Does anybody else experience similar problems? Cacycle (talk) 02:48, 2 June 2009 (UTC)

This appears to be a Mac OS X interaction bug, since I experience the same problem with FireFox 3.0.4 on my Mac. Dnessett (talk) 15:20, 2 June 2009 (UTC)

Problem identified (probably), but a not solution: This behavior seems to have nothing to do with Mac OS X. It appears to arise because I am using a DELL 30" monitor connected to my Mac (screen resolution = 2560x1600). I think the problem is CSS pixels are not screen pixels (see CSS pixels). The definitions of the Find and Replace combo boxes in wikEd.js use the px dimension, which do not map directly to screen pixels. The problem is the layered Find and Replace Select boxes (defined in wikEd.js as #wikEdFindSelect and #wikEdReplaceSelect) are not aligning properly to the top of the bounding box. They are then pushing the material below them into the edit area. This is seen in this screenshot. I have loaded wikEd locally on my personal wiki and played around with the parameters in WikEd.js, but have not been able to adjust them to get a good placement. To test my theory that this is related to my 30" monitor and not Mac OS X, someone with a 30" monitor connected to a PC should see if they have the same problem. (Note: there is a possibility that the problem has something to do with my graphics card, but I would like to eliminate the 30" monitor hypothesis before going down that alley.) Dnessett (talk) 01:44, 6 June 2009 (UTC)

Then again, maybe not: I decided to wade through the explanation of CSS reference pixels given in CSS pixels. A CSS reference pixel is about 1/96 inch on a screen display meant for viewing at arms length (~28 inches). The DELL 30" display has a viewable width of ~26.25 inches. At 2560 pixels of width that means it provides 97.5 screen pixels per inch. So, a CSS reference pixel = 97.5 screen pixels per inch * 1/96 inch = 1.01 screen pixels. This is practically identical to a normal display and therefore insufficient to explain the FindSelect and ReplaceSelect field pushdown into the edit area. So, I am back at square one. Dnessett (talk) 16:21, 6 June 2009 (UTC)

Problem Fixed: This was an extremely difficult problem to identify and fix. That I am not an expert in HTML or CSS is a gross understatement. So, I can only report my findings and hope those with a better understanding of both can elucidate. OK, enough whining. The problem is there is an interaction between class and id styles that leads to improper vertical alignment of the buttons and Find/Replace Select fields in the Find/Replace Button Bar. Some relevant styles specify vertical-alignment of text-bottom, others of text-top and still others 0%. The fix makes the vertical-alignment consistent by specifying vertical-alignment : text-top in the following style definitions - .wikEdButton, .wikEdButtonDummy, .wikEdFindComboInput, .wikEdCombo, .wikEdReplaceComboInput, .wikEdButtonUnchecked, .wikEdButtonChecked, .wikEdSummaryComboInput, .wikEdSummaryText, .wikEdSummarySelect, #wikEdFindText, #wikEdFindSelect, #wikEdReplaceText, and #wikEdReplaceSelect. One problem is I have no way of testing this fix on PCs (I use a Mac for most of my work). While I have a PC, my local test wiki on my Mac is not set up to serve other computers. Rather than going through the trouble of setting up a local network wiki server, I assume wikEd is installed on testwiki. Someone can make the indicated changes there to wikEd.js and test the fix on PCs. If the changes cause problems for PCs, at least the problem is identified and I assume some other approach can fix it for both PCs and Macs. As a side note, it is interesting that both Safari and Firefox on my Mac experienced the same problem. I can only assume that both browsers use a common library that causes the common vertical alignment problem. Dnessett (talk) 00:02, 11 June 2009 (UTC)

Cookie expiration suggestion

I notice that the Toolbar Hide cookies expire after 30 days. Why not 30 years? I don't want to have to re-hide a toolbar I never use. Thanks. --Armchair info guy (talk) 01:33, 1 June 2009 (UTC)

I have changed it to 2 months in version 0.9.80. It should be that short so that the interface is reset to default for irregular and/or unexperienced users. You can always add the following code to your monobook.js page: "var wikEdCookieExpireSec = 30 * 365 * 24 * 60 * 60;". Cacycle (talk) 15:34, 10 June 2009 (UTC)

Ah, yes, makes sense. I should've put 2&2 together before since I already modify several wikEd vars in monobook.js. So thanks for obliging me here. --Armchair info guy (talk) 00:45, 11 June 2009 (UTC)

Unresponsive

As of recent, the script has been causing my browser(s) to become unresponsive while attempting to edit some articles.

A script on this page may be busy, or it may have stopped responding. You can stop the script now, or you can continue to see if the script will complete. Script: http://en.wikipedia.org/enwiki/w/index.php?title=User:Cacycle/wikEd.js&action=raw&ctype=text/javascript:8823

This is happening with both Firefox 3.x.x under Windows 7 and with Firefox 3.0.9 under Ubuntu 9.04. wikEd version is 0.9.79c.   — C M B J   19:16, 2 June 2009 (UTC)

On which articles or article sections does it happen? Cacycle (talk) 00:32, 3 June 2009 (UTC)

I (re)noticed the problem while trying to make some changes to hydrocodone. If it's not reproducible for you, I will check to be sure that the problem is not exclusive to these two machines -- so that I do not send you on a wild goose chase.   — C M B J   06:18, 3 June 2009 (UTC)

I can reproduce this on this revision and will try to fix this as soon as I find the time. Thanks for reporting it, Cacycle (talk) 12:51, 3 June 2009 (UTC)

That revision is really bad, but it's happening even on the most recent revision. The script doesn't go completely unresponsive, but the interface is lagged and Firefox is using up lots of processor time.   — C M B J   20:47, 3 June 2009 (UTC)

Fixed in 0.9.80. Cacycle (talk) 15:22, 10 June 2009 (UTC)

Lightweight highlighter

I tried wikiED and I found that it was too cumbersome (sophisticated?) for me. But I really like the text highlighting feature. Can you make a version, or a customization, that strips out all the buttons and leaves just the text coloring? (In a totally separate matter, is it possible to optionally hide refs so they don't clutter article text?) Thank you in advance.--HereToHelp ^{(talk to me)} 22:39, 3 June 2009 (UTC)

No, please check User:Cacycle/wikEd help#Can I have only some wikEd features. Cacycle (talk) 16:40, 4 June 2009 (UTC)

Bug: copy/paste in Safari introduces extraneous line breaks when text is from Word Pad

• My wikEd version : 0.9.79c (May 25, 2009)
• My browser id : Safari Version 3.1.2
• Error console errors : Couldn't find an error console on Safari's Menu list
• Which browser add-ons have you installed : Lots of plugins (too many to list). None seemed relevant to this problem
• Which user scripts have I installed on my monobook.js page: gWatch
• Which operating system do you use: Windows Vista SP1 (and Mac OS X 10.4.11 (8S165))

• Problem: Copy and paste from WordPad (TextEdit on Mac) into edit window when WikEd enabled causes extraneous line breaks.

• Steps to reproduce: Enable WikEd. Copy the following text (except for the <br> and <nowiki> tags) to a WordPad file:

<includeonly>{{#switch: {{{OP}}}
| nop
| note = <ref group=fn name=first></ref>
}}</includeonly>

Then open a Sandbox, edit it and clear all text. In WordPad, highlight and copy the text given above. Then paste it into the Sandbox edit window. Save the edit and reedit. Extraneous line breaks are added between each line. I first noticed this problem with Safari and TextEdit running on Mac OS X. I then verified the problem also exists on Windows Vista. This bug is important to me, since eliminating extraneous line breaks is necessary for a workaround of Mozilla bug 18994, which I need to use for a template I have devleoped. Dnessett (talk) 18:42, 5 June 2009 (UTC)

Alterations to Bibleverse and Infobox templates create error conditions

Infobox insists on first letters of fieldnames to be lowercase. wikEd changes them all to uppercase. Example:

{{Infobox Saint | Name=Saint Paul

is changed by wikEd to: {{Infobox Saint |Name=Saint Paul **which does not work**

---

John 3:16 becomes John 3:16 **which does not work**

The issue seems to be that the empty parameter "||" which is used for a numbered Bible book like "|1|Corinthians" must be left blank for "||John"

Thanks...Afaprof01 (talk) 17:16, 6 June 2009 (UTC)

This happens only if you use the Fix Caps and Fix All buttons which should only be used on selected text. I am planning to fix this by detecting templates and tables. Cacycle (talk) 03:07, 8 June 2009 (UTC)

spell check does not work in chrome

description: when wikiEd is enabled chrome's built in spell check does not underline misspelled words. All other functionality of wikiEd works when enabled. Disabling wikiEd and typing new misspelled words shows them underlined.

steps to reproduce: Edit an entry and type a misspelled word.

attempts to trouble shoot:

• restarted chrome
• disabled all other wiki gadgets (then restarted)
• checked spell check on other websites (works)
• right clicked and un-check 'Spell check options > Check the spelling of this field'. When highlighting the word this would sometimes cause the misspelled word to be underlined.

Setup:
wikiEd: 0.0.97c G
browser: google chrome 2.0.172.30
script errors: none
browser add-ons: none
user scripts: none
OS: windows vista business SP1
—Preceding unsigned comment added by R.Vinson (talk • contribs) 23:13, 6 June 2009 (UTC)

Unfortunately, this is a Chrome issue and I cannot do anything about it. Cacycle (talk) 04:10, 9 June 2009 (UTC)

Have you been able to quantify the problem? If you know exactly what the issue is, perhaps I can help. R.Vinson (talk) 17:30, 9 June 2009 (UTC)

It is probably just not yet implemented as there is also no spell checking for other rich text editors such as http://www.kevinroth.com/rte/demo.htm. Cacycle (talk) 20:08, 9 June 2009 (UTC)

Problem with tables

If I have this

Head Part 1 Part 2

# Head #* Part 1 #* Part 2

wiked formatter gives this

Head * Part 1 * Part 2

# Head # * Part 1 # * Part 2

then, comments (<!-- -->) should not be modified inserting empty lines between them and the rest of the text, because it could lead to malfunctions. Example

Part 1 Part 2

* Part 1 <!-- Hidden text --> ** Part 2

will be modified in this way

Part 1 Part 2

* Part 1 <!-- Hidden text --> ** Part 2

--93.47.32.238 (talk) 21:37, 10 June 2009 (UTC)

It's possible this is related to the bug I reported recently. Dnessett (talk) 00:10, 11 June 2009 (UTC)

Fixed in 0.9.80 - empty lines before and after lists are still inserted but this does not change the rendered article. Cacycle (talk) 04:37, 11 June 2009 (UTC)

How to disable wikEdFollowLinks?

How do I disable wikEdFollowLinks? Following links do not work in Firefox on a Mac, so I want to disable the feature. Using wikEdFrameCSS['wikEdFollowLinks'] = false; did not disable it. Gary King (talk) 01:35, 12 June 2009 (UTC)

Which feature are you talking about exactly? If it does not work we should try to fix it... (check the top the page for a bug report form). Cacycle (talk) 00:05, 16 June 2009 (UTC)

When I mouse over a wikilink, it says "ctrl-click", which I assume means when I hold the ctrl button and click on the link, it will open it in a new window. However, this does not work in Firefox on a Mac, so I want to just remove the text that says "ctrl-click" since it is inaccurate. I also want to remove the underline on wikilinks since they are not clickable. Gary King (talk) 00:19, 16 June 2009 (UTC)

If you file a complete bug report I will try to fix this for you :-) Does anybody else on a Mac have similar problems? You could disable linkification with "var wikEdFollowLinks = false;". Cacycle (talk) 02:22, 16 June 2009 (UTC)

Maybe it is a popup blocker addon? Cacycle (talk) 01:31, 22 June 2009 (UTC)

I don't have any Firefox addons enabled right now. Gary King (talk) 01:35, 22 June 2009 (UTC)

var wikEdFollowLinks = false; doesn't do it for me. I still get "ctrl-click" when I hover over links in the textbox. Gary King (talk) 02:48, 22 June 2009 (UTC)

I have now fixed wikEdFollowLinks to disable this feature (0.9.81). Does Ctrl-click work for other users on a Mac? Cacycle (talk) 04:34, 22 June 2009 (UTC)

FYI by default, ctrl-click on a Mac is the same as right-clicking on a Mac, which might be why the script's use of it does not work. Gary King (talk) 15:03, 22 June 2009 (UTC)

Added Cmd-Click for Macs in version 0.9.82. Please could you check if it makes sense and if it works. Thanks, Cacycle (talk) 03:39, 23 June 2009 (UTC)

 Fixed Works perfect now. Gary King (talk) 15:31, 23 June 2009 (UTC)

Autoscroll bug

wikEd automatically scrolls down to the editbox. However, if a page has an editnotice, this can cause you to miss it.

I propose the implementation of a simple check for <div id="editnotice

I have not closed the tag, as the id attribute ends in several different ways, depending on the namespace. If that string is found anywhere in the page, wikEd should not automatically scroll down to the editbox, as the editnotice should be read.

I have reproduced this on the latest version.

This is a bug with wikEd, and is common to all browsers.

fahadsadah (talk,contribs) 14:56, 14 May 2009 (UTC)

Added to upcoming release. Cacycle (talk) 03:18, 20 May 2009 (UTC)

wikEd should also not scroll down on pages with protection notices. fahadsadah (talk,contribs) 10:13, 17 May 2009 (UTC)

Why? Cacycle (talk) 03:18, 20 May 2009 (UTC)

Same reason as the editnotice one. You should read the notice. fahadsadah (talk,contribs) 08:47, 23 May 2009 (UTC)

Fixed in 0.9.79a. Cacycle (talk) 20:26, 24 May 2009 (UTC)

The same should apply to deletion notices, to stop you recreating deleted pages. fahadsadah (talk,contribs) 10:16, 28 May 2009 (UTC)

Moved to botton, as this is still a problem, but now unnoticable.

What is the best way to reliably detect these notices? Cacycle (talk) 00:03, 16 June 2009 (UTC)

I think, to be more futureproof, the best thing to do would be to treat everything unusual above the editbox as an editnotice. fahadsadah (talk,contribs) 18:29, 22 June 2009 (UTC)

That's probably a not very futureproof idea with respect to future changes and compatibility with other gadgets :-) Cacycle (talk) 03:45, 23 June 2009 (UTC)

Idea for making editbox text more readable and less daunting for newcomers

Hi, I was wondering if it would be possible to make an alteration to how wikEd treats non-textual elements (inline citations, nav- and infoboxes, other templates, etc., maybe even tables) in the edit box. Right now, you color those differently, which helps definitely, but I'm wondering if you could encapsulate them in a show/hide collapsible <div>? It would be very helpful for some workshops for scientists that I've been invited to give.

I floated the idea yesterday at the Village Pump. The basic idea is to replace the "special" texts with a two-state tag like [citation]. By default, everything non-textual (e.g., the ref tags and the citation between) would be hidden within such a tag. But if the editor clicked on a particular [citation] tag, it would show everything within, and could be edited. Once the editing was done, the editor could click that tag again and it'd collapse again.

This approach might make the editbox version of the article more readable (inline citations can be a bear!) and closer to the appearance on the article itself. Do you think it's feasible? We wouldn't need wikEd's other amazing powers (although they'd be a big win), so if you needed to disable something to make this one trick work, it would be OK by us.

I really appreciate your help on this, and I think it could benefit the scientists as they take their first steps into Wikipedia. Please feel to e-mail me, if you think it'd be better. Thanks! Proteins (talk) 23:04, 25 June 2009 (UTC)

That is a good idea. I assume that you are familiar with the button? One big problem with your idea is that wrong wikicode syntax can hide large chunks of the article in those invisible folded-in passages. In general, do not underestimate the abilities of new users to quickly learn wiki editing, especially if taught. Cacycle (talk) 04:14, 26 June 2009 (UTC)

Thanks! I do know the [1] button, but sometimes scientific/mathematical articles are so dense with references, that they still hamper readability despite the smaller text. Some citation templates can take up several lines each. Here's an illustration of what I mean. Another motivation is that many articles begin with an infobox, which occupies the full first screen; if that could be collapsed, so that the editor saw the lead text immediately...

I agree that these scientists can and will pick up wiki-markup quickly; I'm doing my best to put together good teaching materials. :) But at one workshop in particular, we've been allotted only 90 minutes. So I'd really like to "hit the ground running" with them, and not have to explain citation templates and infoboxes immediately. They'll be editing a variety of existing articles, so the problem of dense refs is real. WikEd will be turned on by default on their accounts.

During an earlier lecture to non-editors, I'll also be opening an edit window on a scientific article to demonstrate how Wikipedia works. If the content were readily understandable by them, that would be a huge win.

I appreciate the badly-formatted-wiki-text problem, but I really believe that the advantages of this approach outweigh its risks. The basic goal is to make the editbox article easier to read and navigate by showing simple wiki-markup (such as sections, wikilinks and italics) but hiding advanced wikimarkup (such as references, templates and infoboxes). Is it feasible, do you think? Thanks again for your time and help, Proteins (talk) 05:49, 26 June 2009 (UTC)

You can already do this by redefining wikEd's CSS schemes and switching all hidden passages on or off with the [1] button instead of opening and closing those passages separately with a double click. It is not possible yet to display a placeholder with this approach, but I could add something to do that. I will probably not incorporate that into the main wikEd as it is too risky with users that do not know exactly what they do and has the potential to break existing articles, but we could make it an optional plugin. Cacycle (talk) 13:20, 26 June 2009 (UTC)

Thank you very much, Cacycle; I'm grateful for your help. I'll work on adapting the CSS schemes and e-mail you with more details on the scientific workshops early next week. Proteins (talk) 15:52, 27 June 2009 (UTC)

I have just finished something cool for you :-) give me some time to update wikEd... Cacycle (talk) 01:17, 28 June 2009 (UTC)

Please update with Shift-Reload for the new version 0.9.83, please let me know how you like it and how it could be improved. Cacycle (talk) 04:26, 28 June 2009 (UTC)

Simply awesome! That's just what I was hoping for. It should really help newcomers to read/navigate the page and to make their first edits. I tested the new feature on several pages and it worked great. I did notice two glitches, which I hope won't be difficult for you to fix. The first was the second long template on Amanita phalloides, {{mycomorphbox}}; somehow the body of the template wasn't included in the TEMPL placeholder, perhaps because of some non-standard formatting?

The second was the coloring of tables, e.g., this edit section. Once a table is started, the coloring seems to extend for the rest of the article, i.e., it doesn't seem to recognize the table end symbol |}.

Would it be possible to collapse tables in the same way that you've collapsed references and long templates? I think that they're the last major impediment to readability, being unfamiliar in syntax and stretching over many lines.

Your work is exciting, and will be very helpful at these workshops. I have a few more ideas, but I'll send those by e-mail on Monday, if only to give you a breather. :) Thanks again! Proteins (talk) 13:30, 28 June 2009 (UTC)

Problems fixed in 0.9.83a, please update with Shift-Reload. Cacycle (talk) 15:51, 28 June 2009 (UTC)

wikEd doesn't load on Konqueror

wikEd which worked ok on my Win7+FF3.6a1pre doesn't load on Kubuntu9.04+Konqueror (KDE4.2.2). No plug-ins. SkyBon^{Talk\Contributions} 16:15, 28 June 2009 (UTC)

What do you mean by "does not load", do you see a wikEd logo on top of the page? What happens if you add "var wikEdSkipBrowserTest = true;" to your monobook.js page? Are there errors in the error console? Please see the top of the page for the informations that I need to help you. Thanks, Cacycle (talk) 18:26, 28 June 2009 (UTC)

wikEd actually starts loading in Konqueror but then encounters problems. Since Konqueror does not have an error console I cannot work on this under KDE on Windows. Maybe you can provide command line error messages. Cacycle (talk) 02:15, 29 June 2009 (UTC)

Hmmm... I haven't managed to find any console in Konqueror. SkyBon^{Talk\Contributions} 12:16, 30 June 2009 (UTC)

References and template hiding

A superb idea. I thought wikEd more or less had everything, but I was wrong!

Just a small suggestion: when references are hidden, a mouseover displays its content, but hides the templates within. Since templates such as {{cite web}} are widely used for referencing, perhaps it would make sense to automatically expand the templates within a reference when it's expanded on mouseover.

On a side note: when is 1.0 due? :-) GregorB (talk) 09:49, 29 June 2009 (UTC)

1.0 is reserved for when MS IE becomes compatible with web standards (selection model!) and wikEd can finally be used under it. Cacycle (talk) 12:47, 29 June 2009 (UTC)

More suggestions for wikEd

Hi Cacycle,

Great work on wikEd! I have a few more suggestions for your consideration, which might be helpful. The first one is the most important for the workshops, but also the most work. I'm grateful for whatever you can do, and leave all of these suggestions to your discretion whether they'd improve wikEd or not. Thanks, Proteins (talk) 18:35, 29 June 2009 (UTC)

• If you could combine the "in-text reference" button with the template-filling tool of Diberri, that would be awesome. Diberri's tool builds a named reference from a PMID code (and many other types of codes). Here's an example:

http://toolserver.org/~diberri/cgi-bin/templatefiller/index.cgi?ddb=&type=pubmed_id&id=17890307&add_ref_tag=1&full_journal_title=1

Perhaps you could add a special button that requests the PMID, launches an XML request and inserts the resulting full reference into the Wikipedia page?

Cool tool and a great idea. Somebody should make a wikEd-compatible Wikipedia gadget for this. But it is probably a bit outside the scope of the wikEd project. See User:Cacycle/wikEd customization#Custom buttons and User:Cacycle/wikEd development#wikEd API for how to add custom buttons and functions to wikEd. Cacycle (talk) 02:31, 12 July 2009 (UTC)

• Some of the best articles on Wikipedia use both in-text references to the literature and explanatory footnotes, such as <ref group=note> (see WP:FOOT for more details and Mary Shelley for an FA example.) Could you add a button for footnotes similar to that used for in-text references? Footnotes can also be named.

An extra button would be overkill, but maybe as a Ctrl-click option. Cacycle (talk) 02:31, 12 July 2009 (UTC)

• I'd like to encourage newcomers to make their contributions accessible to visually impaired readers and others who can't see images. Perhaps you could add an ALT attribute to images and math-mode formulae, e.g., [[Image:filename|thumb|alt=|widthpx| ]]?

For images the alt attribute is taken from the last parameter: [[Image:filename|thumb|alt=|widthpx|ALT-TEXT]]

• The tag is easy to learn, but perhaps it'd be helpful to have a button for inserting math-mode tags, something like

:<math alt="">
Add formula here.
</math>

Clicking one button is faster than typing it out, and I believe the format is standard.

This is probably too exotic for a normal button but would be an ideal candidate for a custom button, see User:Cacycle/wikEd customization#Custom buttons. Cacycle (talk) 02:31, 12 July 2009 (UTC)

• Perhaps you could add a collapsible menu for links to common help pages, e.g., table markup? The editing page already has a cheatsheet link ("Editing help"), I know, but it's not obvious to newcomers and I think one could do better. I was experimenting with something along these lines here (look in the upper right corner and scroll the page), but it's very rudimentary.

Good idea for a gadget. Cacycle (talk) 02:31, 12 July 2009 (UTC)

Again, thanks for your help, Proteins (talk) 18:35, 29 June 2009 (UTC)

Thanks for the suggestions, please see my replies above. Cacycle (talk) 02:31, 12 July 2009 (UTC)

Error in templates or tables

If I have something like this

{{Stub
| arg
|}}

(last argument missing) button returns an error

{{Stub
| arg
|}

}

probably because |} is treated like a table element. Can you fix? --93.47.34.59 (talk) 21:52, 29 June 2009 (UTC)

Fixed in 0.9.84b. Cacycle (talk) 02:02, 12 July 2009 (UTC)

How to stop using wikEd by default?

wikEd remembers whether I have wikEd enabled or not and then applies that the next time I open an edit page. That's good, but I'd like to instead force it to be disabled by default because it slows down the loading of pages, especially long ones, too much. How do I disable it by default instead of having it remember whether or not it was previously disabled? Gary King (talk) 04:07, 30 June 2009 (UTC)

Please see User talk:Cacycle/wikEd#Default: disabled above. Cacycle (talk) 11:58, 30 June 2009 (UTC)

var wikEdDisabledPreset = false; does not work for me. wikEd is still enabled based on whether or not it was enabled the last time I was in an edit window. Gary King (talk) 15:54, 30 June 2009 (UTC)

If I change it to true then it does indeed disable wikEd, but there is no way to reactivate it when I need it because none of the buttons created by wikEd appear, so this does not help. Gary King (talk) 15:57, 30 June 2009 (UTC)

The main switch is the icon next to the logout link. Cacycle (talk) 01:30, 1 July 2009 (UTC)

I'm looking for an option to just set the Classic Text Area as the default option instead of the wikEd text area. It's easier that way so I don't have to be at the top of the page to enable it; it requires two clicks when doing it like that, too, because then I have to enable it in the text area, too. Anyway, it doesn't work when set to either true OR false; it stays enabled consistently. Gary King (talk) 01:36, 1 July 2009 (UTC)

Hidden templates?

Using wikEd 0.9.83a and Firefox 3.0.11, when I try to edit Rsync and expand the {{Infobox software}} within, the latest_release_date parameter appears empty, but it isn't, it is populated with {{release date}}, which is only visible once wikEd is turned off. GregorB (talk) 08:48, 1 July 2009 (UTC)

Working on it. Thanks, Cacycle (talk) 21:33, 11 July 2009 (UTC)

Fixed in 0.9.84b. Cacycle (talk) 02:01, 12 July 2009 (UTC)

Firefox 3.5

Reference/template unhiding is apparently broken in Firefox 3.5 (wikEd 0.9.83a, WinXP SP3); mouseover does nothing. GregorB (talk) 15:21, 1 July 2009 (UTC)

Yep, doesn't work in Firefox 3.5. I'd love to see this fixed. Gary King (talk) 01:05, 2 July 2009 (UTC)

I have filed a Firefox bug report. Cacycle (talk) 01:49, 6 July 2009 (UTC)

I have filed another Firefox bug report that prevents an alternative approach using mouseover events. Please vote to get these bugs fixed in Firefox 3.5, see the orange box on top of this page. Cacycle (talk) 21:58, 11 July 2009 (UTC)

Ideographic space

I recommend U+3000 IDEOGRAPHIC SPACE to be highlighted: it is occasionally treated as wide variant of U+0020 SPACE and therefore is forbidden on ja Wikimedia projects.

Regular square with dotted lines may be desirable for highlighting image (note that it is wide character --- as Chinese ideographs [kanzi] are wide). --Hatukanezumi (talk) 16:42, 1 July 2009 (UTC)

Added to next release. Cacycle (talk) 05:34, 5 July 2009 (UTC)

Fixed in 0.9.84. Cacycle (talk) 21:28, 11 July 2009 (UTC)

Change <pre> to <source lang=javascript>

See title. Please change: (...) Please see edit window. —MC10|Sign here! 23:00, 1 July 2009 (UTC)

 Not done for now: please establish a consensus for this alteration before using the {{Edit protected}} template. — Martin (MSGJ · talk) 06:13, 2 July 2009 (UTC)

Changed pre to source on User:Cacycle/wikEd. Cacycle (talk) 05:33, 5 July 2009 (UTC)

Hidden begin-end not working in preview

Content hidden with Template:Hidden begin isn't working in wikEd's preview. The template isn't broken - it works in articles, and in WP's "Preview". I'm using FF 3.0.1 and the version wikEd supplied by "my preferences."

For example, "{{hidden begin|title=my title}}hidden content{{hidden end}}" displays as

my title    [show]

with WP Preview (where "[show]" is clickable), but as

my title
hidden content

with wikEd. — eitch 21:22, 8 July 2009 (UTC)

Fixed in next release. Thanks for reporting - Cacycle (talk) 02:48, 10 July 2009 (UTC)

Excellent, thanks for a great tool! It'd be great if, when the next release comes out, you deleted the "Notes" section from Template:Hidden_begin-end/doc (right now it warns about this wikEd problem) — I'll try to notice and do it myself, but there could easily be a delay — eitch 20:13, 10 July 2009 (UTC)

Fixed in 0.9.84. Cacycle (talk) 21:27, 11 July 2009 (UTC)

Doubled protection warnings.

Safari 4. page. Whenever I have WikEd enabled, suddenly i see the protected page warning twice after wikEd has loaded. —TheDJ (talk • contribs) 18:37, 12 July 2009 (UTC)

The warning is mirrored above the edit area so that you see if when you start editing - it's a feature :-) Cacycle (talk) 04:56, 13 July 2009 (UTC)

Basic fixes breaks CATSORT

When I use the single check button, it removes the space following the pipe in a Category link on an article that is supposed to be at the top of its category (e.g., "[[Category:History of Louisville, Kentucky| ]]" --> "[[Category:History of Louisville, Kentucky|]]"). It took me a while to realize this as the diff before saving is nearly identical, but if the space isn't reinserted before saving, the link is saved as with the page title inserted after the pipe. This screws up the sorting in the category and it would be helpful if you could get the script to skip fixing spaces following a pipe in category links. I realize it must be wikimedia software adding the pagename after the pipe when saving—causing the discrepancy between diffs before and after saving—but tweaking the script would prevent accidental changes to the sorting. Thanks. —Ost (talk) 18:39, 14 July 2009 (UTC)

A link is not working

Hi. The link for site-wide installation under "Installation" is not working. You have typed _ in stead of - between "site" and "wide". I'm not able to edit the page so I'm telling you. --79.160.203.21 (talk) 06:25, 15 July 2009 (UTC)

Thanks, fixed. Cacycle (talk) 12:43, 15 July 2009 (UTC)

Urls with ampersands

Hi, I installed wikiEd just now as a gadget through the Wikipedia preferences, and while it's unfortunate that ref (un)hiding is broken on Firefox, wikEd looks like a great idea. A bug: It seems that wikEd breaks URLs with ampersands in them (at least, URLs in refs). In Firefox, it turns each ampersand into � (that's Unicode 0002 "START OF TEXT") and in Safari it turns them into "%02" (same thing?). While strictly speaking ampersands in URLs must be encoded, in practice everyone uses ampersands and it's really ungainly to encode all of them. (And in any case, it's unlikely that existing links on a page have their ampersands encoded.) Is this a known bug? Regards, Shreevatsa (talk) 13:19, 16 July 2009 (UTC)

I cannot reproduce this, please could you provide an article link and fill out a detailed description of this bug (see top of the page). Thanks in advance, Cacycle (talk) 13:46, 20 July 2009 (UTC)

Sure. I should have been clearer: the bug is that when you click on the URL from within the wikEd textarea, it takes you to the wrong place. Here's a detailed description:

• wikEd version: 0.9.84b G (July 11 2009)
• Browser: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-GB; rv:1.9.1.1) Gecko/20090715 Firefox/3.5.1
• Error console: No errors. (Lots of warnings, though, but nothing relevant AFAICT.)
• Firefox add-ons installed: Adblock Plus, CacheViewer, Download Statusbar, DownThemAll, Firebug, Greasemonkey, Leechblock, Link Widgets, Live HTTP headers, Nightly Tester Tools, wiki auto-discovery button, Zotero.
• User scripts installed on monobook.js page: User:Dr pda/prosesizebytes.js, User:Smith609/toolbox.js
• Operating system: Mac OS X 10.5 ("Leopard")
• Description of problem / steps to reproduce:
  • Turn on wikEd. Toggle automatic syntax highlighting on.
  • Go to (e.g.) Arthur W. Ryder and click Edit.
  • There is a link in the second line. Hovering over the text shows the URI and "(Cmd-click)"
  • Cmd-click. (Or Ctrl-click if not on Mac OS X, I guess.)
  • Expected result: A new page opens to that URL.
  • Actual result: Firefox is taken to a page whose URL is a transformation of the actual URL, in which all the ampersands have been replaced by � (U+0002 START OF TEXT).

Hope you can reproduce this, Shreevatsa (talk) 14:30, 20 July 2009 (UTC)

Fixed in current 0.9.85, Ctrl-Reload to update. Thanks, Cacycle (talk) 15:36, 20 July 2009 (UTC)

Excellent and amazingly quick, works now in both Firefox and Safari. Thanks! Shreevatsa (talk) 16:02, 20 July 2009 (UTC)

PS: Do you know if the "ref hiding" is broken in Safari too? Turning it on seems to hide {{quote}} content too (in both Firefox and Safari), which is usually part of the article proper and need not be hidden. Regards, Shreevatsa (talk) 16:02, 20 July 2009 (UTC)

Thanks for reporting this. I have fixed it in 0.9.85c, please Shift-Reload to update. Cacycle (talk) 04:20, 21 July 2009 (UTC)

Yes, it works now. (Before you fixed it, I was going to add that some other templates get hidden too, but they all seem to work now.) Thanks again, Shreevatsa (talk) 04:31, 21 July 2009 (UTC)

Only simple, single line, non-nested templates are not hidden. I am wondering if we should disply the template name in the TEMPL buttons. Cacycle (talk) 12:12, 21 July 2009 (UTC)

Bold text

This problem started showing up after I had enabled the new enhanced toolbar in the preferences. If I have wikEd enabled (but editor mode disabled), and press enter/return in the "edit summary"-field (in order to submit the form), the '''Bold text''' is added after the cursor position in the textarea and this is then submitted. This happens on at least Safari 4 and Chrome (Jarry). If i disable wikEd with it's "p-personal" icon, the problem does not occur. —TheDJ (talk • contribs) 23:09, 16 July 2009 (UTC)

Happens only in Chrome >= 2.0, will check into it. Thanks, Cacycle (talk) 13:57, 20 July 2009 (UTC)

Edit area font grows when clicking buttons

Every time I click on "Toggle REF and template hiding" or "Toggle between classic text area and wikEd", the font size in the edit area grows. The only solution is to reload the page after clicking one of those buttons.

wikEd 0.9.84b G, Safari 4.0, Mac OS X 10.5.7, No user scripts --UncleDouggie (talk) 07:24, 20 July 2009 (UTC)

Have you changed your default text size from 100% in your browser? Cacycle (talk) 13:52, 20 July 2009 (UTC)

No UncleDouggie (talk) 06:34, 21 July 2009 (UTC)

It's working now with wikEd 0.9.85c! UncleDouggie (talk) 06:42, 21 July 2009 (UTC)