User talk:Cacycle/wikEd/Archive 003

Spaces

I use wikEd on the Dutch Wikipedia and I really enjoy using it, except for two things. The first is that I've come across a problem with spaces there. Sometimes wikEd simply removes spaces when I move (copy and paste) a piece of text. Is this some English specific function? If so, can I turn it off? One of these edits is [1], where wikEd removed the spaces between artikelen and beginnen, aantal and deze and de and beveiliging. Do you have any idea what causes this? The second is that I can't simply press Tab to go to the summary field, just like mentioned at #WikiEd suggestions. Is it possible to specify in monobook.js what you want tab to do? I.e. either add four (?) spaces or go to the next edit field. Thanks in advance and thanks for creating wikEd :) --Erwin85 19:25, 16 November 2006 (UTC)

Actually I have never experienced this and it's definitely not a crazy English function :-) Please could you try to figure out when exactly it happens so that I can reproduce it - that's the only way to fix it. Do you see it right after pasting, after using wikEd buttons, after switching to the classic textareaor, or after saving.

The tab problem is a tricky one, but I will try to find a way to make the tab button work again.

Cacycle 23:32, 16 November 2006 (UTC)

The Spaces problem sounds like the problem with Francis E. Dorn I reported above in "First look at the latest version - diff diffs - spaces?" I'm not comfortable saving a page where someone looking at a diff will see changes reported in paragraphs I didn't touch. --CliffC 00:39, 17 November 2006 (UTC)

Actually it is caused by trimmed spaces at the end of lines. If will try to fix that in one of the next versions. Cacycle 04:11, 19 November 2006 (UTC)

The Tab-to-summary function has been added to the next version. Cacycle 05:53, 20 November 2006 (UTC)

Thanks, Erwin85 19:30, 20 November 2006 (UTC)

I have found and fixed the space-eater bug. Please update (Shift-Reload). Cacycle 05:52, 22 November 2006 (UTC)

I'm using wikEd again and it looks good, I know everyone here appreciates the hard work that has gone into it. I tested for the 'spaces' problem with Francis E. Dorn again and it is fixed, good show. I turned up a similar but less severe problem elsewhere, diff HERE shows a change in a paragraph I didn't touch. Thanks for listening to these small but pesky problems. --CliffC 04:47, 23 November 2006 (UTC)

Thanks :-) Your problem is cause by removed spaces at the end of a paragraph. I will change that soon. Cacycle 05:11, 23 November 2006 (UTC)

Fixed in version 0.9.10 Cacycle 05:21, 24 November 2006 (UTC)

HELP!

Dosent work for me. Appears but then dissapears. Unable to edit useing script on FF. My JS file

The Fox Man of Fire 21:40, 17 November 2006 (UTC)

Disable the User:Topaz sectionsplitter by deleting the following line: inc("User:Topaz/sectionsplitter.js");". wikEd and this script are incompatible. Cacycle 22:51, 17 November 2006 (UTC)

How about a wikEd user box

How about a wikEd user box? You might find more people using wikEd -Will Pittenger 06:34, 18 November 2006 (UTC)

This user edits with the gadget wikEd.

Paste the following text to your page:

{{User:Cacycle/wikEd userbox}}

Cacycle 00:33, 19 November 2006 (UTC)

<code> button needed

Please add a button to apply <code> tags to the selection. -Will Pittenger 06:39, 18 November 2006 (UTC)

More space needed

As wikEd toolbars grow, a problem crops up at Wikia.com. They require viewers to surrender part of their screen's width to Google ads (and a few others too). This prevents your toolbars from fitting as designed. (In fact, the newest version doesn't even fit on Wikipedia for me.)

It would help if I had a monitor that was designed for more than 1024x768. You might have to resort to two lines. Now if you know how to move my sidebar into drop menus along the top as shown here... then I could reclaim some space. -Will Pittenger 06:43, 18 November 2006 (UTC)

Fixed in 0.9.18. Cacycle 02:50, 8 January 2007 (UTC)

History lists non-changes as changes

Sometimes, when editing an article with wikEd, the page's history lists changed sections that weren't actually changed. For example, if you look at the List of Chinese Martial Arts history from my last edit, you'll see numerous lines listed in change notation even though no changes were made to those lines (edit was made with wikEd 0.9.8). -Erik Harris 01:04, 19 November 2006 (UTC)

That is caused by trimmed spaces at the end of lines. If will try to fix that in one of the next versions. Cacycle 04:10, 19 November 2006 (UTC)

Fixed in version 0.9.10 Cacycle 05:19, 24 November 2006 (UTC)

Unexpected cursor movements

If I paste from the clipboard, or delete text with the Delete key, wikEd moves my cursor to either the top or bottom of the window. -Will Pittenger 05:22, 20 November 2006 (UTC)

The same thing happens if I delete the "[[" before an internal wikilink. For instance, if you edit WP:V, on the first line, move the cursor over, delete the double bracket from "[[Wikipedia:Vandalism]]", and then hit delete again to delete the "W". It won't delete the letter because the cursor is somewhere else. This is a persistent problem. --Flex (talk|contribs) 14:12, 15 February 2007 (UTC)

This is a browser bug, one of the many rich text editing related ones. Some of them, including Flex's problem, have already been fixed in the upcoming Firefox releases. It is always important to have a simple test case to replicate the bug, however, I could not yet find a reliable way to replicate Will's problem.

Ok, and thanks for your excellent work! You are indefatigable and very helpful. :-) (BTW, I see this problem with Firefox 2.0.0.1.) --Flex (talk|contribs) 15:21, 15 February 2007 (UTC)

Modified layout below the save button

How about modifying the Insert section? Some of it is duplicated by wikEd. Other parts just take up room. Many times I am trying to get to Wikipedia's preview window (for something LivePreview handles incorrectly) and I have to scroll past all that. The later would be solved if that section could collapse when not needed.

Perhaps you could do the same with the template list. -Will Pittenger 06:49, 20 November 2006 (UTC)

Go to 'my preferences' and check 'Show preview before edit box' under 'editing'. Cacycle 23:24, 23 November 2006 (UTC)

Sorry. I originally had that, but got tired of scrolling past long articles to get to the edit box. This would be mute if LivePreview could more completely replace the standard preview. -Will Pittenger 04:02, 24 November 2006 (UTC)

Then update to 0.9.10, it has a jumper at the top of the standard preview section. Cacycle 05:19, 24 November 2006 (UTC)

Installation does not work

I have tried out the installation and put the content of the Simple Version of the Installation Code into my
userpage http://mydomain/wiki/index.php/Benutzer:Karsten/monobook.js and make many refreshs in my Firefox 1.5.0.7 but nothing happens :-(

Maybe the reason is that i am using a german installation (you see Benutzer instead of user or it is that i am using a MediaWiki Version 1.3.11 ?
(It will be not a problem to install the current stable version)

The complete installation-process looks for me very suspect.

• Why should an insert of an {{subst:wikEd}} in my page install something ?
• And how the simple version will do it ? (A little more explanation to understand would help)
• Will the Javascripts be copied to my wiki on the Server ?
• And what's about the corresponding images ?
• The function of "Pasting formatted content, e.g. from MS-Word" is fine but after doing it the source is not good to read. It would be fine if there would be also a translation without the HTML functionality. Just using the simple formatting options bold' italic underline and the important feature of processing tables.

Maybe i'm to stupid or i can't see the forest because of too many trees?
Kmalcher 18:00, 20 November 2006 (UTC)

The template substitution of the ultra-simple version does only work on the English Wikipedia, try {{subst:en:wikEd}} instead from the other language Wikipedias. It does not work for a non-Wikipedia wiki. Check the template page Template:wikEd and the general Wikipedia help on templates for how it works. The javascripts specified in the simple version will always be loaded to your computer from the English Wikipedia, independent of which wiki you use, including non-Wikipedia wikis. The images are hosted on the Mediawiki Commons. To 'unformat' the pasted content simply press the [T] button and to wikify it press [W]. There cannot be a simpler solution because wikEd relies on the browser's integrated rich text editor. Hope that answers your questions, Cacycle 00:51, 21 November 2006 (UTC)

After i have written the text i have tried out the installation in this wiki here and - of course - it works.
But this didn't answer my questions how to use this editor in other wikis.
It's a pity that this editor only work in a Original-Wiki, because i find it is great. It is at least simple to implement and as i have understand without patching the Original Wiki. But the main thing is that it can do a really conversion into the wiki syntax. The other editor-implementations i looked for are working only in HTML
Up to now i thought that the MediaWiki is basing on the same software of the Original-Wiki ?
So what can i do to get a Wiki with your Editor ?
Kmalcher 09:48, 21 November 2006 (UTC)

You misunderstood me, wikEd works with any MediaWiki installation (at least if it is a recent one). The clutter after wikifying Word content is a bug, i will check that later. Cacycle 19:03, 21 November 2006 (UTC)g

Sysanalyst 21:37, 21 November 2006 (UTC) This is not true. I have many MediaWiki installations and WikED won't work on any of them. There is some special add-on that is required but I've not found out what it is as of yet. The folks on the MediaWiki help board refer me back here to no avail. I really wish I could get this to work, but it just doesn't.

Sysanalyst: what JavaScript console error do you get when you try the current version. Can you please post the html source of an empty edit page here (inserted between <nowiki><pre>...</pre></nowiki> tags, I will remove it later) or me give access to your wiki. Cacycle 23:35, 21 November 2006 (UTC)

Sysanalyst 19:44, 22 November 2006 (UTC) Here is a screen shot of the error message;

The error is different today than the other day, most likely due to changes in wikED. The buttons function to a degree, but the changes are not saved (we hit the java error prior to save?). I've been able to reproduce this error on several different Wiki's. I'd love for you to have access to my Wiki's, but they are behind a firewall. If you'd like to try using WebEX or NetMeeting let me know and you can Wiki away.

Fixed that one for you, try it again after Shift-Reload. Please copy the error text with Ctrl-C (if there is one). Cacycle 22:49, 22 November 2006 (UTC)

Thanks and outstanding work Cacyle! The Java errors are all gone and WikED is working very well. Thanks for your hard work and dedication to WikED. Sysanalyst 14:54, 27 November 2006 (UTC)

O.K. It's fine that i am not alone with the problem and that a solution is discussed :-)
But - the question of some short installation-instructions on an other wiki are still open ...
Javascript-programming and the internal functions of mediawiki are not my world, but maybe i can help to debug the problem ?
Kmalcher 15:12, 23 November 2006 (UTC)

If you really need an "ultra-simple installer" on your wiki then read about templates and template substitution and copy the Template:wikEd page to your wiki. Re: helping: go ahead... Cacycle 17:19, 23 November 2006 (UTC)

What i really mean is how to install the editor independent from http://en.wikipedia.org, for instance on a local Webserver with no internet-connection.
So i can't use your simple-installation. And it is generating unnecessary traffic on the wikipedia.
When i look in the main-script wikEd.js i can see that it is hardwired to wikipedia. To install it locally i must

• Extract the *.js scripts
• Extract all the png-images
• Edit all the hardwired pathes
• Install / transfer all somehow in a local mediawiki

Is this correct and is there no better or easier way ?
Kmalcher 11:09, 24 November 2006 (UTC)

Yes, you have to copy all .js files from the wikEd installation code to your own server, the same is true for the images, just follow the 'Images' link in the wikEd jumper box on this page. All paths are user-customizable from user or general .js pages, check the customization section. You could also change the paths directly in the main program, they are all on top of the code. If it works, please could you write a how-to to be put on the wikEd page. Thanks, Cacycle 22:16, 27 November 2006 (UTC)

OK - this should be done. An I think it would be helpful when you concentrate on developing the editor and shawn and myself look for the installation-procedure on local servers.
As i have written in shawn's section i have not to much time to do that but i will try to give my best ;-).
Some points:

• You should tell me (us) when we have a stable Version of the Editor for the moment. It make no sense to make something like a package when the source is not stable and will be changed often.
• We must define an alternative installation in the way that you have normally console- or ftp-access to a server where we want to install the editor. So it would make sense to put all the *.js and *.png into physical pathes on the webserver ?
• Maybe we can use the unix patch utility to make a new "local version" of the editor instead of editing every new release. So the source must fit to do this easily ?
• When we defined how to do it i will write the correponding HowTo.

Kmalcher 11:02, 28 November 2006 (UTC)

I've also got problems with installing WikEd on a local mediawiki installation, unfortunataly; no errors, nothing at all! It seems monobook.js on my userpage does not "load" anything of the external file (ps. the local webserver has access to the internet). Is there anyway to make wikEd the standard editor for the mediawiki installation? Boris 19 feb. 2007 (update, I've read in a post further down that adding: $wgAllowUserJs = true $wgAllowUserCss = true to the LocalSettings.php would help. Maybe you should at it to the installation description since this did the trick!!)

Syntax highlighter can't count

I noticed that when I edit an image link with links in its description, the syntax highlighting is broken. As a test, take the code below out of the nowiki link and see what happens.

[[Image:First Electric Tree.jpg|First [[Christmas tree]]with electric lights, in the home of [[Edward H. Johnson]] in [[New York City]], [[December 22]] [[1882]].]]

-Will Pittenger 07:30, 23 November 2006 (UTC)

Thanks, I have already noticed that myself. I will try to fix that (and several of your other suggestions) soon. Cacycle 20:13, 23 November 2006 (UTC)

Lost trailing ">" of an html comment

It appears that wikEd lost the trailing angle bracket of an html comment, near the bottom of the diff HERE, causing part of the article to disappear from view after being saved. Everything up to the "-->" closing a later comment was considered part of the first. BTW, Happy Thanksgiving! --CliffC 17:35, 23 November 2006 (UTC)

Thanks :-) I have tried hard, but I could not reproduce that. Maybe you have done it accidentally yourself? Can you reproduce that by editing the old version again? Thanks and many barnstars... Cacycle 20:11, 23 November 2006 (UTC)

Hmm, I can't make it happen again, so maybe I did do it by accident. I thought it might have something to do with the fact that the article started with a section header – I clicked on its '[edit]' to work on just that section, then removed the header along with making a few other changes. I'll keep an eye out. --CliffC 01:46, 24 November 2006 (UTC)

FWIW and for the sake of completeness, the trailing ">" was the last character of the section I edited. --CliffC 03:41, 28 November 2006 (UTC)

Paste issues

I have noticed that some situations odd things happen when I paste into wikEd pages. Some are only cosmetic. Something like that would be what happens when you paste a link. However, others are more serious, at least if you click the Update Syntax Hightlighting button.

First, if I paste an entire header from a page, it adds a newline before the header text (and sometimes afterwords). It also shows a newline after the header text. If you then hit the Update Syntax Highlighting button, it adds equal signs before and after the text.

Next, please paste the entire text between the arrows into wikEd: →text← and press Update Syntax Highlighting. wikEd will reproduce the <small> tags I included.

As you may recall, a while back, I suggested something along the lines that would have wikEd detect rich text and offer to either strip it or convert it to Wiki syntax. I think this option would help both problems. -Will Pittenger 04:59, 24 November 2006 (UTC)

Unfortunately, all these suggestions are nearly impossible to implement. wikEd relies on the browser-internal rich-text editor. So any changes to the edit frame that do not go through its interface erase the undo/redo history. And I hope you are not seriously suggesting to implement pop-up windows... Cacycle 05:17, 24 November 2006 (UTC)

Could you trigger a clean up code after a paste? As for the poppt thups, a script that adds tabs to warn users pops up a dialog to ask which page to warn the user about. (I don't know which script that was.) A JS window as a CSS layer would preferred over a Windows dialog. (With that other script, I can't go back to check the page name.) -Will Pittenger 05:39, 24 November 2006 (UTC)

No, for the reason mentioned above. Either it destroys the undo history or it adds to it. It is also not easy to detect pastings (e.g. mouse drops). Cacycle 06:11, 24 November 2006 (UTC)

On a second thought, one could detect new html content on the page after every mouseup and keypress Ctrl-V and then syntax highlight it with an anchored box offering the two options (wikify or textify). I will think about it and all implications. At least the syntax highlighting part sounds interesting, maybe it should blink or get a red or black background... Cacycle 16:54, 24 November 2006 (UTC)

New button bug

The new buttons to take users from the standard preview to the edit box ends up on top of the edit box when I add a new section and have not previewed the text. -Will Pittenger 05:47, 24 November 2006 (UTC)

Fixed, please reload. Cacycle 06:07, 24 November 2006 (UTC)

New RegEx button of no use outside AWB

Please hide the new RegEx button for AWB if I am running something other than AWB. -Will Pittenger 05:48, 24 November 2006 (UTC)

Why? It is completely independent, see the help page. Cacycle 05:57, 24 November 2006 (UTC)

If it works in Firefox, why is it disabled for me? -Will Pittenger 08:00, 24 November 2006 (UTC)

See the help page :-) Cacycle

Do you have an offical presence on Wikia.com?

Do you have an offical presence on Wikia.com? If not, you might consider creating one. It would also help you by providing a place to test your code. As it turns out, the user name Cacycle is available. -Will Pittenger 05:07, 27 November 2006 (UTC)

Thanks, but I think I don't have time for that. I am already wasting too much time for this  :-) Cacycle 22:18, 27 November 2006 (UTC)

It would not be quite as useful, but I could serve as your representative there. I would probably be telling you about any problems there as well has hosting your Wikia pages. For all I know, you might need a Wikia specific version. I would not be able to edit that (I know no JS). But I could host the code. Not a whole lot of help, but it's better than nothing. -Will Pittenger 01:03, 28 November 2006 (UTC)

Problem with wikEd on non-Wikipedia installation

First off, I just want to say that I really like your editor - it is very helpful when editing articles.

I like it enough that I am trying to implement it on my company's internal wiki so it will be easier for other employee's to enter information. However, I am having trouble getting it to work properly. My assumption is that I have something set up improperly in either the web server or in Mediawiki but I am out of ideas on what to check. Here are the specifics:

Web Sever: IIS V5.1 PHP: 5.2.0 (isapi) Database: MYSQL Server 5.1.12 Wiki Software: Mediawiki 1.5.8 Web Browser: Firefox 2.0

I have added the following settings to my localsettings.php file: $wgAllowUserJs = true $wgAllowUserCss = true

The web server is not public, but it has access to the internet. I have added all the code to monobook.js (just like I do on the Wikipedia, where it works). I've forced a refresh of monobook.js but here is what is happening:

Any page I go to, I can see that the browser is attempting to (or actually is) accessing the site en.wikipedia.org (shows in the status bar at the bottom of screen as the page loads). However, when I go into the edit screen, none of the wikEd buttons show up - it is just the default Mediawiki editor. I do not get any error messages, it just isn't working.

Any assistance would be appreciated.

Thanks,

Shawn

Mck321 15:26, 27 November 2006 (UTC)

Sysanalyst 20:51, 27 November 2006 (UTC) Java Browser Console Output? Wiki log output? Hint: $wgDebugLogFile ="/tmp/wiki-st.debug.file";

Mck321 00:06, 28 November 2006 (UTC) The Wiki log output wasn't very useful. However the Java Error Console told a different story. Here is the error I am getting: "wgServer is not defined" and the error hits at line 631 of wikEd.js where the javascript is attempting to use wgServer. I've tried manually overriding my wgServer settings in localsettings.php but the error persists.

I have now changed the script so that javascript doesn't throw the error, but that's not a clean solution. You should make sure that wgServer and the other wgXxx variables are correctly set, check the html source of any page. Did you use the right MediaWiki settings file? One has only the initial settings but is no longer used. Cacycle 00:58, 28 November 2006 (UTC)

Hello, maybe we can establish a solution together ?

When you look at the topic >Installation< you can see that i am struggling at least with the same problems.

My main problem is that i have no console access to my server under the week so i am very slow to work and implement a solution.

Kmalcher 10:35, 28 November 2006 (UTC)

Mck321 17:15, 28 November 2006 (UTC) I was able to track down the source of my problem. The problem was the version of Mediawiki that was running. I upgraded to 1.8.2 and wikEd is now functioning properly. Thanks for the assistance!

Self-inflicted edit conflict

I got an 'edit conflict' error adding to a section in Talk:Spyware; I think I had two copies of the section open in separate windows (I lost track of where one window was after entering only a few words so I just opened the section again). When I did a Save Page for the second set of edits I got the Edit Conflict message and the earlier edits were saved instead. Nothing lost and no big deal, just a little confusing. --CliffC 17:31, 28 November 2006 (UTC)

Probably not wikEd related :-) Cacycle 06:46, 30 November 2006 (UTC)

Buglet: Disabling wikEd disables "classic" edit buttons too—issue with Toolbar 0.8.0

FYI, I run Wikipedia toolbar 0.8.0 (force-enabling it in Firefox 2 with Nightly Tester Tools), and I find that disabling wE (0.9.11c) also disables the classic edit buttons (the blue row) (which offer more options than the toolbar). Conversely, toggling between the classic text area and the wE, the WP toolbar doesn't recognize the wikEd editor (toolbar buttons are not available at all when text is selected, unless the classic text area is live). I'm guessing that it requires more overhead to preserve text selection in the wikEd and classic layers when toggling, or to "hot-wire" the selection of text simultaneously in both layers, so that a user may click whichever Bold button is closest (or visible!!) to the text they're editing, regardless of the editor state (hope this makes sense).
One other buglet still is in evidence, which I find a distraction: After toggling the syntax highlighting, and the classic text edit area to OFF and/or ON, I really would like whatever status is current to be preserved after hitting the preview button. wikEd always "resets" these toggle positions during a preview execution, and this really isn't good program behavior (all the user wants is preview, nothing else). Since the new "master switch" has a memory, I'm hoping the other ones might too before "final candidate" arrives.
 Schweiwikist   (talk)  17:48, 29 November 2006 (UTC)

Oh, good idea about the toggle button. I will add that asap. The toolbar thing should be doable similar to the current tweak for the standard toolbar. Cacycle 06:45, 30 November 2006 (UTC)

Button memory has been added to the next version. The button states will only be remembered during the current browser session. Cacycle 08:19, 2 December 2006 (UTC)

Gallery tag bug

There appears to be a bug when wikEd initialyzes, it duplicates any <gallery> tags it sees. "<gallery>" becomes "<gallery><gallery>". -Will Pittenger 21:19, 29 November 2006 (UTC)

Yes, that bug irritate a lot. :/

Fixed, please update. Cacycle 01:53, 2 December 2006 (UTC)

Fixed. -Will Pittenger 04:38, 6 December 2006 (UTC)

Major bug

When I go to an edit page with the editor enabled, I don't see anything in the edit box. I have to go to the edit page with the editor disabled and then enable it before I type anything. --- Year2000Prob ^(email) 22:55, 29 November 2006 (UTC)

I don't have that problem. Are you using the dev version? -Will Pittenger 23:50, 29 November 2006 (UTC)

See User:Cacycle/wikEd#Incompatibilities, wikEd is not compatible with the Topaz sectionsplitter. Cacycle 06:25, 30 November 2006 (UTC)

{loses colons to Davey Jones' locker} Fixed. - Year2000Prob 01:25, 3 December 2006 (UTC)

wikEd international

The translation option for the [Preview] and [Changes] buttons (and symbols) are left (or remove the name changing, I think it's not necessary). --Olliminatore 14:23, 30 November 2006 (UTC)

Your script is in the german help page included, please could you hury with this fix?  :). I saw the relevant lines on 1302 (I think the symbol buttons are a bit redundant/ threefold). Thanks --Olliminatore 00:39, 2 December 2006 (UTC)

Fixed in next version. I have added the text to the end of the translation example. Cacycle 02:01, 2 December 2006 (UTC)

Redirect

The auto summary for redirect seems not working correct. --Olliminatore 18:22, 30 November 2006 (UTC)

Right now it only works if the summary is empty. I have fixed the next version so that the redirect text will always be appended. Cacycle 03:56, 1 December 2006 (UTC)

Scrolling bug in Firefox (2) [OS X] may affect WikEd: Check Preferences

An apparent bug in Firefox may affect WikEd behavior (at least under Mac OS X Tiger). If WikEd's buttons are causing unnecessary scrolling (to top), check the following in Firefox Preferences: Preferences/“Advanced” tab/“Always use the cursor keys to navigate within pages” checkbox. Unchecking (disabling) this item eliminated the unwanted scrolling bug, which also appeared for this user when browsing a non-WP website (so it's not a bug in WikEd). I can now use WikEd trouble-free (except for the necessity of typing a fresh character into the edit box before selecting/searching/replacing existing text!).
 Schweiwikist   (talk)  05:12, 6 December 2006 (UTC)

Can't install

I'm using Firefox 1.5.0.8 and Mediawiki 1.6.x. I've tried to put the Complete Installation code given into User:MyUserName/monobook.js but it seems the editor just replaces any <script> tags with /*]]*/ or something to that effect. I've tried putting in simple javascript commands like alert and confirm and those seem to work fine. I'm not sure why certain tags are removed. I don't have any special extension installed that could do that. I should also note that I have $wgAllowUserJs set to true.

I am not sure what you mean. Where and when are <script> tags removed and how do you observe that. Is wikEd already active when it happens (ie.e the logo is displayed on top of the window). Thanks, Cacycle 17:28, 8 December 2006 (UTC)

No response from Pilaf

I asked Pilaf some questions at User talk:Pilaf/Live Preview#Wishlist. I have not gotten a response. Any chance you could prod him or her about it? -Will Pittenger 04:58, 13 December 2006 (UTC)

No, he seems to be offline as judging from his last edits. Cacycle 02:38, 14 December 2006 (UTC)

Possible Layout bug

For a while, you had the This is a minor edit on the line after the subject/heading box. However, it has moved back. Also, for a while today, the Subject reset button and Pilaf's Live Preview button were little tiny boxes -- too small to show even the icons. See the attached image. -Will Pittenger 04:18, 14 December 2006 (UTC)

The problem with the icons being too small happened on Wikia.com. However, I failed to get a screenshot then (I was busy) and could not reproduce it later. Besides, I don't know if I can legally put a Wikia screenshot here -- even if most of what is shown is your stuff. -Will Pittenger 05:29, 15 December 2006 (UTC)

It's extremely difficult to add that linebreak only for people which prefer mobile phone displays... I will keep this in mind and try to fix it when I find a solution. Cacycle 02:11, 16 December 2006 (UTC)

Who said anything about mobile phones? -Will Pittenger 02:23, 16 December 2006 (UTC)

Storage

History for summary, find, and replace fields from drop-down menus (history is not lost between browser sessions and is accessible from different windows)

Where is it stored then? A cookie? — Omegatron 14:55, 14 December 2006 (UTC)

Yes, exactly. Their names start with wikEd.... The button cookies are only there when the buttons were pushed. Cacycle 17:44, 14 December 2006 (UTC)

Ok. So it's not stored in a publically-viewable place on my account or anything like that, and it won't migrate from computer to computer. — Omegatron 18:00, 14 December 2006 (UTC)

Exactly. There is also the button to erase those cookies. Cacycle 01:40, 15 December 2006 (UTC)

Wow!

Wow! That's all I can say, as a first impression. I'm awed. And to think I was just looking for a way to search in the edit box!

Firefox 2.0 allows you to search in the edit box already, and it responds a lot faster, too. — Omegatron 15:08, 15 December 2006 (UTC)

I will change wikEd soon to make the searches a lot faster :-) Cacycle 23:50, 15 December 2006 (UTC)

Nearly all buttons are much faster now in version 0.9.13, please press Shift-Reload to update. Cacycle 05:24, 17 December 2006 (UTC)

Live Preview needs serious attention

We really need a Live Preview fix. If you can't get Pilaf to respond, I have to suggest that you look into alternatives. They may not work any better, but even so, I would consider testing them somewhere. As is, Live Preview does not handle correctly templates (as noted before), conditional statements, magic words like __TOC__ (in fact, the TOC is never shown making getting to the end of a long article hard), and definition lists. -Will Pittenger 05:27, 15 December 2006 (UTC)

Those suggestions do not sound like a quick fix, they would be quite difficult (if not impossible) to implement. Why don't you give it a try... Cacycle 00:03, 16 December 2006 (UTC)

Sure. Provide me a C#.NET or C++/MFC development evironment, and I might know what I would be talking about. Beisdes, I never called it a "quick fix." -Will Pittenger 00:16, 16 December 2006 (UTC)

Seriously, JavaScript is extremely simple and you just have to change existing and running code. Here are the only two reference sites I use: http://developer.mozilla.org/ and http://www.w3schools.com/jsref/default.asp. Simply save a Wikipedia edit page to your computer and change the LivePreview call to your local copy for testing. Templates are obviously not possible for an offline script, but the TOC would be relatively easy to implement. Cacycle 01:30, 16 December 2006 (UTC)

First, templates are one reason for the script to go online. (However, a switch should possibly be added to avoid the load time.) My main concern is that I have to wait for an entire page to load. I'll put up with the template load time. Second, I mainly just felt you should keep your ears open to possible alternatives. -Will Pittenger 02:19, 16 December 2006 (UTC)

There is also the User:Pilaf/livepreview.js (User:Pilaf/Live Preview) successor User:Pilaf/InstaView (User:Pilaf/instaview.js). Its developer version User:Pilaf/InstaView/Devel has several fixes. Cacycle 01:56, 17 December 2006 (UTC)

Replace bug.

I was editing my monobook.css file. I had accidently used "//" comments in place of "/* */" comments. Find and replace refused to replace "//</nowiki> </pre>" with "/*</nowiki></pre> */". I double checked and Regular Expressions were off. -Will Pittenger 06:48, 15 December 2006 (UTC)

Fixed (version 0.9.12c). Thanks, Cacycle 02:07, 16 December 2006 (UTC)

I can't confirm that with 0.9.13a. Sorry. (In this retest, I was using this page and searching backwards.) Will (Talk - contribs) 22:37, 18 December 2006 (UTC)

Works fine for me though!? Cacycle 05:24, 19 December 2006 (UTC)

Bugs

I just started using this yesterday, so I probably just don't know how to use it. But:

• I can't get the dash/unit fixers or the find and replace to work. Test - test 200uF Ω ohm.
• Also this looks like a syntax highlighting bug. If light green shows an image tag, the light green should extend all the way to shears]].]]

  This is a known issue. See Syntax highlighter can't count. -Will Pittenger 00:20, 16 December 2006 (UTC)

  Fixed in 0.9.13b. Cacycle 05:25, 19 December 2006 (UTC)

  Excellent. — Omegatron 22:34, 19 December 2006 (UTC)

• (And why is the word "green" that I just typed displayed with a green background? Maybe that's meant to happen inside HTML tags?)

  Because it looks funny ;-) It is meant for html and css color values, especially for hex color values. Cacycle 21:33, 15 December 2006 (UTC)

  Ok. Maybe it should be limited to inside HTML tags? — Omegatron 23:00, 15 December 2006 (UTC)

  Do be aware that there is a quick with colors as shown here. (See the source of this post.) -Will Pittenger 00:23, 16 December 2006 (UTC)

  Text color for colored backgrounds fixed in 0.9.13b. Cacycle 05:18, 19 December 2006 (UTC)

  "A quick with colors"? What does that mean? — Omegatron 22:34, 19 December 2006 (UTC)

• Is the edit box an iframe? Linkification is supposed to ignore them, but it's still auto-linking things in the textarea, and this seems to be a case of the linkificated link getting converted into wikicode. But I can't get it to do that consistently. Something about pasting marked-up code into the box causes the linkification links to be converted to wikicode? — Omegatron 15:25, 15 December 2006 (UTC)

  I am not using Linkification, but everything you paste into the wikEd iframe stays there as it is until you press the Wikify or the Textify button. If you paste a linkified link it will probably pasted as a link and stay a link. Cacycle 21:33, 15 December 2006 (UTC)

  I'm not pasting the links; it's creating links around URLs inside the "textarea", which I guess are converted into wikitext when I do something or other. They are all tagged with class="linkification-ext", which could prevent them from being converted to wikitext. I don't know why it's linkifying things if it excludes iframes, though. — Omegatron 23:00, 15 December 2006 (UTC)

  To me it looks like something else is involved - or did you use the wikify button? Without wikifying only the unformatted visible text would be sent back and any links generated by Linkification would get lost. Also, please could you point me to a detailed Linkification feature or help page. Thanks, Cacycle 00:16, 16 December 2006 (UTC)button

  The edit before this one shows what happens when I click the Unicode fixer with Linkification on. The dash fixer and unit fixers did nothing. — Omegatron 15:35, 15 December 2006 (UTC)

  I'll check the dashes and units fixer later. Cacycle 21:33, 15 December 2006 (UTC)

  I have fixed the dash fixer and completely rewritten the units fixer, you might want to check that one out... (User:Cacycle/wikEd.js, search for function WikEdFixUnits). Is something wrong with the Unicode fixer? Cacycle 06:27, 16 December 2006 (UTC)

  Here is another rewritten unit fixer you might want to look at for ideas: User:Gerbrant/edit/autoReplace/default.js. We should probably be inserting non-breaking spaces between the numbers and units, but there's no way to do that without ugly HTML entities...  :-\ — Omegatron 22:34, 19 December 2006 (UTC)

I have now tested Linkification. It linkifies only on page load. These simple tips will help:

• Press the [T]extify button to remove the Linkification links (no selection defaults to the whole text)
• Do not use the [W]ikify button on linkificated links, e.g. by selecting the text to be wikified (no selection defaults to the whole text)

I will add a linkification killer to one of the next updates plus a wikEd internal linkification. Cacycle 14:48, 17 December 2006 (UTC)

Linkification has an exclude feature already. I can't figure out why it's not working. Look under Options → Advanced. If this text box is actually an iframe, shouldn't it be excluded? — Omegatron 22:34, 19 December 2006 (UTC)

Looks like a Linkification bug to me. Linkification seems to be closed source so there is no way to check. Cacycle 22:51, 19 December 2006 (UTC)

Please respond to User talk:Pilaf/InstaView#InstaView doesn't work in Firefox 1.5.0.8

I doubt that Pilaf will. Will (Talk - contribs) 07:35, 17 December 2006 (UTC)

I added User talk:Pilaf/InstaView#InstaView doesn't show edit changes. If you could tell him that the problem exists, I would appreciate it. Will (Talk - contribs) 00:00, 19 December 2006 (UTC)

InstaView compatiblity problem

The wikEd button to close the Live Preview window doesn't work with InstaView. Will (Talk - contribs) 03:23, 18 December 2006 (UTC)

What a surprise... :-) (actually it is in work) Cacycle 01:31, 19 December 2006 (UTC)

Possible syntax hightlighting bug

Please examine this version of an article I was wikifying. The syntax highlighting is badly messed up. Please note that some of the section headers are ignored as are some bullet points. Will (Talk - contribs) 23:56, 18 December 2006 (UTC)

I don't see any non-highlighted lists on that page, only those headings. Cacycle 01:33, 19 December 2006 (UTC)

Headings are fixed in 0.9.13b. Cacycle 05:18, 19 December 2006 (UTC)

Fix confirmed. Thanks. BTW: I was also unable to reproduce the heading problem. But I know what I saw. Oh well. As long it doesn't return.

What caused the problem? I may not understand JS, but I do have a C#.NET and C++/MFC background. Will (Talk - contribs) 06:24, 20 December 2006 (UTC)

It was just a regExp problem, with look-ahead it now works as expected. Cacycle 17:22, 20 December 2006 (UTC)

tab quirk

With wikEd, you can now tab from the wikEd box to the subject line. However, you can't shift-tab back. I surmise that sends the focus to the now hidden plain text box. Will (Talk - contribs) 06:26, 20 December 2006 (UTC)

Will check that one. Cacycle 17:22, 20 December 2006 (UTC)

Any news on this problem? Will (Talk - contribs) 08:12, 28 December 2006 (UTC)

Saving/Previewing pasted formatted text

Commonly I have been able to paste formatted text into wikEd and have the formatting survive. However, it has become clear that it is not just a quirk. Unless the user wants the formatting to stay, he or she must click the [T] button before saving or previewing the page. Once that happens, wikEd takes any pasted formatting and transforms it into WikiCode. It is as though the user pressed [W]. Will (Talk - contribs) 06:31, 20 December 2006 (UTC)

No, the buttons work as described on the help page. [W] is to convert pasted html formatting to wikicode, [T] is for stripping any html formatting (followed by syntax highlighting). Cacycle 17:22, 20 December 2006 (UTC)

You misunderstood me. I never said the buttons did the wrong thing (other than as I previously noted, they shouldn't change the cursor position or the selection.

Rather, follow the directions below this box.

WP:UBX Testing.

1. Copy the entire text in the box above into your clipboard.
2. Edit a page.
3. Paste the clipboard contents (copied from the box above) into the page you are editing.
4. Save the page.

On my machine, that test results in the contents of this second box.

[../../wiki/WP:BOX WP:BOX] '''Test'''''ing''.

Will (Talk - contribs) 08:04, 21 December 2006 (UTC)

Fixed in next version (0.9.14a), thanks, Cacycle 21:03, 22 December 2006 (UTC)

Source button does not work as expected

I expected the view source button to show me the source of the text -- without actually changing that text. What I thought it would do was similar to the layout mode buttons in Word. You know how they activate the various views: normal, web, outline, and layout. None change the document. They meerly display it differently. However, use of the Source button can't be undone by clicking it again. Will (Talk - contribs) 06:34, 20 December 2006 (UTC)

Don't mess around with developer-only buttons ;-) This button simply shows the html code used for highlighting and from pasting stuff and has no other use than to serve the developer... Cacycle 17:22, 20 December 2006 (UTC)

WikiLink Options

Love the tool - works great. Question: is it possible to modify the default action of WikiLink from [[xxx]] to something like [[namespace:xxx|xxx]]? I looked at the code and could easily change the respective regex string for the wikilink variable, but then I'd have to run & maintain a separate local copy. Besides, I'm not sure I'd want to hardwire a namespace & | symbol. It would be much easier if it could be configured on the fly for different tasks. Chuck Dent 20:38, 22 December 2006 (UTC)

Thanks :-) Do I understand you correctly that you want a new Wiki link button for the Wikipedia namespace. I will think about a user interface for custom buttons and functions. Give me some time... Cacycle 21:09, 22 December 2006 (UTC)

Rather than a adding new wikilink button, perhaps you could add a config option so that the existing wikilink button automatically inserted a specified namespace, | symbol, and target name along with the pre-existing coupled double brackets.

In fact, it would be very cool if one could choose a namespace on the fly, then revert to the standard setting, or set another namespace for other operations. That way, if someone was working on, say, User:text or User_talk:text, then moved over to Image:image and Image_talk:text, etc., they wouldn't have to keep typing namespace: then the | symbol and then some short-text if they didn't want the default namespace:text full-name displayed.

This might be very easy to do. If you had a small (popup?) input box in which to type a chosen namespace, then your regex string would merely insert that variable right after the two /[/[ and trigger an insert of :| and a repeat of the object text thereafter. If nothing was chosen (or reverted back to default), the variable would be '' and the existing regex would work exactly as it does right now. Waddya think?

Chuck Dent 01:20, 23 December 2006 (UTC)

Please check User:Cacycle/wikEd#Custom_buttons for the new interface to custom edit buttons and functions. Cacycle 03:25, 4 January 2007 (UTC)

Translation and suggestion

It’s a great tool! I made the portuguese translation but still missing one thing: one page similar to User:Cacycle/RegExTypoFix.js and based on pt:Wikipedia:AutoWikiBrowser/Typos (Wikipedia:AutoWikiBrowser/Typos portuguese version). Can you tell me how you did that?

Thanks. I have made RegExTypoFix.js by hand using regexp search and replaces. I was thinking about adding an automatic conversion button to wikEd. I will also add support for custom functions and buttons, so better wait a few weeks until that's done, I will notify you. Cacycle 18:12, 28 December 2006 (UTC)

One suggestion: the images used on buttons are too heavy. For example, the button has 3,630 bytes. Converted to PNG-8, using 3 colors palette (in this case) and removing some metadata, this button has 159 bytes (without loosing transparency, quality or colors). If you want I can make this conversion and upload all images. Merry Christmas. Mosca2 11:17, 24 December 2006 (UTC)

Thanks for your offer, your help would be greatly appreciated. Just upload them over the old images. Cacycle 18:12, 28 December 2006 (UTC)

Nice. I will be waiting for the next version. It seems I didn't mess anything with the new images. Could you please "transwiki" to commons the following images? Image:WikEdFormButt.png, Image:WikEdF&RButt.png ,Image:WikEdFixButt.png, Image:WikEdCnt.png, Image:WikEdPrvChg.png. Only admins can do that.

Done, Cacycle 03:26, 4 January 2007 (UTC)

Another suggestion: we could have something similar to this example. Customized MediaWiki:Edittools (drop-down menu and without warnings) on the top. The idea is cleaning the bottom of the edit page for fast preview/changes box and best positioning of the MediaWiki:Edittools. I only found this User:Quiddity/monobook.css (removes the warning messages). Mosca2 12:08, 29 December 2006 (UTC)

Speeding things up when button is clicked automatically

Any chance you could prevent your code from loading (or at least running) when an AutoClick parameter was passed? I use popups to revert, several tools to add warnings or DB tags, and George Money's Auto Welcome tool. Each clicks the the submit button for me. Waiting for unneeded code to load slows me down. Will (Talk - contribs) 08:15, 28 December 2006 (UTC)

Theoretically, the code is loaded once and then hold in memory, that's the reason why you have to push Shift-Reload to upload. Cacycle 18:15, 28 December 2006 (UTC)

Installation in Mozilla 1.7

Hi, I installed it, and nothing happened, even when I went to an edit page, and did shift-reload, or ctrl-shift-r. Then I used Firefox, and it worked fine. What am I doing wrong? js is enabled. Martin^phi _{(Talk Ψ Contribs)} 06:28, 31 December 2006 (UTC)

Please check the JavaScript console under Tools for an error message. Thanks, Cacycle 13:54, 1 January 2007 (UTC)

wikEd broken in 0.9.16 Beta

Somehow wikEd is no longer loading text into the RTF box. It appears to have started with 0.9.16 Beta. On pages with known contents, all I see is a transparent box. (It has the light blue background of the surrounding page.) Please fix this ASAP. We can't edit known pages like this.

In fact, I can't edit at all without disabling wikEd. When I left it enabled, it acted as though I typed nothing. It looked like I had a post ready to go. Not really. Will (Talk - contribs) 19:22, 4 January 2007 (UTC)

I had the same experience. Thanks for all your hard work! --Flex (talk|contribs) 20:46, 4 January 2007 (UTC)

Does it now work with the current version 0.9.16a? Cacycle 23:48, 4 January 2007 (UTC)

It does on my one computer. I'll try the other tomorrow. --Flex (talk|contribs) 00:09, 5 January 2007 (UTC)

Yes. It is working both here and at Wikia. Thanks for taking it up so quickly. What happened? Will (Talk - contribs) 00:12, 5 January 2007 (UTC)

See User_talk:Cacycle#Problem_with_today.27s_version_.282007.2C_Jan_4th, the original bug report. Cacycle 01:20, 5 January 2007 (UTC)

That does not supply a cause. Will (Talk - contribs) 08:37, 5 January 2007 (UTC)

Will, why should he spend time giving us users a detailed explanation? Without the source code, would a full bug report even make sense? Cacycle, the new version works on both of my computers. Thanks and keep up the good work! --Flex (talk|contribs) 14:14, 5 January 2007 (UTC)

Will: try to compare before and after bugfix if you are that interested in it. The error message "wikEdButtonsCustom1.style has no properties" means that wikEdButtonsCustom1.style was accessed but wasn't defined earlier - just a stupid bug :-) Cacycle 01:34, 7 January 2007 (UTC)

Secedit Compatability

Hi,

Thanks for a great tool. It would be nice if it wysywig'd boxes made by User:Supadawg/secedit.js though. --cfp 22:03, 6 January 2007 (UTC)

Thanks. Your suggestion would be extremely difficult to implement and will most certainly not happen soon. Here is a short description how developers can make their scripts compatible with wikEd: Make scripts compatible with wikEd. Cacycle 03:15, 7 January 2007 (UTC)

Simple wikEd question (moved from User page)

[now following your request to use this page for wikEd discussion:]

Indeed, for-each-in has been introduced in Mozilla 1.5. I have changed all for-each-in into for-in loops in the latest version (0.9.17), shift-reload to update. Thanks for helping to improve the progam, Cacycle 01:20, 7 January 2007 (UTC)

A definite improvement today! The logo appears at the top of the page as intended, but thereafter it's sl-o-o-w, & doesn't load properly when editing. However, if I stop the loading I do see your editing buttons (under the textarea), but the text itself then disappears (I see that another user has reported similar behaviour).

These are the errors reported on the JS console:

Error: setting a property that has only a getter

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

Error: uncaught exception: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIDOMNSHTMLDocument.designMode]" nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: "JS frame :: <unknown filename> :: onload :: line 0" data: no]

I suspect an infinite loop somewhere -- but that's just a guess! I think we're nearly there now ... Ndsg 17:00, 7 January 2007 (UTC)

Ref tag button?

I'm up & running now, & very pleased with the look & feel of wikEd. Just one question: is there a Ref button hidden somewhere? If not, is there a simple way to add one? Ndsg 15:34, 8 January 2007 (UTC)

I have already implemented it yesterday, it will be in the next version. Good idea, Cacycle 14:42, 9 January 2007 (UTC)

Thanks for the prompt action!

Added in 0.9.19. Cacycle 01:06, 10 January 2007 (UTC)

In general terms, are buttons user-customizable at all? Not that I want to make wikEd crash ... Ndsg 16:21, 9 January 2007 (UTC)

Check User:Cacycle/wikEd#Custom_buttons. You could also overwrite existing buttons in the same way. Cacycle 22:53, 9 January 2007 (UTC)

Thanks both for the new buttons & the link to Custom buttons. wikEd is a pleasure to use. Ndsg 11:18, 11 January 2007 (UTC)

Another query. Is there a button for Div id=""? This is a handy counterpart to Ref in many cases. If space is short on the toolbar, maybe it could replace the References/ button, since one document may contain several Divs, but at most one References/. Ndsg 11:23, 13 January 2007 (UTC)

New Section broken

0.9.18 appears unable to save section headers in new sections. This happens when I use the + tab. When you click Save Page, it clears the field. Will (Talk - contribs) 03:45, 9 January 2007 (UTC)

Lately, it is worse. I now have to disable wikEd to get any changes to register. Otherwise, my changes are simply ignored. Furthermore, even when the summary contains a section comment (that gets turned into a link to the section), the rest of the summary is deleted by wikEd. I am being forced to consider disabling wikEd from the JS page as disabling it from here doesn't prevent the subject from being cleared. Will (Talk - contribs) 20:32, 9 January 2007 (UTC)

I clicked the + tab, added text to the edit field and to the summary, and saved it. Everything worked as expected for me. It might be an incompatibility with another script. Cacycle 22:48, 9 January 2007 (UTC)

It did not happen until I upgraded to 0.9.18. There were no other changes. Same problem at Wookipedia. I have fewer scripts installed there. That should help narrow down the possibilities. You might go through those and see if you see anything obvious.

I now have 0.9.19. It has similar problems. I edited a section below only to find that it refused to do anything other than clear the summary field as described above. It did not change the page until I entered my summary several times. Then the summary and edit took. Will (Talk - contribs) 05:07, 10 January 2007 (UTC)

Update: When I saved the above post, the field reset when I clicked Enter/Return with the focus on the summary field. When I clicked Save Page, it worked normally. This suggests that the keystroke was activating the Summary field's X button (which does clear the summary field). With 0.9.18, pressing Enter/Return may have activated both buttons. Will (Talk - contribs) 05:11, 10 January 2007 (UTC)

Fixed by trapping return in 0.9.19a. Thanks, Cacycle 13:59, 10 January 2007 (UTC)

Now running 0.9.19a. However, Enter/Return now does nothing. Will (Talk - contribs) 22:45, 10 January 2007 (UTC)

Do you really want that an accidental return submits a page? I don't like that idea... Cacycle 23:35, 10 January 2007 (UTC)

Accidental? If the RTF field has the focus, it should always keep the Enter/Return key messages. It's only if you move the focus away from the RTF key that the Save Page button should be pressed. I think it should at least be an option.

BTW: The X button is still clicked if I move the focus to the Minor Edit button and press Enter/Return there. Will (Talk - contribs) 03:38, 11 January 2007 (UTC)

Symbol insertion problem

I keep forgeting to ask this, but it is there. I don't know if this is a problem with Firefox or wikEd.

1. While editing a page, start with a blank line
2. Add 2 words to that line, but no punctuation.
3. Click any symbol link.

wikEd will add the symbol to the wrong side of the second word. Will (Talk - contribs) 03:49, 9 January 2007 (UTC)

Fixed in 0.9.19. Cacycle 01:06, 10 January 2007 (UTC)

Missing wikEd toolbars

0.9.18 is missing all but the right most toolbar. What is going on? Will (Talk - contribs) 03:50, 9 January 2007 (UTC)

You have temporarily disabled wikEd, re-click the lower left button. Cacycle 14:42, 9 January 2007 (UTC)

Ok. I disabled wikEd to test the subject bug. I didn't know that wikEd now remembers its enable state. I saw the enable button was up, but didn't think about it. Must not have realized what I was looking at. —Preceding unsigned comment added by Will Pittenger (talk • contribs)

"Enter" to commit edits

Thanks again for this tool. My only gripe after, er, 30 seconds of usage: Hitting "enter" in the edit summary box or when the "minor edit" checkbox is selected does not commit the edit; I have to reach for the mouse to click "save" manually. Can this be remedied? Sandstein 21:34, 11 January 2007 (UTC)

Ok, if that makes you and Will happy :-) Cacycle 23:01, 11 January 2007 (UTC)

Thanks! Sandstein 05:39, 12 January 2007 (UTC)

If you want, make it an option. Will (Talk - contribs) 00:06, 12 January 2007 (UTC)

Hey, wait a minute! If this means what it sounds like (I haven't tried it out yet), it could be a step backwards. Surely it's safer for <Enter> to default to Preview rather than Save. Just going to try now Ndsg 11:50, 12 January 2007 (UTC)

Maybe an option is best, but in vanilla Wikipedia (or at least in whatever other edit script I was recently using) Enter defaults to save, which has served me just fine for some 8'000 edits now. Sandstein 12:27, 12 January 2007 (UTC)

Fixed in 0.9.20, press SHIFT-Reload to update. Has now the same behaviour as in standard mode. Cacycle 04:32, 13 January 2007 (UTC)

I now have 0.9.20, but it is clear you don't use this much. When I start typing in the subject/summary box, I see a history list (probably provided by Firefox) that provides previous entries. Your new code is preventing me from selecting an entry.

Before 0.9.18, when that list was open, pressing Enter/Return caused the currently highlighted entry to move into the main box. Now, wikEd saves the page with what was there. I have to prefer the pre-0.9.18 behaviour. Why did 0.9.18 change things around? Don't fix what's not broken. Will (Talk - contribs) 05:56, 13 January 2007 (UTC)

Will, stay cool... Cacycle does this in his spare time, you're not his paying client. That aside, I can report the same bug: we should still be able to select an item from the dropdown list without commiting the edit. More seriously, with 0.9.20, wikEd has become so slow as to be unusable. It takes half a second (and 80% CPU on my 3 GHZ workstation) to type a single character. What might be the problem here? Sandstein 06:53, 13 January 2007 (UTC)

Sorry. I had no intention of saying that Cacycle never uses wikEd. I meant to say that he never uses wikEd in the manner causing us problem: pressing Enter/Return with the focus in the summary. I figure he uses the mouse more. Will (Talk - contribs) 23:54, 16 January 2007 (UTC)

Actually I cannot reproduce the enter/submit problems with the latest Firefox and Seamonkey, so I guess it is a now fixed Mozilla bug. I have added a few lines to fix it for older browsers, please could you update to the latest wikEd 0.9.20a (Shift-Reload) and report back. Sandstein: The freezing problem might be unrelated to wikEd. Do you still experience it or is it gone. Thanks, Cacycle 15:58, 13 January 2007 (UTC)

Now with 0.920b and working on another system, there's no more freezing. I guess it was something with my Java installation, then. Sandstein 07:48, 14 January 2007 (UTC)

I just came to report the same problem. I did the shift-reload and I'm 99.9% certain I have the latest version of Firefox. However, hitting enter still results in committing an edit rather than saving. I, too, prefer the pre-0.9.18 behavior, although, if possible, it might be better to make the save on enter bit an option. -- tariqabjotu 01:08, 14 January 2007 (UTC)

Tariqabjotu: Are you using the latest wikEd version 0.9.20a? If not, please could you update to the latest wikEd (Shift-Reload) and report back if the problem persists (selecting from the summary dropdown list with enter submits the page erroneously). Thanks, Cacycle 01:29, 14 January 2007 (UTC)

Yes, the problem persists (that's supposed to say + ref). -- tariqabjotu 01:37, 14 January 2007 (UTC)

Oh, I just realized that you are talking about the Firefox form popup, not about the wikEd summary history dropdown :-S. I will turn off enter-submit until I find a solution. Shift-Reload to 0.9.20b to updfate (in a few minutes). Cacycle 01:43, 14 January 2007 (UTC)

Alright; thanks. -- tariqabjotu 01:56, 14 January 2007 (UTC)

Hooray, I have figured out a way to fix this. Update by Shift-Reload to 0.9.20c. Cacycle 14:11, 16 January 2007 (UTC)

0.9.20c is disabled in edit pages (the icon is missing from the top-right), but enabled in My Watchlist. This is screwy. I don't understand it. Will (Talk - contribs) 23:54, 16 January 2007 (UTC)

Check for a JavaScript error. Cacycle 00:41, 20 January 2007 (UTC)

I should have thought of that earlier. Shows you why I don't code JS. I should stick to code that has no need of a browser. The errors appear to be from two other scripts. It looks like one or both of them were updated at the same time that wikEd 0.9.20c came out. Will (Talk - contribs) 03:17, 20 January 2007 (UTC)

Confirmed. Thanks for the tip. It seems one of the scripts that errored out had not been working for a while. The other appears to have been deleted. It would be helpful if someone deletes a script that they put something in its place telling those with it installed to remove it.

Again, sorry to bother you. I should have thought of checking that console before. Will (Talk - contribs) 03:31, 20 January 2007 (UTC)

For a while, Enter/Return pressed the Save button. Now I seem to be getting preview. Is there a way to control this via a parameter? Will (Talk - contribs) 02:51, 24 January 2007 (UTC)

Can the find function be independent?

I just tried this and I love the find function but am not so enthusiastic about the syntax highlighting. Are these necessarily bundled or can the find function be installed independently? Thanks. Opabinia regalis 03:45, 12 January 2007 (UTC)

Just click the toggle syntax highlighting button on the right to turn syntax highlighting off. The setting is saved, so you'll never see it again until you hit that button again. Cacycle 03:54, 12 January 2007 (UTC)

Unfortunately you cannot have the search functions without the whole clutter :-) Cacycle 03:57, 12 January 2007 (UTC)

Thanks, I missed that :) I'll give it a shot without all the colors. Opabinia regalis 05:28, 12 January 2007 (UTC)

<ref> tag highlighting is funky

Sometimes–quite often in fact–a <ref> in the format <ref/> will end up highlighting the following sentence(s) until wikEd runs into a closing </ref>. Similarly, the <ref> and <nowiki> tags tend to interfere with each other. Try looking at this section in the editor.

Fixed in 0.9.20, press SHIFT-Reload to update. Cacycle 04:32, 13 January 2007 (UTC)

thanks! makes editing Verbascum thapsus much easier! Circeus 18:25, 13 January 2007 (UTC)

Oh, and does a, y'know, explanation of the highlighting exists? Circeus 20:01, 12 January 2007 (UTC)

What exactly do you mean by that. Cacycle 04:32, 13 January 2007 (UTC)

I think Circeus wants either a list of color codes or instructions on creating his own scheme. Supposedly the later is similar to the instructions for creating international versions, but no details are provided that I have seen. It would be nice to know if some tags that are given the deprecated colors can be given something else. Will (Talk - contribs) 05:48, 13 January 2007 (UTC)

Pretty much that. You see all these colors, but there is no quick reference to make sure you figured out what they are highlighting correctly.Circeus 18:25, 13 January 2007 (UTC)

Ok, here it goes:

• Block elements (tables, headings, lists, pre, div...): grey background
  • Wikipedia headings (See also, References, External links): light bluish background
• Html and wikicode itself: blue text
• Bold, italic, subscript, superscript: formatted as such
• Comments: yellow
• Images: green
• Links:
  • Link target: red
  • Link text: black bold
  • Non-article name space links: lavender background
• Nowiki tags: grey background, no other highlighting between tags
• Unsupported and deprecated html: pink/white striped background
• Html and css colors and color codes: respectively colored background

See the first example under for customizing the highlighting colors, it's done by CSS. Feel free to submit better color schemes. Hope that helps, Cacycle 19:08, 13 January 2007 (UTC)

The customization link only provides what you see below for theme packs. Perhaps you should expand that. Will (Talk - contribs) 05:49, 14 January 2007 (UTC)

If you don't like the syntax highlighting colors or want to use other buttons - no problem, you could make your own theme pack (similar to the wikEd translation files by changing the wikEdMainCSS and wikEdFrameCSS style sheet definitions. You could also suggest improved colors on the talk page of this article so that they might be incorporated into the official release.

Div button?

(Copied from above, in case you missed it:)

Is there a button for <div id="">? This is a handy counterpart to <ref name=""> in many cases. If space is short on the toolbar, maybe it could replace the <references/> button, since one document may contain several <div>s, but usually just one <references/>. Ndsg 12:10, 15 January 2007 (UTC)

No, we have to save space ;-) But you can make yoyr own, see User:Cacycle/wikEd#Customization. Cacycle 04:06, 16 January 2007 (UTC)

You can't add buttons if you don't know how to code JS. I don't or I would create a <code> button.

BTW: Could you add a gallery of custom buttons and theme packs? Will (Talk - contribs) 06:35, 16 January 2007 (UTC)

Couldn't <div> be generated by double-clicking on the <ref> button? Ndsg | Talk 10:38, 17 January 2007 (UTC)

I have made the top button in the example under custom button User:Cacycle/wikEd#Customization into a <div> inserting button. Cacycle 02:54, 21 January 2007 (UTC)

can't remove original bar

Despite activating the option, I can't seem to be able to move the edit bar above the edit section... And yes I have repeatedly cleared up the cache.Circeus 18:12, 15 January 2007 (UTC)

Try to move that setting up, before the wikEd installation block. Cacycle 21:45, 15 January 2007 (UTC)

Did you try turning the bar off from Preferences? Will (Talk - contribs) 06:36, 16 January 2007 (UTC)

There is now a standard non-wikEd toolbar toggle button (update to 0.9.21). The old custom setting is now without effect. Cacycle 02:56, 21 January 2007 (UTC)

Since I myself hid the MediaWiki toolbar from preferences, how do I hide the button to hide the toolbar that is hidden? Will (Talk - contribs) 03:07, 21 January 2007 (UTC)

References button needs to insert header too.

I like the new references button. However, I think the button that inserts the <references/> tag should add the References header code too. Can that change be made? Could I make it by changing something along the lines of a translation change? Will (Talk - contribs) 06:38, 16 January 2007 (UTC)

What do you mean by "References header code". Try doubleclicking the button. Cacycle 14:13, 16 January 2007 (UTC)

He means == References ==, which, for the record, I see as a very bad idea, if only because there is deep disagreement across the community about the proper name for this header.Circeus 15:50, 16 January 2007 (UTC)

I see. I think i will add it to the doubleclick text. Circeus: what are the alternatives to it. Cacycle 18:22, 16 January 2007 (UTC)

Circeus is correct as to what I was talking about. However, I was thinking of making it an option. The default behaviour would be to emulate what we have now (no header). As an option, it could be implemented for both single and double clicking. One way to control the option would be to require the CTRL key be down when you click the button.

BTW: To address Circeus's concern about the header text, you might make that a variable that can be quickly changed. You will need to make some special accomadations here anyway. "References" is one of several headers that they syntax highlighter treats special. Will (Talk - contribs) 23:49, 16 January 2007 (UTC)

Added to 0.9.20d (please update): "== References ==" added to doubleclick references button, text can be changed ('wikEdReferencesSection'). Cacycle 02:02, 17 January 2007 (UTC)

Creating/copying tables

What's the simplest way of creating a table using wikEd?

I've tried copying a table created in Word, but so far without success (whether I use Word or HTML format). Ndsg | Talk 17:38, 16 January 2007 (UTC)

Use the table button with a selection, I just noticed that the empty table insertion is broken if nothing is selected. Will fix that later today. After pasting a word table you have to push the [W] button to convert it into wikicode. Cacycle 18:21, 16 January 2007 (UTC)

Fixed in 0.9.20d, please update. Cacycle 02:02, 17 January 2007 (UTC)

By "Word table", do you mean a Word-format table or a table converted to HTML by Word? I pasted a Word-format table, but it lost all its formatting. I've tried various other approaches too—but nothing seems to work. Ndsg | Talk 22:23, 16 January 2007 (UTC)

This is a table directly copy & pasted from Word after pressing the [W] button:

1	2
3	4

Cacycle 00:10, 17 January 2007 (UTC)

Thanks. It seems that this works with W2K but not W97. But the table is not in WikiTable format, is it?

Is it better to start from scratch, clicking on the Table button in wikEd? Ndsg | Talk 10:30, 17 January 2007 (UTC)

I'll check for the W97 compatibility. After the table is converted to wikicode it is wikicode. Feel free to remove the valign="top" clutter. You caould also paste html table code and press the [<>] fix html to wikicode button. Cacycle 01:34, 18 January 2007 (UTC)

Thanks for explaining this. BTW you haven't responded to my point about double-clicking on the <ref> button to get <div>. At the moment there's no double-click assigned to that button. NigelG (or Ndsg) | Talk 19:02, 18 January 2007 (UTC)

removing buttons

How can I get just the syntax highlighting, and none of the buttons? How can I remove some of the buttons or some of the button panels? -Pgan002 12:05, 18 January 2007 (UTC)

That's not yet possible. If it is really important for you I could implement a user setting for it. Cacycle 15:07, 18 January 2007 (UTC)

Well, I find syntax highlighting very useful, but at the expense of greatly slowing down load and response times on my computer. But is loading and rendering the buttons what is slowing it down? Another inconvenience is the greatly reduced editing space. I don't know about other users, but I haven't used the buttons yet. Is it not possible to put the buttons in the left column? Or after the Summary box and Save dialog, together with the default wiki markup links? That would be more consistent and more convenient, since the save panel is used much more often. Some of those editing functions are suprefluous, as they are already implemented by any browser that supports Javascript: Undo, Redo, Search, Replace, the search modes, Jump to top/bottom, Jump to previously changed position (using Undo and Redo). And the Preview and Show changes buttons are already provided. The Full screen function is very helpful. Lastly, the syntax highlighting and preview should ideally highlight as you type, without having to be updated. I guess they would have to be browser extensions. (I know you are using someone else's code for the preview.) -Pgan002 23:48, 18 January 2007 (UTC)

Thanks for your comments. In order to display colors wiked has to rely on the browser's spartanic editing interface for editable html frames. This causes many workarounds and trickeries to get what you see here. I am aware of the mentioned shortcomings, but I think the program is pretty much at the limit of what's possible with browser-independent JavaScript. I am also aware that wikEd is best viewed on larger displays where all button bars are in one row and on faster computers and connections. You could try to remove the 'RegExTypoFix' lines from the installation code to speed up the loading of the first Wikipedia page.

Indeed, there are some buttons that I do not use often, especially the formatting buttons, they are more aimed at wikicode beginners. But there are powerful functions that your browser does not provide, e.g. type-ahead find, regular expression search and replace, fixing buttons, wikifying pasted text (you can even copy text from an article without opening its edit page). And the local Changes button gives you a better overview over changes than the server-site preview. The undo/redo buttons are also handy because there is no right-click undo/redo for the edit area.

Cacycle 05:10, 19 January 2007 (UTC)

Here are examples of how live syntax highlighting and preview should work, both implemented in Javascript: CodePress and Humanized blog entry box with preview (at the bottom of the page) It is really live: you don't have to click any buttons to see the output. -Pgan002 20:11, 19 January 2007 (UTC)

True, regular expression search-replace is probably useful -- I had not realized that you had implemented it. It should really be implemented in the browser. That's something I suggest to Mozilla. -Pgan002 20:11, 19 January 2007 (UTC)

Type-ahead search is implemented in my browser, Forefox2.0, thought I know you want to provide it for all browsers. Firefox also has right-click undo/redo, and I'm sure any modern browser has them through the Edit menu and the universal Control+Z/Control+Shift+Z accels. Functions like Bold, Italic, Underline, Strike-through, Nowiki, Insert image, Insert table, Subscript, Superscript, Redirect are implemented using the default buttons above the edit area. All these make the interface a bit complex, and cluttered, probably slow down loading, take up memory and probably complicate the code.

As for the others, is it possible to put them above the edit area, next to or above the default buttons? That way they would not interfere with saving. Also, any chance I can get the source code? -Pgan002 20:11, 19 January 2007 (UTC)

Thanks for those two links, the CodePress editor looks interesting. The problem with live syntax highlighting is that every such change to the edit frame either erases or messes up the undo history. In order to get live syntax highlighting the whole undo/redo system and the whole editing logic of the RichText interface had to be simulated from scratch in JavaScript. This is possible, but would need quite some time to code, would further bloat the program (currently ~220 kB without LivePreview, Diff, and RegExpTypoFixer), and would render the browser's undo/redo menu entries useless.

As for a minimalistic interface: I will think about it. If you are really into it you could redefine the existing button bars as described under User:Cacycle/wikEd#Custom_buttons (only the "// define custom button bars" part of the example). The wikEd program code resides on a Wikipedia page and is public domain, just follow the "Scripts: Main" in the wikEd navigation box on top of every wikEd related page.

Pgan002 says:

"Some of those editing functions are superfluous, as they are already implemented by any browser that supports Javascript: Undo, Redo, Search, Replace, the search modes, Jump to top/bottom"

Can you please explain this? I'm using Firefox, but I don't seem to have Search/Replace available. How do you access it? NigelG (or Ndsg) | Talk 17:19, 20 January 2007 (UTC)

My apologies -- there is no undo/redo yet in Firefox, though it has been suggested and apparently is implemented in Konqueror. -Pgan002 05:55, 23 January 2007 (UTC)

In the newest update 0.9.21 I have moved the edit buttons above the text box and I am surprised how much better it looks. That should also solve the space problem as you could just scroll them out of your window (simply click the scroll button). Cacycle 02:51, 21 January 2007 (UTC)

Thanks for considering my suggestion! I also think it is better :-) -Pgan002 05:55, 23 January 2007 (UTC)

Using wikEd on other wikis

Hi, I have been using wikEd and I have found it very useful. I was wondering if you could tell me how to put it at Neverwinter which is hosted by Wikia. Actually, I think that a lot of wikis would benefit from this. --Leon (talk) 22:53, 18 January 2007 (UTC)

Check User:Cacycle/wikEd#Complete_version, the same code works for every MediaWiki installation. Cacycle 05:10, 19 January 2007 (UTC)

Actually, the install template is the only thing that doesn't work. I only copy what the template creates for me. I mention this because some users (like I did originally), believe that means they need to copy the full source. That is incorrect.

My other suggestion would be to install the CSS code I have at Wikia:Starwars:User:Will Pittenger/monobook.css#Turn the side bar into a series of drop menus. Doing so will help you reclaim some of the horizontal space you lose to Wikia's ad system. Note: The section link might not work unless you manually purge the page. Sorry. Will (Talk - contribs) 07:09, 19 January 2007 (UTC)

Can not delete without typing first.

I am using Firefox (2.0.0.1) on Mac OS x 10.4.8 and have discovered that wikiEd will not delete text from the text box unless I type a character first. This does not affect the same browser under Windows XP SP 2.Phatom87 04:51, 19 January 2007 (UTC)

Sorry, this is a browser bug and I cannot develop a workaround because I cannot test the code under MacOS x Firefox. Cacycle 23:26, 19 January 2007 (UTC)

Thanks. This is mostly an anoyance any way.Phatom87 18:50, 22 January 2007 (UTC)

Unexplained JS error from wikEd code

I was checking my Java Console for more errors. (I found some wiki code that wasn't commented out in my CSS file.) I noticed the following error.

Error: [Exception... "'Permission denied to set property XULElement.selectedIndex' when calling method: [nsIAutoCompletePopup::selectedIndex]" nsresult: "0x8057001e (NS_ERROR_XPC_JS_THREW_STRING)" location: "JS frame :: http://en.wikipedia.org/w/index.php?title=User:Cacycle/wikEd.js&action=raw&ctype=text/javascript&dontcountme=s :: WikEdSaveButtonHandler :: line 1600" data: no] Source File: http://en.wikipedia.org/w/index.php?title=User:Cacycle/wikEd.js&action=raw&ctype=text/javascript&dontcountme=s Line: 1600

Will (Talk - contribs) 08:27, 20 January 2007 (UTC)

Might be related to your other monoscript code. Anyway, it would prevent you from submitting a page under wikEd, so I guess it is no longer an issue. Cacycle 19:00, 21 January 2007 (UTC)

I can host some wikEd-related galleries for you

Would it help if I added some wikEd-related galleries to my user space at User:Will Pittenger? Included would be galleries for themes, custom buttons, and (if you don't already have one) translations.

However, I have to ask that you provide a API page in your user space. This needs to have details on how to build custom buttons, translation, syntax highlighting themes. etc. Once that happens, the demand for galleries should go up. Unfortunately, a sample won't be enough. For the custom buttons, you might be able to settle for mostly samples by showing what the built-in buttons look like in code (without requiring coders to wade through your master code looking for what they want).

Will (Talk - contribs) 03:14, 21 January 2007 (UTC)

Since such code would go on a normal non-.js page they could go in the current wikEd hierarchy. I really do not have the time and motivation to develop alternative themes or alternative buttons, my whole spare time goes into fixing and improving wikEd itself. However, the complete API documentation is on the wikEd homepage and the translation page for everybody who want's to do it. That's all I can do at the moment. Cacycle 18:57, 21 January 2007 (UTC)

I did not assume you would devote time to developing the themes and buttons. Rather, the entire point to the gallery was to get others to do that for you. Will (Talk - contribs) 00:27, 22 January 2007 (UTC)

Documentation

The full version can go between "nowiki"s, I would think. Rich Farmbrough, 11:49 21 January 2007 (GMT).

Thanks, I have corrected the sentence. Cacycle 18:50, 21 January 2007 (UTC)

Syntax highlighter has problems with #if conditions

Can you explain why the #if conditions are formatted the way they are while editing User:Will Pittenger/templates/Summary Consistently Omitted? Look at how it formats "{{#if:{{{2|}}}|2}}". Looks like it does the same thing in this page before I put the <nowiki> tags in. Will (Talk - contribs) 02:55, 24 January 2007 (UTC)

The syntax highlighter is not made for nested elements of the same type for the sake of simplicity and speed. Cacycle 03:23, 24 January 2007 (UTC)

New control options

I think it some simplified buttons might be helpful. Perhaps some that simply insert a string when clicked would be a good idea. The user provides the string and button image in their monobook. A template might be able to subst the code in. I might use such buttons to add something like some of my custom reminder templates (like {{User:Will Pittenger/PlusTab}}). As is, even with shortcuts, it takes a lot of typing. Unfortunately, as is, button development appears to require some JS development expereince. I would like to see average Wiki-coders able to create at least simple buttons.

I don't know if such a macro-like button could handle something like <code> tags or not. Such a button would need to remove the tags if they are already present. Same for <pre>. However, I would like the option of telling the button to ask for parameters if you could do that. (PlusTab requires three.)

I also like the idea of providing collapsible buttons. Some might be simply a toolbar that hides inside a button. Stuff you don't use much could hide there. Others might be like in Word where you have a radio button setting (like the font color). You open it to choose a color.

I am guessing all this would take some time to develop. However, I think it would turn out to be worth it. Will (Talk - contribs) 03:12, 24 January 2007 (UTC)

If you implement some drop buttons, here are some things that could then be created, possible by 3rd party users:

• Smilies -- Ideally we should get a theme system where something like :) is represented by " :)". A emoticon theme would specify typical entries. Not all themes would provide all entries (like some fonts omit some characters). Only the image would be placed into the text. However, the text emoticon might be used as a tooltip.
• Text alignment -- The only choices would be those supported by HTML. Note: With my limited CSS skills, I commonly end up using HTML <center> tags even though those are deprecated. Something like this would help.

Will (Talk - contribs) 09:41, 27 January 2007 (UTC)

Replace all

When will the Replace All functionality be completed? From my point of view, it doesn't look like much work. Will (Talk - contribs) 03:13, 24 January 2007 (UTC)

It has already been implemented a while ago and works fine. Cacycle 03:24, 24 January 2007 (UTC)

Ok. My last test did not work. Don't know why. It's working for me now. Will (Talk - contribs) 21:15, 24 January 2007 (UTC)

It replaces only in selections if text is selected. Cacycle 22:55, 26 January 2007 (UTC)

Underscores in wiki links

Can we get something that strips out underscores from Wiki links? I sometimes copy links from the URL bar because that is unformatted. But its a pain having to manually remove those. I though something like the [W]/[T] buttons or one of the Fix buttons would do this job. But not yet. Will (Talk - contribs) 03:17, 24 January 2007 (UTC)

Good idea, I will think about how to implement it. Cacycle 22:56, 26 January 2007 (UTC)

Details:

• Don't do anything if only part of a link is selected, the selection doesn't include any part of a link, or there is no selection
• I think we also need the same tool to convert URL links to Wikis into inter-wiki links. So, "[http://en.wikipedia.org/w/index.php?title=User_talk:Cacycle/wikEd]" would be converted into "[[User talk:Cacycle/wikEd]]".

Will (Talk - contribs) 09:28, 27 January 2007 (UTC)

While we are at it, I think buttons to trigger simple grammar and spelling changes might be a good idea. I am just talking about replacing "i" (the word) with "I" and similar activities. I don't know how much the RegEx stuff does, but in my previous tests, "i" was ignored. Perhaps a version of the RegEx filters in the local JS file would be a good idea. Then users could make changes as they saw fit without affecting other users. Will (Talk - contribs) 08:33, 1 February 2007 (UTC)

Changing font information from wikEd

Any chance that a future wikEd version could generate Span tags to let users change the font, color, background, or size of text? That would be helpful. (You would need to remove or move existing tags.) Will (Talk - contribs) 03:22, 24 January 2007 (UTC)

Nope. Same for div tags. However, they are not that difficult to type by hand, are they? ;-) Cacycle 03:30, 24 January 2007 (UTC)

Develop the buttons by hand? The code would take some time and buttons would not work. As for as simply generating the span tags myself, that's what I do now. However, it is a pain to experiment with colors looking for the one you want. It would help to just point at the one you want and get it. Will (Talk - contribs) 03:50, 24 January 2007 (UTC)

Formatter

You might want to note that the Formatter script (adds a format tab to edit pages and fixes extra whitespace, etc.) does not work when wikEd is enabled. Other than that, great program! -- Tuvok^^{Talk|Desk|Contribs}  00:04, 31 January 2007 (UTC)

Does it work if you temporarily disable wiked, use the Formatter script, and reenable wikEd? It's the button in the right button bar with the wikEd logo. Thanks, Cacycle 02:40, 31 January 2007 (UTC)

It appears to. Perhaps you'd consider adding the features of this script to wikEd; it would be really useful, especially seeing how many features wikEd already has. -- Tuvok^^{Talk|Desk|Contribs}  03:00, 31 January 2007 (UTC)

sigContract

I've actually noticed a major issue with Where's sigContract script. The script removes complicated, properly tagged signatures from the edit window, and puts them back when one of the form buttons (Save, Preview, or Diff) is clicked. wikEd is loading the contracted versions of the signatures, but sigContract can't put the expanded versions into the edit box before submission. Maybe this is something Where can add to the script using your compatibility instructions; I'm not sure. -- Tuvok^^{Talk|Desk|Contribs}  23:45, 31 January 2007 (UTC)

Looks like a real incompatibility to me. One has to make sure that the sigContract script runs before wikEd takes over and then again after wikEd has done its job after pressing the submit button. Cacycle 00:24, 1 February 2007 (UTC)

So you would recommend that I disable sigContract, right? If I don't, I'd have a serious problem whenever I edited pages with sigContracted sigs. -- Tuvok^^{Talk|Desk|Contribs}  01:10, 1 February 2007 (UTC)

No, let it enabled, it is a great way to remove those monstrous signatures :-) Cacycle 01:43, 1 February 2007 (UTC)

I don't appear to be having any problems with the combination. Will (Talk - contribs) 05:55, 1 February 2007 (UTC)

Correction, sigContract looks to be disabled. Will (Talk - contribs) 09:25, 1 February 2007 (UTC)

It was working yesterday... Weird. And FYI, it was working long enough for you to change my sigs above. I'll leave them for now. -- Tuvok^^{Talk|Desk|Contribs}  23:32, 1 February 2007 (UTC)

Weird, it's hiding my sigs but not yours. This one can't be worked around by disabling and enabling wikEd. I think the workaround is to not use wikEd on pages with signatures. -- Tuvok^^{Talk|Desk|Contribs}  23:36, 1 February 2007 (UTC)

That looks like like it is an intelligent algorithm ;-) There is also the possibility not to use sigContract (for a more realistic Wikipedia feeling) ;-) Cacycle 23:44, 1 February 2007 (UTC)

I feel really bad about this decision, since I had to get Where's help to make sigContract work in the first place, but wikEd is going to take precedence over sigContract. I'm disabling sC. -- Tuvok^^{Talk|Desk|Contribs}  00:27, 2 February 2007 (UTC)

Can you build sigContract logic into wikEd? Will (Talk - contribs) 04:11, 2 February 2007 (UTC)

No way. Why should I shield users from the mess their signatures leave. Cacycle 14:00, 2 February 2007 (UTC)

:) -- ∂ 14:20, 2 February 2007 (UTC)

faulty custom option

I noticed the following option in your Customization section.

var wikEdFollowHighlightedLinks = true;

I think you want to take the "var" part out. The variable is probably already declared and might be causing errors. Will (Talk - contribs) 08:53, 1 February 2007 (UTC)

No, that's ok. It's the way to add presets to wikEd. If you check the program code you can see that the presets are redefined using the previous value if there exists one:

var wikEdFollowHighlightedLinks = wikEdFollowHighlightedLinks || false;

Cacycle 13:32, 1 February 2007 (UTC)

You put the options before the code? I had added mine afterwards. Also, what does that option supposed to do? Will (Talk - contribs) 04:14, 2 February 2007 (UTC)

Yes, as stated under User:Cacycle/wikEd#Customization. It is supposed to make links followable after syntax highlighting without any preview. Cacycle 13:50, 2 February 2007 (UTC)

Ok. I moved the options before the include for the code. However, I still am stumped. I see no way to follow the link. I tried clicking the link with all three mouse buttons and all three modifiers. Will (Talk - contribs) 07:53, 4 February 2007 (UTC)

It is not yet implemented (as stated...) Cacycle 02:53, 5 February 2007 (UTC)

What is implemented? Will (Talk - contribs) 04:36, 5 February 2007 (UTC)

Heading changes problem

When I click the button to Increase Heading Levels, it should ignore lines that aren't headings unless that is all that is selected. In the past, I have wanted to demote or promote entire sections which might have subsections inside. wikEd currently doesn't let me do that. If I try, each paragraph becomes a major section. I have to demote or promote each heading individually. Will (Talk - contribs) 09:24, 1 February 2007 (UTC)

Fixed (0.9.23). New headings are not created for multi-line selections. Cacycle 03:15, 2 February 2007 (UTC)

More informative summaries are needed

Cacycle, I have seen that you commonly reply to several posts with one edit. That's nice and efficient. However, it also forces everyone to check to see if you replied to a thread they are following. Which summary do you find more informative?

• A: "Replied".
• B: "Replied to →Minor suggested changes, →Modified layout below the save button, and →New button bug."

As shown, MediaWiki does allow for multiple section names. Just surround each in /* */. Will (Talk - contribs) 04:29, 2 February 2007 (UTC)

Is that one of your templates? ;-) Cacycle 04:44, 2 February 2007 (UTC)

Templates? They don't work in edit summaries. The software does it for you. Will (Talk - contribs) 04:51, 2 February 2007 (UTC)

mimick original function of redirects?

Is it possible to mimic MediaWiki's redirect highlighting? When you hit the redirectbutton of the default bar, the text of the link is highlighted, but WikEd selects theentire text. Can thatbeeasily fixed? Circeus 17:58, 2 February 2007 (UTC)

I am not sure if I understand what you are suggesting. Please could you elaborate. Thanks, Cacycle 22:12, 2 February 2007 (UTC)

Selections after buttons fixed in 0.9.24. Cacycle 07:20, 4 February 2007 (UTC)

Find and Replace problems

• There is no information that I saw as to which regular expression syntax to use for Find & Replace. I finally figured it out. But I think a collapsible pop–up showing options would help. Or make it like MS Word and Visual Studio by making it a menu that inserts into the box. The VS one is pretty smart. (At least it was in v2003.) When you insert something like a set, it put the cursor inside the set marker. I finally figured it out, but there was very little information on the web as to what to do with the replace box. At first, I tried \1. Then I noticed what little information I found also listed $1. That worked. You might consider creating a Regular Expression syntax rules page of your own in the wikEd namespace.

Check the wikEd_help, it's all there. Cacycle 18:42, 3 February 2007 (UTC)

• When you start to type in the find box, you change the selection. However, you also stated that Replace All ignores unselected text. I think you should make it like MS Word. When Replace All is used such that replacement is limited to selected text, once the replacement is done, it asks for permission to go outside the selection.
• New Item: I keep trying to tab and shift tab between the find and replace boxes. Can you arrange that by having the controls capture those keys and sending the focus in the correct direction?

Added to 0.9.24b, see help page. Cacycle 05:09, 5 February 2007 (UTC)

Will (Talk - contribs) 08:30, 3 February 2007 (UTC)

Uncheck the Find ahead button if you don't want to change the focus. If you want to change the whole text all you have to do is to have no selection. Cacycle 18:42, 3 February 2007 (UTC)

New item. Will (Talk - contribs) 07:43, 4 February 2007 (UTC)

Special Characters and related links

When you insert special characters from the part below Live Preview, wikEd behaves oddly. First, if text is selected, special characters should replace the selection. On the other hand, if I click links like <includeonly>, I would expect it to put the inlcudeonly around the selection. Also, when wikEd is done inserting, it always leaves the inserted text selected. This doesn't make sense either. Will (Talk - contribs) 08:36, 3 February 2007 (UTC)

The insert special characters are not the responsibility of wikEd, actually they already work a bit more intuitive under wikEd. For me <includeonly> does put the tags around the selection. I will probably change the selection issue. Cacycle 18:49, 3 February 2007 (UTC)

Selections after buttons fixed in 0.9.24. Cacycle 07:18, 4 February 2007 (UTC)

Editing problems

• when I delete text using the key delete, the caret (cursor) sometimes (e.g. when the color of the text changes or a pipe should be deleted) just disappears and I have to click again to the place to be able to continue deleting.

Old problem. Until Cacycle says otherwise, I suspect it is caused by the rich text control. He has no control over that. Do you use Firefox? If so what version? I use Firefox 2.0. Will (Talk - contribs) 09:27, 3 February 2007 (UTC)

I'm using Firefox too. Usually 2.0 or the previous version. --Eleassar ^{my talk} 10:48, 3 February 2007 (UTC)

Unfortunately, there's nothing I can do about it. It is one more of those annoying Mozilla bugs. Cacycle 18:31, 3 February 2007 (UTC)

• when I edit some text and then disable the wikEd, the classic toolbar does not reappear. When I press save, the edit window disappears, but the changes are lost (well, this happened once, I didn't test more).

How are you hiding the standard toolbar? Will (Talk - contribs) 09:27, 3 February 2007 (UTC)

Standard toolbar? I'm not hiding it. It simply isn't there when I have wikEd installed and enabled. It should reappear immediately after I disable wikEd (in the editing mode). --Eleassar ^{my talk} 10:48, 3 February 2007 (UTC)

I hide the classic (aka standard) toolbar from preferences. wikEd can't hide or show it for me. I actually find the Hide/Show button that wikEd offers redundant. If Cacycle ever tells me how to hide it, I probably will. Will (Talk - contribs) 07:49, 4 February 2007 (UTC)

For me the standard toolbar behaves exactly as suggested. Please could you give me an exact procedure to reproduce your problem. Did you notice the toggle standard toolbar button - its setting is saved. As for the disappearing edit: as stated on the wikEd homepage, that happens irregularly when you use the browser's back button after submitting the article to make more changes. You have to click the standard edit article link instead. Cacycle 18:12, 3 February 2007 (UTC)

• if I click the redirect button and try to enter the text; the code #redirect disappears and is replaced by the text entered. Only the text inside the brackets should disappear.--Eleassar ^{my talk} 09:19, 3 February 2007 (UTC)

I don't see this can be fixed without changing what is selected. Should the selection be changed? Yes. I think so. Will (Talk - contribs) 09:27, 3 February 2007 (UTC)

Yes, I think so too. Also the edit summary should include not only "#redirect" but also the target link (i.e. "#redirect Foo"), or it should be absent completely (so that MediaWiki fills it out). --Eleassar ^{my talk} 10:48, 3 February 2007 (UTC)

Type the link target first, go over it (or select it if it is multi-word), then push the button. I will probably change the selection to the orange placeholder so that you can start typing immediately. Cacycle 18:31, 3 February 2007 (UTC)

Selections after buttons fixed in 0.9.24. Cacycle 07:18, 4 February 2007 (UTC)

[W] has problems with pasted HTML tables

I found that wikEd has problems converting a pasted HTML table into wiki code. Go to Wikipedia talk:Userboxes/New Userboxes#Tools that can be used to create Nation and state user boxes and try pasting the table shown into a wikEd box without looking at the source. Click [W] after pasting. Now compare the wikEd version with the orginal source. In my tests, options like style, colspan, and rowspan attributes were dropped. Will (Talk - contribs) 01:59, 5 February 2007 (UTC)

That is to prevent Word from cluttering up wikified tables with options. However, colspan, and rowspan are important and should not be removed, I will fix that. Cacycle 02:51, 5 February 2007 (UTC)

colspan and rowspan are preserved, so there is no need to fix it. I am thinking about a shift-wikify that keeps everyting. Cacycle 04:28, 5 February 2007 (UTC)

[T] problems

Sometimes when I paste text (including from other wikEd boxes) and then press [T], I see each line getting a new space at the beginning. That should not be happening. Will (Talk - contribs) 04:40, 5 February 2007 (UTC)

Please could you give me a recipe to reproduce that. Thanks, Cacycle 05:11, 5 February 2007 (UTC)

At the moment, no. Maybe it disappeared. If it reappears though, I will see if I can repro it reliably. Will (Talk - contribs) 05:15, 5 February 2007 (UTC)

Custom button problems

What is wrong with custom buttons I had at User:Will Pittenger/monobook.js#Custom Buttons? The first two (in the order declared) were working fine. When I tried to add the most recent two, it stopped working. I had not tried the older ones in a couple of days. Will (Talk - contribs) 08:28, 7 February 2007 (UTC)

Norwegian translation

I translated WikEd to norwegian, for use on the english wikipedia (User:Dvyjones/wikEd_international_no)

Dvyjones^t·c·e 17:29, 7 February 2007 (UTC)

Sign button

WikEd should have a sign button so it would paste ~~~~ at the end of the page (or at the cursors position) Dvyjones^t·c·e 17:41, 7 February 2007 (UTC)

There is a link underneath the summary box unless you hid it. Otherwise, see the section on custom buttons. Will (Talk - contribs) 06:32, 8 February 2007 (UTC)

The links under the text area dissapeared after i installed WikEd —The preceding unsigned comment was added by Dvyjones (talk • contribs) 14:27, 8 February 2007 (UTC).

Pasting problem

I'm having a bit of a problem when pasting text that is formatted differently than that in the WikEd textbox. It keeps its original formatting instead of adopting the formatting of the WikiEd box. Can this be fixed?

If you click the [W]ikify button the formatting will be converted to wikicode. If you press the [T]extify button all formatting will be remove, leaving only the plain text. See also the User:Cacycle/wikEd help page. Cacycle 02:24, 9 February 2007 (UTC)

Also, I'd be very interested in getting WikEd to work in IE7 and Opera, but I don't really understand the code. If you could guide me though it, perhaps by just presenting one problem at a time, I may be able to help you get it working. —Remember the dot (t) 20:22, 8 February 2007 (UTC)

Thanks for your offer :-) wikEd consists mainly of two parts:

• The setup routine WikEdSetup() is responsible for initialization, for rearranging page elements into wrapper divs, for putting the buttons on the page, and for generating the combo input boxes (input with drop-down button)
• The button handlers:
  • WikEdButton() for buttons that do not require nor change the text
  • WikEdEditButton() for buttons that require or change the text (slower)

Making the code compatible with IE or Opera should start with the WikEdSetup() routine. I will add configuration variable to skip the browser test that currently stops the wikEd installation when it detects IE. For performance reasons it is highly recommended to test the scripts on a local copy of a Wikipedia edit page in that all addresses to scripts, css files, and images have been changed to local copies. Relative links have to be preceded with "http://en.wikipedia.org". Configuration variables can be set in the header JavaScript of the page, e.g.:

var wikEdUseLocalImages = true;
var wikEdImagePathLocal = 'file:///D:/wikEd/images/';
var wikEdSkipBrowserTest = true;
var wikEdShowSourceButton = true;

Cacycle 02:24, 9 February 2007 (UTC)

Please see the new development pages for User:Cacycle/wikEd development (documentation) and User talk:Cacycle/wikEd development (discussion). They are easily accessible through the wikEd navigation box on every wikEd-related page. wikEdSkipBrowserTest has been implemented, please update to 0.9.24c. Cacycle 03:27, 9 February 2007 (UTC)

The banner to link to your page

I would like to have the image and the links to your site to connect from my site. The image on your home page along with the links to each pages would be a great thing to introduce your editor and to have an immediate link to your pages. Would you please consider making it available for your fans? Thank you --Kohyin 12:00, 9 February 2007 (UTC)

Translation to Slovenian: update

Thanks for notifying me. I have put your original .js page to watchlist now. --Eleassar ^{my talk} 18:20, 28 January 2007 (UTC)

wikEd logo

I just noticed something -- the logo doesn't show up in the upper right when I'm in normal mode at an article or its talkpage, but it does show up if I'm looking at something like a watchlist or contrib history. Not article history though, just user contrib history. Strange! Anyway, hope that helps track it down for you.  :) --Elonka 00:33, 3 February 2007 (UTC)

Italian wikEd

Hi, I'm translating wikEd for the italian wiki. Just a question: in your code you've written

wikEdLocalPreview.title = 'Show preview below';
wikEdLocalDiff.title = 'Show current changes below';

Theese two lines prevent me from translate the related terms. Could you modify them, reading the strings from the translation page? (respectively 'wikEdLocalPreview title' and 'wikEdLocalDiff title'). Thanks --Jalo ^{Write me here!} 13:48, 3 feb 2007 (CET) —The preceding unsigned comment was added by 151.31.33.241 (talk) 19:38, 3 February 2007 (UTC).

Thanks, I have fixed it, press Shift-Reload to update to 0.9.23b. Cacycle 19:52, 3 February 2007 (UTC)

Bug report

Okay, I've been using WikEd for a day or two now, and I've noticed the follwoing quirky behaviors:

• After cutting or pasting, the up and down arrow keys take you to the top or bottom of the page, rather than the next line like they should. Makes it very difficult to edit.
• The text cursor disappears a lot, so you can't see where you are in the text.

I hope this report helps. The Transhumanist   05:38, 7 February 2007 (UTC)

These two are annoying Mozilla browser bugs, I cannot do anything about it. Sorry, Cacycle 01:22, 8 February 2007 (UTC)

Translation to norwegian

I translated WikEd to norwegian, have a look at User talk:Cacycle/WikEd --Dvyjones^t·c·e 17:32, 7 February 2007 (UTC)

Norwegian wiki

Hi! Can I copy and translate the WikEd pages from here to my user page on the norwegian wiki? --Dvyjones^t·c·e 19:34, 7 February 2007 (UTC)

That's great! Go ahead. Cacycle 21:18, 7 February 2007 (UTC)

Edit top bug

Please edit and preview the intro of Balance of Power with something like Wikipedia:WikiProject User scripts/Scripts/Edit Top (which adds an edit link for the introduction. Because the text is too short to push the edit box down, the text in the edit box flows around the infobox. -Will Pittenger 02:38, 28 November 2006 (UTC)

Probably fixed in the next version, please report back when using 0.9.12. Cacycle 01:58, 2 December 2006 (UTC)

I am now using 0.9.12a Beta. No fix as of yet. -Will Pittenger 04:33, 6 December 2006 (UTC)

No joy with 0.9.12b Beta. -Will Pittenger 04:30, 14 December 2006 (UTC)

0.9.13a doesn't help either. Still waiting for a fix. Will (Talk - contribs) 22:32, 18 December 2006 (UTC)

The bug is still present with 0.9.19a Beta. Will (Talk - contribs) 20:08, 12 January 2007 (UTC)

0.9.27c fixes this problem. Thanks. Will (Talk - contribs) 05:41, 25 February 2007 (UTC)

Possible full screen bug

Possible full screen bug: When I click the full screen button, I got links to "discussion" and "edit this page" on top of the edit box. -Will Pittenger 03:02, 28 November 2006 (UTC)

Screen shot? or preference settings? Cacycle 06:47, 30 November 2006 (UTC)

See Image:WikEd full screen bug screenshot.PNG, User:Will Pittenger/monobook.js, and User:Will Pittenger/monobook.css. -Will Pittenger 06:28, 1 December 2006 (UTC)

Probably fixed in the next version, please report back when using 0.9.12. Cacycle 01:58, 2 December 2006 (UTC)

As noted above, I am now using 0.9.12a Beta. This problem is still present. -Will Pittenger 04:36, 6 December 2006 (UTC)

Now I am running 0.9.12b Beta. This problem is still present. Will Pittenger 04:28, 14 December 2006 (UTC)

0.9.13a doesn't help either. Still waiting for a fix. Will (Talk - contribs) 22:33, 18 December 2006 (UTC)

Still present in 0.9.19a Beta. Will (Talk - contribs) 20:09, 12 January 2007 (UTC)

Still present in 0.9.27a. Will (Talk - contribs) 05:44, 25 February 2007 (UTC)

I cannot replicate this problem under Firefox nor Seamonkey, not even when using your monobook.js. Cacycle 02:37, 26 February 2007 (UTC)

Suggestion

How about to reach the big 1.0, you put in a full WYSIWYG editor and an option to switch between the two editors (pseudo-WYSIWYG and full WYSIWYG)? --- Year2000Prob 07:14, 10 December 2006 (UTC)

I already asked for that. See My long term wikEd wishlist. -Will Pittenger 06:07, 12 December 2006 (UTC)

Too slow

This tool would be very useful if it would not take so long to have pages uploaded. When I open a page for editing, I have to wait e.g. 15 sec to be able to edit. --Eleassar ^{my talk} 11:14, 24 January 2007 (UTC)

How fast is your computer and your internet connection. Does it happen always or only on long pages or during periods were Wikipedia is serving the pages slowly. Cacycle 22:52, 26 January 2007 (UTC)

I have measured the program execution times - it turned out that the simple addition of the CSS style rules were responsible for the slow page loading. By replacing the unbelievably slow (but standards-compliant) style.insertRule with style.innerHTML, a massive speed-up of page loading was possible. On my computer it went down from > 5 s to 0.8 s. Please update to version 0.9.27. Cacycle 00:06, 25 February 2007 (UTC)

The wikEd edit box needs a TOC control of some sort

Can we get a TOC for the edit box? Something that lets me jump to a section header is enough. When I am working on my user page, a TOC becomes required. Will (Talk - contribs) 06:45, 28 January 2007 (UTC)

Added in 0.9.28, check the find drop-down. Cacycle 02:41, 13 March 2007 (UTC)