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 9 10 11

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 Wikipedia skin do you use (e.g. monobook or vector, please paste the following name: Special:MyPage/skin)
• Are you using the experimental Wikipedia Beta user interface (see the top left of this window)
  • Optional: What happens if you disable Wikipedia Beta
• Which user scripts have you installed on your Special:Mypage/skin.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

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)

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)

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)

Problems with fix html

In "fix html" () I found two issues

• tables don't inherit attributes (example <table class=wikitable> doesn't turn into {|class=wikitable)
• when converting, it converts new lines into <br /> in some tags like pre and math, causing malfunctions (try for example here; after fixing html, substitution <br /> -> \n gives the correct conversion) --93.47.29.46 (talk) 13:37, 18 August 2009 (UTC)

Preview background-color

Where can i change the background-color for the Preview function mentioned in Preview and changes?
Is this only possible using a css-rule or is there also a variable i can modify?
⇐⇑©TriMoon™ Talk @ 06:51, 4 February 2010 (UTC)

• PS: maybe you could change the default background-color to be "inherrit" instead of the white as it is now, that way it will look better on all wiki's because it will use the site's default colors.
  ⇐⇑©TriMoon™ Talk @ 09:11, 5 February 2010 (UTC)

Disable autoscroll?

Is it possible to selectively disable the autoscroll feature that causes the page to jump down to the edit box when loaded? I saw the previous discussion that this behavior is disabled when there's an edit notice, but I really would rather it not happen at all. I use Friendly and Twinkle, and often find myself opening a non-existent talk page to welcome or warn someone. However, wikEd jumps down to the edit box, causing the tabs to go off-screen, and I have to manually scroll back up to use my other tools. Since my browser is big enough to see the whole edit box anyway, the scrolling is more annoying than useful for me. --Darkwind (talk) 05:37, 16 April 2010 (UTC)

I will work on this as soon as I find the time after the upcoming major change to version 0.9.91. Cacycle (talk) 20:28, 20 April 2010 (UTC)

UploadForm.js not working when wikEd is enabled

Is there any way to switch of wikEd for selected articles? I have a problem with running the UploadForm-Script when the wikEd Option is active. I tried disabling loading wikEd.js (which does work wrt. wikEd not showing up), but the new upload form is still not applied. When switching off wikEd (user preferences), the new upload form is correctly applied. Thanks --StefanSchulzDe (talk) 18:30, 27 April 2010 (UTC)

How do I install UploadForm-Script? I don't think it loads when I try this and I cannot find any installation instructions. Cacycle (talk) 20:33, 28 April 2010 (UTC)

The script is loaded via the MediaWiki:Common.js script. Has some pre-requisits though, as can be seen, and I am not sure whether it can be applied via User-Scripts. I assume there is a reason, why WikEd is not available in commons. --StefanSchulzDe (talk) 17:56, 2 May 2010 (UTC)

Inserting/deleting newlines spuriosly 2 (bugreport)

• Wiked version: wikEd 0.9.91j G (July 22, 2010)
• Browser version: Google Chrome 6.0.472.33 beta
• Skin: Vector
• Link to section: User talk:Cacycle/wikEd#Inserting/deleting newlines spuriously

Here you go. ~ Boro (talk) 09:42, 12 August 2010 (UTC)

Hopefully fixed in 0.9.91k, please could you verify this? Thanks everybody for reporting and insisting on this :-) Cacycle (talk) 21:55, 15 August 2010 (UTC)

Could not reproduce the steps from the section above (Chrome 5.0.375.126/Win 7), so it looks like it's finally fixed! GregorB (talk) 07:27, 18 August 2010 (UTC)

However, it appears that newlines do creep in in some situations, i'll try to construct a test case. GregorB (talk) 10:15, 18 August 2010 (UTC)

It's a variation of the earlier test case:

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 Not any more, this has been fixed
5. Add the fourth "#" in the last line, directly below the third "#" in the edit window
6. Click on "Preview"
7. The third and fourth "#" are separated by an empty line. GregorB (talk) 11:37, 18 August 2010 (UTC)

I hope I could fix it in 0.9.91m. Cacycle (talk) 00:25, 22 August 2010 (UTC)

Cannot reproduce this in the new Google Chrome 6.0.472.53. Might be considered fixed. GregorB (talk) 22:23, 4 September 2010 (UTC)

• I've been consistently having this problem up until even today when using wikEd 0.9.100b G (September 17, 2011) in Chrome 14.0.835.202 and Vector and OS X. Test case is Military career of Hugo Chávez. Clicked edit tab, selected all text, then clicked the "Convert pasted content to plain text ..." button. Editor then inserted one newline after each paragraph.
• Further, wikEd mysteriously deletes a space before every [[, {{, and '' (there may be others in this list) that happen to be butted along the left-hand margin. If I use Firefox, no space-deletion or newline-addition issues, but wikEd becomes horrendously slow--dilatory cursor updates, general GUI flakiness, etc.
• Is there a pertinent thread for the latter issue? Otherwise, thanks for the great work. Saravask 09:48, 12 October 2011 (UTC)

Bug using wikEd on a specific website

On this website : http://fr.nvcwiki.com wikEd can be activated via gadgets preferences, but doesn't work properly.

With Firefox one can only have the right part of wikEd but not functionnal. And with Camino or Safari the edit window is to small to be visible except when set to full screen.

Thanks for your help.

--Dieudo (talk) 22:31, 6 September 2010 (UTC)

Thanks for reporting this. I could replicated this and will fix it as soon as I find some time. Cacycle (talk) 06:46, 10 September 2010 (UTC)

Text highlighter on view source page?

Would it be possible to implement the font/text highlighter on the view source page? (without the toolbars of course). — Train2104 (talk • contribs • count) 19:25, 12 September 2010 (UTC)

What is the "view source" page? Cacycle (talk) 21:36, 12 September 2010 (UTC)

The one a user gets when they try to edit a page and they don't have permission to . — Train2104 (talk • contribs • count) 21:46, 12 September 2010 (UTC)

Sure, I will add it as soon as I find some time. Thanks for the suggestion - Cacycle (talk) 22:06, 12 September 2010 (UTC)

wikEd is overwriting user customization (I give also an solution)

Hello, Cacycle! That's a very good and powerful Gadget! I have one problem/suggestion about accesskeys. You wrote "it overwrites the MediaWiki shortcuts", that's pretty fine. But You also overwrite user customization with that:

    // button access keys
    if (typeof(wikEd.config.buttonKey) == 'undefined') { wikEd.config.buttonKey = {}; }
 
    // wikEd.InitButtonKey: define accesskeys for edit buttons (wikEd button number: [key string, JS key code])
    wikEd.InitButtonKey = function() {
        wikEd.InitObject(wikEd.config.buttonKey, {
            26: ['b', 66], // wikify
            27: ['o', 79], // textify
            67: ['g', 71], // scrolltoedit2
            72: ['g', 71], // scrolltoedit3
            74: ['g', 71], // scrolltoedit4
            32: ['g', 71]  // scrolltoedit, overwrites previous wikEd buttons for same key
        });
    };

I'd like to attach 'u' to Underline button, 'i' to Italic button and 'b' to Bold button but the 'b' key seems not to work. It's attached to Wikify, I think that's because You add user customization and then set accesskeys for wikify, textify and scrolltoedit. Maybe You should reverse it?

    (...)
    wikEd.InitButtonKey = function() {
        wikEd.InitObject({
            26: ['b', 66], // wikify
            (...)
            32: ['g', 71]  // scrolltoedit, overwrites previous wikEd buttons for same key
        }, wikEd.config.buttonKey);
    };

P.S. Don't You think about archiving some sections here? q;) Vinne2 (talk) 18:57, 13 August 2011 (UTC)

Reversing the variables does not work. Please see User:Cacycle/wikEd_customization#Keyboard_shortcuts for how to redefine existing shortcuts. Cacycle (talk) 00:14, 4 January 2012 (UTC)

Links in diff link to template

Safari 5.0.2 (6533.18.5). The wiki-links in the diff link to the template of that link, so if the diff has [[Joss Whedon]] and I click it I go to [[Template:Joss Whedon]]. Templates aren't clickable at all, so this doesn't work at all, which would be extremely helpful. c Not sure when it started acting this way, maybe a week or so ago. Any thoughts?

Also, quick diff (Is that the name?) and quick preview haven't worked for a long time, I think since Safari 5. Thanks. _Xeworlebi ^(talk) 17:07, 18 October 2010 (UTC)

Will check, but it will take a while. Safari 5 seems to have several issues. Cacycle (talk) 20:49, 19 October 2010 (UTC)

Mostly fixed in 0.9.95c, still working on wikEdDiff for Safari 5... Thanks for reporting, Cacycle (talk) 23:06, 1 November 2010 (UTC)

Thanks. _Xeworlebi ^(talk) 12:37, 2 November 2010 (UTC)

Fail on bold italic text

Hello,

Some of us on frwiki have problems with wikEd when editing a page with bold italic text.

• wikEd 0.9.97a
• Firefox 3.6.13 on Ubuntu 10.10 (for me, but it looks it's not related)
• Plenty of addons (not related either)
• Plenty of other gadgets (including popups — but I don't think this is related either)
• Not related to userscripts (same behaviour with or without)
• monobook for me (don't know for the others) and no beta interface

How to reproduce :

• Take the source of this page http://fr.wikipedia.org/enwiki/w/index.php?title=Utilisateur:Arktest/test&oldid=62086827 (this revision)
• Save
• Try to edit the page
• ⇒ Empty textarea

Relevant information :

 Error: parseObj.tree[openNodeIndex] is undefined
 Source File: http://en.wikipedia.org/enwiki/w/index.php?title=User:Cacycle/wikEd.js&action=raw&ctype=text/javascript&dontcountme=s
 Line: 11679

The line 11679 is

 parseObj.tree[openNodeIndex].tag = tag; // openNodeIndex is null, the previous value of tag is “bold”

This is called by line 11147:

 wikEd.HighlightTreeRedefine(parseObj.secondlastOpenNodeFiltered, 'bold', 0, 3, parseObj); // just after case “'boldItalic':”

This is called by line 13316:

 wikEd.HighlightSyntax(obj);

With obj.whole == true and obj.html == // the whole page

If you can't reproduce, please let me know at fr:User talk:Arkanosis, I'd be happy to help.

Best regards — Arkanosis ^✉ 15:44, 8 February 2011 (UTC)

Oops. I can reproduce it and will check into it. Thanks for reporting. Cacycle (talk) 08:18, 9 February 2011 (UTC)

Req: Sort (and normalize?) list entries contained in a single line

Hi! I've got a feature request for you. Hope it hasn't been up for discussion before (boy was that ToC long – didn't dare to cast an eye on the archives too..!) Sometimes, in navboxes for instances, there are lists contained in a single table cell (e.g., Template:Beta blockers, delimited by various methods involving a bullet. Could you make the sort function sort these single-line lists somehow? Also, if possible, normalization would be neat to ensure that the method used for separating the entries (I guess " • " is the most common version) is consistent for a given line. Sometimes there is a bullet first on the line, where it's not supposed to be, sometimes people forget the   or add double spaces after the item, etc. Sometimes this can make editing the list a minor nightmare.

For now, I sorted the Template:Beta blockers by replacing the bullet stuff with newlines, opening up another WikEd tab and sorted the newly-created lines, then re-replaced the newlines with the bullet goo and pasted back in the first tab. Not so practical. :) W n C? 11:35, 23 February 2011 (UTC)

A workaround is to replace "• " with "•\n" (regex mode) then sort it afterward undo the replacement. Now I've been asked to add extra sort method (sort by last name, date, link title) to Dab solver, it would be nice to have a more powerful sorting interface. — Dispenser 04:25, 2 March 2011 (UTC)

The sort button can now sort lists in a single line, please see the wikEd help for details. Have fun, Cacycle (talk) 21:42, 6 March 2011 (UTC)

Oddly, single-line sorting doesn't seem to work for me now anymore (Safari 5.0.5, OS X 10.6.7). It just seems to mess around with the whitespace. Tried it on Template:Peripheral vasodilators. Doesn't help if I replace the &nbsp;• with e.g. {{•}}, either (though I do think WikEd could clean the ampersand mess up though, but maybe that's just wishful thinking. ;) ). W n C? 12:55, 16 June 2011 (UTC)

Extra line is inserted with regular expression replacement function if text ends a line

Happens first time, every time. Suppose I change from blogg to blog (UTC), where 'blogg' is at the end of the line. It works fine unless the regular expression button is pressed. Then an extra, blank line is inserted. Same with changing \w\wogg to blog. Text in the middle of the line works fine with or without regular expressions. Firefox 3.615 on Windows Vista, my only gadgets are Navigation popups and WikEd. Chris the speller ^yack 19:00, 8 March 2011 (UTC)

I see this too and I will check into this. Cacycle (talk) 07:44, 9 March 2011 (UTC)

Just to let you know that this is still a problem, and it effectively stopped me from cleaning up an article with a very long list. I can let the article wait, or do a whole lot of deleting lines by hand. Chris the speller ^yack 00:34, 25 June 2011 (UTC)

I omit this bug by adding "\n" at the end of the RegExp "Find" field and at the end of the "Replace" field. But it works only if You know and want to find expressions at the end of line. If that expressions are not only at the end You can add (\n?) to "Find" field and $1 (in the simpliest case) to "Replace" field. BUT: that doesn't changes the fact that I'd love that bug to be removed... q;) Vinne2 (talk) 19:10, 13 August 2011 (UTC)

Making scripts compatible with wikEd

I have installed WikEd on my wiki with the "intgrated to wikifarm" installation. I have some problem with the WikiEditor extension, when activated wiked's editing frame isn't visible. It work when you activate the fullscreen mode but the modification aren't applied. I have a mediawiki 1.16 and the WikiEditor (Version 0.2.0) extension installed with UsabilityInitiative (Version 0.1.1)

I want to do "Making scripts compatible with wikEd" installation but I don't get how it has to be done and where to paste the code --Tsouchon (talk) 13:41, 18 March 2011 (UTC)

This sounds like an incompatibility, perhaps with WikiEditor. What happens if you disable that extension? Please could you also fill out a bug report form (from the top of this page)? Do you see the wikEd logo on top of the page and does it give an error message on hovering? The "Making scripts compatible with wikEd" section is for authors of simple scripts, not for users. Cacycle (talk) 16:02, 18 March 2011 (UTC)

I have this problem too. MW version is 1.16.2. When WikiEd is on I cannot edit pages and sometimes I also get a "WikiEd Error" (WikiEd icon has a red X on it). For some reason here everything is OK... --Tharbad (talk) 19:03, 19 March 2011 (UTC)

I　got the same problem too, my MW version is 1.16.2. These two editor just work fine in zh.wikipedia.org(1.17) but not in my wiki. here is a Screenshot of the broken editor http://easycaptures.com/fs/uploaded/387/0939602272.png

PS: the small icon in right-top show as normal（There are no red X on it.）--晒太阳的冰 (talk) 04:44, 29 March 2011 (UTC)

InputBox retargets edit form

Edit this page with the above InputBox element

1. Quick preview
2. Click Save/Show Changes/Show Preview (keep the preview open)

Now you'll land on the inputbox specified page. This is because of the "title" field in the inputbox. Tested in Firefox 3.6.15 Windows XP. — Dispenser 17:42, 21 March 2011 (UTC)

"Convert to plain text" button jumps to the end

Here is a problem in Firefox 4:

1. Edit e.g. this page
2. Scroll down to the middle of the text in the edit window
3. Click on [T]
4. This causes wikEd to jump to the end of the text, instead of staying in the same position, as it does in 3.6.16 and Chrome 10

Somewhat annoying when using [T] in big articles, otherwise not a big deal. GregorB (talk) 11:18, 26 March 2011 (UTC)

Bug in diff.js

Hi. I found a bug in your diff.js: Look at this diff (don't care about the text, this was the example I found the bug in, and I didn't look for an English example). There is a move shown, which looks like only the comma and the space was moved. If you look at the HTML source, you can see that the deleted "also" and the inserted "wenn man" are in the moved block too, which is kind of strange. But even if you accept this to be a move, it is wrong still, since the following "einfach" should belong to the moved block too. I hope you are able to find the bug in your diff.js. --Schnark (talk) 07:29, 11 April 2011 (UTC)

In certain cases, the results are counterintuitive, especially for many close minor changes of common words and when block moves are involved. I would not call this a bug. Cacycle (talk) 17:07, 8 May 2011 (UTC)

The diff suggests that the word "einfach" wasn't changed. But it was changed: It was moved from the point where the yellow arrow shows a move to the place where it is shown in the diff. But it is not highlighted yellow as it should. The span with the class wDiffHtmlBlock should end after the word, not before it.

It should be possible to restore both the old and the new text from the diff, by omitting either the inserted or deleted blocks and by putting moved blocks either where they were or where they are now. But in this case you can only get the new text correctly in this way, the old text can't be restored from this diff. --Schnark (talk) 09:34, 10 May 2011 (UTC)

It is even possible to hide vandalism: [1] If you only look at the text marked as changed you won't notice the vandalism that occured. --Schnark (talk) 07:44, 12 May 2011 (UTC)

Screenshots to show the bug: "Vandalism is" should be yellow. --Schnark (talk) 08:31, 17 June 2011 (UTC)

• 
  What it looks like
• 
  What it should look like

Edit window size

I'd like to customize the size of the edit window in my browser and I'm a wiked user. Is there a customization bit for that, or will I need to do something special?
— V = IR (Talk • Contribs) 14:08, 19 April 2011 (UTC)

• To do that, you can drag the grip handle at bottom right of the edit window. -Pgan002 (talk) 03:39, 26 April 2011 (UTC)
  • You can chose the textarea size in your wiki preferences, wikEd keeps the default size. You can also use the fullscreen mode which is a persisting setting. Cacycle (talk) 07:03, 6 May 2011 (UTC)
    • Is it possible to calculate the text area height depending on the window height? it seems this should be already happening in

wikEd.SetEditArea(), but for me it always comes up a standard height. -Pgan002 (talk) 01:25, 24 December 2011 (UTC)

• • • Full-screen mode is great! But it should resize area dynamically if the window gets resized, or if the Find bar is shown or hidden (for example in Firefox) or a notification bar appears (in Firefox). Is that achievable? I noticed that the width does change dynamically.

Google Chrome

Google Chrome does not work. Version may be due. I'm using version 12.0.712.0 Beta.--Ğaaw (talk) 10:12, 23 April 2011 (UTC)

The latest version, 0.9.99, failed on Google Chrome 12.0.742.100 with MediaWiki 1.15.5-3 on Ubuntu Natty 11.04 64 bit and on Google Chrome (version unknown) with MediaWiki version 1.16 (I think) on Windows XP 32 bit. However, version 0.9.91o dated Aug 23, 2010 works on the Ubuntu setup. I won't know until tomorrow if it works on the XP setup. See the previous versions for the download link. --216.210.84.195 (talk) 04:00, 30 June 2011 (UTC)

I confirm this, latest working version is the one from Aug 23, 2010 on Chromium (15.0.861.0 (Developer Build 97968) Built on Ubuntu 10.10). -- Trinevahepttinette (talk) 09:23, 27 August 2011 (UTC)

Weird cursor behaviour

Hello! I'm using the WikEd, which is integrated into the German Wikipedia on Firefox 4.0 and Windows XP. I know the following two problems:

• When I remove a term which is framed by ''', the cursor will skip the last '''.
• The cursor also sometimes skips an entire line, after removing a term, which is framed by square brackets for instance.

I experience the same bug in the English Wikipedia. It is easily reproducible. Access the article Ermine_Street and try removing words out of any tag letter by letter. See what happens. --Aetas volat. (talk) 09:16, 29 April 2011 (UTC)

I will try if I can fix the first problen (it's a really tricky one). The second one seems to be a strange Firefox bug. Cacycle (talk) 21:19, 8 May 2011 (UTC)

JS errors in IE 8

After enabling the wikEd gadget on Portuguese Wikipedia and going to a page like pt:Idempotência using Internet Explorer 8.0.6001.18702 I get the following errors in the console:

Error: Type mismatch
javascript&smaxage=21600&maxage=86400, line 15568 character 3
		domElement.detachEvent('on' + eventType, domElement[eventType + eventHandler]);

and

Error: Object doesn't support this property or method
javascript&smaxage=21600&maxage=86400, line 15547 character 4
			domElement['wikEd' + eventType + eventHandler](eventRootElement.event);

Could this be fixed? Helder 20:46, 9 May 2011 (UTC)

minor bug considering new lines and highlighting

New lines created at the beginning of the document will already possess the highlighting of the following lines, no matter what you write there. It's distracting me slightly.

It's reproducible. For instance, open the page [2], go to the start of the document, press enter two times and start writing. The text will adopt the highlighting of the following lines, no matter the content. --Aetas volat. (talk) 13:30, 30 May 2011 (UTC)

Supplement: It's not just highlighting, but formatting in general. --Aetas volat. (talk) 16:03, 30 May 2011 (UTC)

Font sizes and memory usage

There are two big disadvantages I find to using wikEd: memory usage in Firefox and font sizes.

• Memory usage: one load of wikEd after some WP browsing, especially long pages, can take up 100+ MB of RAM. Several more edits can easily push the memory usage of Firefox over 550 MB, and by the time it reaches 820 MB, the browser is sluggish to the point of inusability. Restarts of the browser fix the situation, but it's very inconvenient.
  • User Note: doesn’t seem to be a problem under OS X Lion/Firefox 6 beta. Opening multiple edit windows on the entire Barack Obama article did push up RAM allocation to FF6 past 800MB (and slow things down), but memory was released once the edit windows were closed (back down to ≈525MB [still a hefty chunk]). The buglet described below, and the solution below it, still do apply on this platform, however. —Schweiwikist (talk) 10:37, 8 August 2011 (UTC)

• Font sizes: This is probably a very common complaint, but when you try and paste texts from a page title or level 1 heading, it appears as a large font size and with breaks before and after. The easy way of getting rid of the breaks involves placing the cursor after the last character of normal text and pressing "delete". But it does not work in every case and one must sometimes undo and press backspace from before the first large character. Is this one of those Firefox bugs or what? Pasting of most other text results in unhighlighted but properly sized text, which I think is perfectly acceptable.

Can you please investigate these bugs? — Train2104 (talk • contribs • count) 02:25, 25 July 2011 (UTC)

For the font size, issue, I click the "[T]" button ("Convert pasted content to plain text, update highlighting"). It works every time. Chris the speller ^yack 13:16, 25 July 2011 (UTC)

Removes empty comments

• wikEd version: 0.9.99 G; browser: Firefox 6.0; no JS errors in the console; skin: Vector; addons and other scripts: several, but problem persists when they are all disabled.

When I edit the page Template:Navbox with columns (unprotected copy at User:Ucucha/sandbox), a few empty comments get removed before I make any change to the wikitext. See the revert here. This can be reproduced by editing the page and clicking "Show changes"; it will show that these two comments are removed. This no longer happens when I disable wikEd and it does happen when I disable all other scripts and browser add-ons I have. Ucucha (talk) 23:17, 22 August 2011 (UTC)

Fixed in version 0.9.100 Thanks for reporting, Cacycle (talk) 11:42, 4 September 2011 (UTC)

And thanks for fixing it. Ucucha (talk)

Had to roll this back in 0.9.100a, but will hopefully be able to finally fix it soon. It is actually not a trivial problem... Cacycle (talk) 07:18, 7 September 2011 (UTC)

insertTags fails on empty textareas

WikEd's insertTags() fails on empty textareas. It happens mostly on Special:Upload, as the textarea in edit page mode always contains "\n".

The following patch fixes it:

Index: WikEd.js
===================================================================
--- WikEd.js	(revision 1623)
+++ WikEd.js	(working copy)
@@ -9651,6 +9651,8 @@
 //
 
 wikEd.FindBoundaries = function(word, line, para, whole, selection) {
+	if (!whole.plainArray.length)
+		return;
 
 	// get the start node and offset
 	var startNode = selection.range.startContainer;

Preview doesn't work properly in Safari

In Safari 5.1 under Mac OS 10.7, clicking on the same-page preview button (the magnifying glass) results in a generated preview where templates are not expanded, but instead appear in their source code form. Firefox works properly. Hgrosser (talk) 03:41, 1 September 2011 (UTC)

Quotation characters

Across the quick insert bar, or whatever it's called, I'm concerned about the inclusion of these ‘single’ and these “double” accents, and being able to surround words with one-click whilst the 'single' or "double" straight quotation marks do not, they only appear one at a time. Per MOS:PUNCT:

Quotation characters

Do not use grave and acute accents or backticks (`text´) as quotation marks (or as apostrophes).

There are two possible methods for rendering quotation marks at Wikipedia (that is, the glyphs, displayed with emphasis here, for clarity):

• Typewriter or straight style: "text", 'text'. Recommended at Wikipedia.
• Typographic or curly style: “text”, ‘text’. Not recommended at Wikipedia.

The exclusive use of straight quotation marks and apostrophes (see preceding section) is recommended.

I come across a lot of articles using the non-recommended style, grave and curly quotations and am quick to copy-edit. Perhaps this part of wikEd should be designed to default to, and encourage, the use of straight style characters also, to help editors out in this matter?

Ma®©usBritish ^[talk] 09:12, 1 September 2011 (UTC)

Now that you brought it to my attention, it gives me the willies, too. And those glyphs following the degree sign are not double and single straight quotation marks, but double and single primes, I think. I agree that it would be helpful to have the surround ability for the straight form of single quotation marks and, especially, double quotation marks. It would be very, very helpful for articles with lots of song titles. I once wrote my own custom button for this, but it soon caused problems. Chris the speller ^yack 14:55, 1 September 2011 (UTC)

Oh, yes now I look closely, yes they are primes.. for feet and inches, mins and secs etc 5′11″ vs 5"11' doesn't look much different in the edit box unless you squint. Still, would still help to have the inset bar with "' before ‘’“”°″′, as you say, they're a pest on pages with albums, or edited by people where English characters are not their first language and the insert bar looks convenient to use. Ma®©usBritish ^[talk] 22:18, 1 September 2011 (UTC)

wikEd has nothing to do with that - wiked is only the grey button bars. Cacycle (talk) 19:55, 3 September 2011 (UTC)

Sorry, just re-read the request. Yes, this sounds like a good idea for a fixing butten and should be relatively easy to implement. I will try to add this as soon as I find some time. Cacycle (talk) 07:15, 7 September 2011 (UTC)

Disable Pasting of Rich-text

I sort of asked this once before, but it bears repeating: Is there a way to disable rich-text pastes from being pasted as rich text? Currently, whenever I want to paste into the edit box I first paste into my search bar, then copy that text and paste it into the wikiEd editor. This method removes any formatting. Or I paste into Notepad, then copy, then paste into wikiEd. This is a huge pain. Is there anyway to make all pastes act as plain text? I only use wikiEd for its syntax highlighting as it is, and having this paste method I've devised is a bit of a hassle. --Odie5533 (talk) 11:23, 17 September 2011 (UTC)

Unfortunately not because this is done by the browser, not by wikEd. There is no reliable way for JavaScripts to intercept these events. I know it is a major annoyance. Cacycle (talk) 16:30, 17 September 2011 (UTC)

Perhaps an option to automatically remove the highlighting by pressing [T] after a user performs a paste, and then return to the right cursor position? Currently pressing [T] selects all. --Odie5533 (talk) 22:59, 17 September 2011 (UTC)

Please see also User:Cacycle/wikEd help#Automatic syntax highlighting for more details. Cacycle (talk) 19:29, 18 September 2011 (UTC)

You could add a "Plain-text pasting" text input field to the WikEd toolbar. Pasting text into it would automatically insert that text at the cursor position (or replace the selected text) in the text area. It could be done as a text input field above WikEd through a user script, but it would be nicer if it is a built-in function. --V111P (talk) 03:49, 24 December 2011 (UTC)

Ok, apparently you can use Shift+Ctrl+V to paste as plain text in Firefox and Chrome. Chrome even has an option "Paste as plain text" in its right-click context menu. --V111P (talk) 02:41, 25 December 2011 (UTC)

New Wiki Look Compatibility

Is there any way to use WikEd as a userscript with the new Wiki look (Oasis I belive)? --Pichu659 (talk) 10:59, 26 September 2011 (UTC)

Tabbing

Did something change with the tabbing? For some mysterious reason, tabbing out of the edit textarea to the edit summary now fails to select the content of the edit summary (instead inserting the cursor at the beginning of the input), which is the behavior behavior anywhere that I know in computing. Circéus (talk) 16:48, 14 October 2011 (UTC)

Sig Button

This is probably the only feature to be added with WikEd. On user talk pages its annoying to have to toggle between the standard toolbar and wiked only. --Kangaroopowah 22:21, 23 October 2011 (UTC)

Ref hiding bug

In this edit I used the "[REF] and [TEMPL] hiding" feature to make the text easier to edit, but it removed the </ref> tag at the end. —danhash (talk) 18:35, 31 October 2011 (UTC)

Cannot get wikEd to display at all. Followed instructions, but still no dice.

I've installed the extension completely on my site. I'm trying to set it site wide. I've added the lines to the localsettings file, added all of the .js pages to my install. Tried it both as a gadget, and as a full local install. No dice either way.

Anyone care to take a look, I'd be happy to provide you access. I'm just not sure what I'm missing. --Fadmwheeler (talk) 03:46, 22 November 2011 (UTC)

Please could fill out the bug form (see top of the page)? Please feel free to send me your site's details using the E-mail this user page. Cacycle (talk) 13:35, 26 November 2011 (UTC)

WikEd version is the latest version. I've tried this is IE 9, Firefox, Chrome, and Safari to no avail. (I am a coder myself, so I generally verify which platforms will function for my users). No errors, the addin just doesn't load at all, it's like it's ignoring the commands all together. No browser add-ons except Java. No affect if i disable the add-ons. Using Pixeled skin, although i've tried it in MonoBook and Vector as well to no avail. (We have moved some items in CSS in pixeled, so i understand it wont look EXACTLY the same, but we have tried it in the out of the box monobook and vector styles as well. Using Windows XP and Windows 7, no change in either. The problem is simple, the script just doesn't load. There is no evidence that it is ever taking affect. I have e-mailed you my site information. I appreciate your help! Fadmwheeler (talk) 15:24, 27 November 2011 (UTC)

Your problems are caused by 1) the semicolon at the end of line 21 in your MediaWiki:Common.js (see your error console) and 2) by the Pixelated skin (I have added support for it to the next release going online soon). Cacycle (talk) 23:32, 13 December 2011 (UTC)

It should work now, please update your copy of wikEd to version 0.9.102 (January 03, 2012) (or, even better, load wikEd from its official page so that you get updates automatically). Cacycle (talk) 11:45, 4 January 2012 (UTC)

window.wikEdUseWikEd is undefined

window.wikEdUseWikEd is undefined even when WikEd is on, so old scripts can't detect WikEd and some of the examples in WikEd's documentation don't work. (Firefox 6 & Chrome 15, Windows OS, wikEd 0.9.101, Vector skin.) --V111P (talk) 04:00, 2 December 2011 (UTC)

Please could you provide more details? Why exactly do you think that window.wikEdUseWikEd is undefined? Please also provide details about your system and configurations (see the top of the page for the bug report form). Which examples do not work? Cacycle (talk) 19:10, 3 January 2012 (UTC)

Insertion of special characters fails

I'm using wikiEd as a gadget in ro.wp and en.wp on Firefox 7. I've noticed that if I try to insert a character from the new Vector toolbar, it only works on the first click. On subsequent clicks, the cursor jumps around, but nothing else happens. Debugging with Firebug, it would seem that everything goes ok until the execCommand('insertHtml'), which for some reason fails. If I disable wikiEd, everything goes back to normal. Has anyone else seen this behavior?--Strainu (talk) 08:23, 17 December 2011 (UTC)

Fixed in wikEd 0.9.102 (January 03, 2012), thanks for reporting. Cacycle (talk) 19:06, 3 January 2012 (UTC)

How can I disable thumbs within syntax highlighting?

When syntax highlighting is enabled, thumbs of used images are shown within the text editor window. This is confusing and buggy (tiny images are repeated to fill a certain width). How can I dsiable those thumbs while keeping normal syntax highlighting? --Subfader (talk) 15:22, 30 December 2011 (UTC)

Images are only repeated when the image size parameter is not set (e.g. instead of ). It is not exactly a bug as there is no other way to implement this without knowing the image size. In order to turn image preview off, you might try

wikEdConfig = { 'filePreview': false };. See User:Cacycle/wikEd customization for details. Cacycle (talk) 19:18, 3 January 2012 (UTC)

Thanks a lot that worked :) --Subfader (talk) 19:04, 4 January 2012 (UTC)