User talk:Cacycle/wikEd/Archive 009#Newbie question: Shortcut keys

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)

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 [http://www.mediawiki.org/wiki/Extension:Inputbox 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 [http://www.mediawiki.org/wiki/Extension:Inputbox 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)

As my browser (Firefox 2.0.0.14) is loading [http://en.wikipedia.org/w/index.php?title=Talk:Gilles_Deleuze&curid=5870358&diff=216069624&oldid=216069408 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)

Version is 0.9.62g. See [http://en.wikipedia.org/w/index.php?title=Mozilla_Firefox&diff=219141763&oldid=219136554 this diff]. Apparently it's related to [http://en.wikipedia.org/wiki/User_talk:Cacycle/wikEd/Archive_006#WikEd_makes_Firefox_freeze_on_a_specific_article this]. GregorB (talk) 19:44, 13 June 2008 (UTC)

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

My config:

• wikEd: 0.9.64b

When copying rich text with many paragraphs left-indent, wikEd adds a

section.

But

needs the

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

marks with
marks within

.

Another solution would be to use the [http://www.mediawiki.org/wiki/Extension:Poem Poem extension] (it adds
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 mark (as wikEd acutally does with blockquote), then the whole quote is itallic. For instance:

''
Au clair de la lune,
Mon ami Pierrot:
Prête-moi ta plume,
pour écrire un mot.

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)

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)

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)

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 [http://en.wikipedia.org/w/index.php?title=MediaWiki:Gadget-wikEd.js&diff=252370894&oldid=251715967 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 . 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)

:::::: [http://en.wikipedia.org/w/index.php?title=Wikipedia:Sandbox&oldid=252791596 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)

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/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/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 Image:WikEd_fix_all.png button? The css error messages are not caused by wikEd. Cacycle (talk) 01:57, 24 November 2008 (UTC)

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 [http://www.i3g.hs-heilbronn.de/attach/Ver%C3%B6ffentlichungen/What+you+see+is+Wiki.pdf 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 [http://www.corel.com/servlet/Satellite/us/en/Content/1153321168468 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 [https://bugzilla.mozilla.org/show_bug.cgi?id=458524 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)

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/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/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/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/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/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)

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)

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)

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)

I just ran into an unclosed ref tag, and because the syntax seemed correct, I asked at HD. The edit diff is [http://en.wikipedia.org/w/index.php?title=Building_insulation&action=edit&oldid=255973486 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)

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 [http://en.wikipedia.org/wiki/User_talk:72.148.61.160 this] user. Prowikipedians (talk) 12:02, 8 December 2008 (UTC)

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)

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)

• 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)

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;';

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

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)

::I had a similar error when using the Greasemonkey script "Wikipedia with NoScript". Ensure that your Greasemonkey install is current, and the script to add WikiEd doesn't conflict with another you're using. --King Öomie 17:41, 21 August 2009 (UTC)

i am in korean translation.

while editing, for example, when i put a mouse on the

Image:filename

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)

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)

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)

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)

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)

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)

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 [http://en.wikipedia.org/wiki/Wikipedia_talk:AutoWikiBrowser/Typos#bug:_capitalizes_every_instance_of_words_beginning_with_.22th.22 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)

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: [https://bugzilla.mozilla.org/show_bug.cgi?id=428096 bug 428096]. Cacycle (talk) 14:25, 27 January 2009 (UTC)

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 encyclopediareference. (punct. at end)
  
• Wikipedia is an encyclopedia. reference (extra space)
  
• Wikipedia is an encyclopedia reference. (extra space and punct. at end)
  
• Wikipedia is an encyclopedia.reference. (duplicate punct.)

It should read:

• Wikipedia is an encyclopedia.reference It is really thorough.
• Wikipedia is an encyclopedia;reference 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)

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:

:

: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)

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)

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)

Hi, I work on Wikisource fr and I would realy appreciate wikEd to work properly in proofreading mode ([http://fr.wikisource.org/w/index.php?title=Page:Henri_IV_-_Lettres_Missives_-_Tome1.djvu/91&action=edit 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)

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)

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)

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 [http://en.wikipedia.org/w/index.php?title=Technological_singularity&oldid=270087601 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 [http://en.wikipedia.org/w/index.php?title=Deluge_myth&oldid=270257796 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 [http://en.wikipedia.org/w/index.php?title=Flood_geology&oldid=270281209#Genesis_and_the_Flood 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)

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)

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/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)

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

1. Click e.g. [http://en.wikipedia.org/w/index.php?title=User_talk:Cacycle/wikEd&action=edit§ion=new 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 Image:WikEd_textify.png. Cacycle (talk) 14:44, 19 February 2009 (UTC)

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)

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)

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)

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 Image:WikEd_logo.png 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)

In diff pages wiked makes links lickable right? But there's a bug for which external links work wrong (see for example [http://en.wikipedia.org/w/index.php?title=Diamond&diff=next&oldid=262849237 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 [https://bugzilla.mozilla.org/show_bug.cgi?id=440926 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)

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)

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 (Image:WikEd_syntax.png button)? Your help would be greatly appreciated. Thanks in advance, Cacycle (talk) 03:36, 6 March 2009 (UTC)

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 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)

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)

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)

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 (Image:WikEd_syntax.png button)? Your help would be greatly appreciated. Thanks in advance, Cacycle (talk) 23:35, 12 March 2009 (UTC)

(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)

1. Steps to reproduce:
2. Follow site-wide installation instructions
3. Edit MediaWiki:Common.js
4. Paste in installation code
5. User:Cacycle/wikEd in-browser text editor
6. document.write('