[Home]MeatballWikiBugsResolved

MeatballWiki | RecentChanges | Random Page | Indices | Categories
Old MeatballWikiBugs, possibly of historical interest.

Tabs to spaces:

Many browsers have problems with tabs. I cannot type them by hitting the tab or ctrl+i keys. If I need them I seek another page that already has a tab on it, and use cut and paste. A well-designed Wiki should not require me to do this, in my view. -- DaveHarris

I use Notepad for this purpose. I agree that tab-based formatting is a Wiki bug (mis-misbug?). I've already implemented a simple substitute for unordered lists (*, **, ***, etc), and I'm considering similar substitutes for other formatting conventions. (Wiki:BoLeuf made some interesting suggestions recently via email.)--CliffordAdams

Indeed - I appreciate the unordered lists. Another simple idea is to treat runs of spaces as tabs - say 4 per tab, at least when they come at the beginnings of lines. JosWiki does this. -- DaveHarris

PS I've grown to hate the indented interpolated comment look of dictionary lists, so it doesn't bother me that I can't type them. -- DaveHarris

treat runs of spaces with tabs

While this would be nice, it breaks code formatting. Maybe use *, **, *** unordered list and #, ##, ### ordered list and """block quote""" ?? -- SunirShah

(Discussion moved to TabsAndSpacesDiscussion.)

For ordered lists, the # character seems OK, but I vaguely recall that the # character may not be on some international keyboards. (Then again, ordered lists are rare, so I might not really care.) Quotes are a problem--it is reasonable to start a line with double-quotes. In some fonts they are difficult to distinguish from two single-quotes. I was considering : (colon) for the indented block-quote. -- CliffordAdams

According to MSDN, the following characters are not usable on international keyboards: @ $ { } [ ] \ ~ | ^ ' < > -- SunirShah

I'm leaning toward keeping the old tab-based Wiki formatting, but I'm wondering if *anyone* really likes it. One argument against keeping it is that some browsers mangle tabs in the edit area. Another argument is that mixing old/new styles will make the edit pages ugly. Perhaps I could detect the old style and convert it to the new style when it is saved?

Eventually (after 1.0) I'd like to offer a subset of HTML tags, since they are popular in many forums. --CliffordAdams

For version 0.82 I decided to remove the old tab-based style and add some HTML tags. --CliffordAdams

I've implemented alternate forms of numbered lists, definition lists (quote blocks), and preformatted text. See the SandBox, and later the TextFormattingRules. --CliffordAdams

Perhaps you could escape preformatted text with <PRE></PRE> tags. This would get around the "space in to monospace" rule. -- SunirShah

Right now, I'm thinking of adding a pseudo-tag "<pre>", with a closing "</pre>". I've been annoyed at the current handling of preformatted text. --CliffordAdams [Now done. --CA]

Punctuation and URLs:

Note: link delimiters have changed since this text was written. See TextFormattingRules for the current situation.

There is a (de facto) bug in the link pattern for URLs where-by they include trailing punctuation. Strictly speaking, URLs may end in commas, full stops and question marks, and certainly you should allow these characters in the middle of an URL, but when they occur at the end they are almost always intended as punctuation. I believe this has been fixed for page links, eg LinkPattern, but not for URLs, eg http://www.bhresearch.co.uk/DrhFeed.htm. -- DaveHarris

At first I resisted this, because I don't want to restrict valid (although unusual) URLs. However, I just realized that you could add a second punctuation character to the end in the (hopefully very rare) case that the actual URL ends with punctuation. For instance: http://www.usemod.com/cgi-bin/mb.pl? is a reasonable URL (the ? is useless). After the change is made, one would need to use something like http://www.usemod.com/cgi-bin/mb.pl?. to use the ? character in the URL. Yes, I worry too much. --CliffordAdams

Done. --CliffordAdams (who spent more time typing the paragraph above than fixing the problem)

This is Wiki:StillBroken!! <-- note the two punctuation marks in a row. More commonly exemplified as (Wiki:Foo, Wiki:Bar, Wiki:Baz).

Obviously ignoring only one punctuation mark isn't adequate (at least for the overly excitable or parenthetical ;-). I do not want to emulate the C2 wiki, which excludes valid URLs. On the other hand, it is important for links to look nice and flow well with text. The current behavior (delete one "trailing punctuation" character) is good for a few common cases, but it is hard to explain and surprising in the examples given.

I'm considering following one of the official URI recommendations (rfc 2396 Appendix E: http://www.ietf.org/rfc/rfc2396.txt) and allowing double-quote (") delimiters (which are not rendered), like: 

The sites ("http://www.usemod.com/" and "http://c2.com") are good.

...which would be rendered like:

The sites (http://www.usemod.com/ and http://c2.com) are good.

In this case, the rules would be greatly similified to delimit the URL (or InterWiki link) at:

Another recommendation is the angle brackets "<>", which I considered before double-quotes. There are several nasty interactions with the <> characters and quoting, however, that would make them difficult to use in a wiki context. (For instance, it is legal (but probably immoral) to include ">" in a URL.)

Comments? --CliffordAdams
Wiki: Links

Wiki:FrontPage includes the </em> in the URL.

Fixed.
Formatting bug with ; lists

The ; formatting didn't work properly if the definition term contained HTML-special characters like <>& which are quoted. (The quoted form contains a ;, which was taken as the delimiter of the term.) For instance, the following example was mangled: 

;<b>Bold text term</b>;Some text here.

Considered fixes:

Resolved by changing the second character to a colon (:). Only 8 pages had used this formatting rule.

Search appears to be broken

The search feature seems to be broken... When I just tried searching for "Meme" using the search text-box, I received a "cgi/bin access forbidden" error. Side-effect of the changes at the hosting provider? Hopefully a quick fix.

"It was working fine this morning..." I did a few more searches after your message, and they seemed OK. I'm experiencing some network difficulties reaching www.usemod.com (and other Futurequest sites), however, so I haven't done much testing. --CliffordAdams

Went back in and tested it (this time with both Mozilla and Netscape). I can't see any difference in the HTML between UseModWiki and MeatballWiki, but UseModWiki searches work just fine, whereas MeatballWiki searches continue to produce the error. And yet, if I manually type in http://www.usemod.com/cgi-bin/mb.pl?search=meme, everything's hunky-dory.

Correction: MeatballWiki has a <BASE> tag in its pages, whereas UseModWiki doesn't. That <BASE> tag, at least in Netscape and Mozilla, causes searches to funnel through the given URL. Which, in this case, is simply http://www.usemod.com/cgi-bin/, which doesn't seem to be happy getting a POST.

Your correction is correct. When I changed the BASE, I also needed to have the search form have an "ACTION" of "mb.pl". This fix is now installed. --CliffordAdams (who doesn't always like MSIE's "accept almost any garbage" philosophy)

Edit window wrap: (Browser issue)

When you go into EditPage?, the editor window does not wrap at the margin. If you type, it shows up as a very long line, which is not as useful as it would be if it wrapped. -- AnonymousDonor

Browser, version, operating system?

Redhat Linux 6.2 Browser is kfm version 1.167.2.21. The non-wrapping behavior is only present in the Editing window. Once I hit the Save button, the page reloads and the words are wrapped correctly. -- AnonymousDonor

Your browser is malfunctioning. It is munging the edit text. You can see some evidence on MeatballWikiCopyright (if you hurry). -- SunirShah

Munging? I am trying kfm, as my Linux box keeps crashing when running Netscape. I'm not sure how I could screw up text on one page, and not text on another. Rather, from what I see, the wrapping on the pages is broken as well. The page width seems to depend on the longest indented line. For example, this page has no indented lines and wraps normally. Both LimitTemptation and MeatballWikiCopyright are as wide as the longest indented line. I don't think that is a function of my browser. -- AnonymousDonor

I would be very interested to know if the same browser wraps well with the C2 wiki. UseModWiki sends out WRAP="virtual" (in the TEXTAREA tag). The C2 wiki sends wrap=virtual. I'm inclined to believe that the UseModWiki behavior is correct, as the html is generated by the CGI.pm package.

On WardsWiki the behavior is the same. Things seem to wrap correctly for reading pages, but do not wrap in the edit text window. I do not think that makes this a non-bug. Perhaps it is low priority, but it is still odd that it works this way on any browser. -- AnonymousDonor

I suspect it's your browser. It probably doesn't understand the "wrap=" part of the TEXTAREA tag. Apparently "wrap=virtual" is not standard (at least for HTML 4.0), although it is very useful and commonly implemented. (There is no standard substitute for that behavior. The standard leaves wrapping up to the implementation. See http://www.w3.org/TR/html4/interact/forms.html#edef-TEXTAREA for more information.) Wiki markup is line-based (and I don't see easy ways of changing it short of moving to HTML), so this may be a problem.

I also noticed that your home browser replaced TAB characters with two spaces (even tabs you didn't type). I fixed them here, using the new formatting conventions. --CliffordAdams

Cliff, thanks. I will see if I can get kfm to act differently for both the tabs to spaces, and the "wrap=virtual". I am really glad you provided the alternate ways to indent on Meatball. I like the *, **, and : options. -- AnonymousDonor

September 18, 2000: Apparently the "wrap=virtual" works on most browsers, since I haven't heard any other complaints in the past few months. I've tested it on multiple versions of MSIE, Netscape, and Lynx, and all of them were happy with the wrapping. I think I'll move this to the "resolved" section, as there is nothing much I can do from the server side. --CliffordAdams

The double-double-quote LinkPattern break doesn't work outside of an actual link. Which hurts when you want to write something like 

Link""Pattern

which emits as Link""Pattern. -- SunirShah

Not a bug. The "" marks the end of a link (page, image, InterWiki, or URL). To get what you want, use the "nowiki" tag like LinkPattern (edit this page to see the tags). Yes, this is inconvenient, but one should rarely need to prevent ordinary wiki links. In most cases, a space character between words is the best option if you don't want a link.

Actually, in the case listed above, you can simply use:
<pre> LinkPattern </pre>

and the link will be prevented without *any* special formatting. The multi-line <pre> tags prevent linking, mostly to make them useful for code samples. If you want preformatted text with links, you will have to put one or more spaces at the front of each line, like: 

 LinkPattern goes here.
 This is more preformatted text with links like UseMod:RecentChanges

[Edit this page to see the samples. --CliffordAdams]

I had also problems with this (being used to the Wiki:SixSingleQuotes of WikiWikiWeb).

In a Wiki about programming (talking a lot about functions with names that qualify as links), having to use "nowiki" would be very uncomfortable. I would prefer to sacrifice a special character of the extended character set for such purposes. -- HelmutLeitner

Can't you just wrap the entire code segment in a <nowiki></nowiki> pair?

That will work fine for code snippets (using pre), and in fact this an extreme advantage compared to the situation in WikiWikiWeb. But in the text around the snippets, were you talk about the functions, you can't avoid to mix function names, links and formatting. -- hl

MoinMoin does it like this:

An {{{inline code sequence}}} has the start and end markers on the same line.

A code display has them on different lines: {{{
No markup here!
}}}

-- JürgenHermann

UserName/Preference cookies (explained, HTML "BASE" solution)

[The original attempt at using cookie domains didn't work, so UseModWiki now uses the BASE attribute to keep people at www.usemod.com. See the end of this section for details.]

My UserName didn't show up in RecentChanges even though my preferences lists it. cr82441-a.rchrd1.on.wave.home.com has a cookie installed unlike ottawa.oti.com which I also post from. -- SunirShah

Ok, and it showed up when I edited this page. Don't get it. --ss

It has to do with the "www" third level domain. When I use it, I get my cookie. When I don't use it, I don't get my cookie. There must be some way around this. --ss

Always use www.usemod.com? :-)

There is a possible way around it, but I'm not sure I like it. The cookie standard contains a "domain" attribute which controls which domains the cookie will be sent to. By default (if the domain attribute is not present), the cookie will be sent back *only* to the host that initially supplied the cookie. In your case, "www.usemod.com" was the host on the initial cookie, so your browser didn't send the cookie to "usemod.com".

The simple workaround would be to send cookies with a domain of just "usemod.com", which would be sent to *all* subdomains of usemod.com. I'm considering hosting multiple wikis in the future, however, and wouldn't want cookies for the main wiki to also be sent to "test1.usemod.com", "usemodwiki.usemod.com", etc.

For now, always use "www.usemod.com". Since other sites may want to do things differently, I'll add an option to set the cookie domain. It's not something I want to happen automatically. (Consider if a cookie was set for "sourceforge.net" rather than "usemodwiki.sourceforge.net". Some other admins would be justifiably annoyed. (UseModWiki isn't yet a SourceForge project. I plan to keep usemod.com even if I do add it to SourceForge.)) --CliffordAdams

This policy breaks the functionality of UserPreferences?. Some (most?) people will be coming to MeatballWiki as http://usemod.com/cgi-bin/mb.pl? as that's what I've been writing the links as! (Doh!) However, you could try setting <BASE HREF="http://www.usemod.com/cgi-bin/"> inside the <HEAD></HEAD> tags when generating the pages and see if that helps. -- SunirShah

Another solution is to redirect to www.usemod.com when the www part is missing. -- JürgenHermann

I really don't like using redirection in this way, as broken client software could potentially cause a redirection loop. (Apparently this happens sometimes even for ordinary redirections to another domain.) --CliffordAdams

I'm leaning toward adding the cookie domain option, and setting it to "usemod.com". UseModWiki has a cookie-name option so that multiple wikis can have separate cookies within a single domain. I'm also thinking of printing your current User-ID/UserName on the editing page, so you can easily see which UserName you currently have. --CliffordAdams

It seems that the cookie domain feature doesn't do what I'd like. The biggest problem is that the cookie standard requires two dots in the "domain" field, which means that here the domain would be ".usemod.com". (Plain "usemod.com" doesn't work.) MSIE 5.0 sends ".usemod.com" cookies to the plain "usemod.com" domain, but Lynx (at least my ISP's old version) and Netscape 4.75 won't send the cookie back to the plain "usemod.com". (They might just do a simple right-side matching, and fail because the cookie-domain has an extra "." character.)

The current (September 1, 2000) solution is to add a $SiteBase optional configuration variable. If it is set, it will be used as the BASE value in all non-error headers. It is still possible to go directly to a "usemod.com" page, but all the links on that page will point to "www.usemod.com". [This change has now been added to the public Meatball wiki, and will be included in the next public release.]

Also, in the near future I plan to add a "login" capability to allow users to share a single User-ID from multiple locations. One could use the login feature to share cookies between "www.usemod.com" and "usemod.com" if one uses both URLs. Still, the official URL is www.usemod.com, and that is what should be used for any future links. --CliffordAdams

Couldn't you just make a list of sites in the cookie for usemod.com? So, if you had FooWiki and BarWiki on example.com, in the .example.com cookie, you'd list the ordered pairs: (FooWiki, FooWiki user ID), (BarWiki, BarWiki userID). So, when you fetch the cookie, you extract the appropriate user ID for the current site and move on with your life? You have 4kb of data.. plenty of space. --SunirShah

I'm not sure I understand your suggestion. UseModWiki already does something similar to this with the $CookieName configuration variable. In fact, it's used right now to distinguish the userIDs for Meatball, the test wiki, and the UseModWiki scripts. I also include a "randkey" as a minimal security measure, and a "rev" (revision) number to make upgrades easier.

The "domain" problem I'm referring to is really a client software problem. If I set the domain to ".usemod.com" (like the standard requires), then Netscape won't send the cookie to "usemod.com" (without the dot). If I set the domain to "usemod.com", Netscape apparently considers the cookie to be corrupt (it doesn't even prompt when I turn on the cookie-prompt option). MSIE 5.0 is happy with almost anything. Obviously I'm not going to break the Preferences for Netscape users, especially when the BASE option nearly solves the problem (and the logins will take care of the rest). --CliffordAdams

See RFC 2109 and http://directory.google.com/Top/Computers/Programming/Internet/Cookies/ for more than you ever wanted to know about cookies.

I don't believe all changes listing is working. http:mb.pl?action=rc&all=1

Interesting... I thought I made some changes backwards-compatible. (I added "rc" to the names of some options, like "rcall", "rcnewtop", and "rcshowedit") They are backwards compatible, *if* you haven't set your user preferences. Sigh. Fixed. --CliffordAdams

You should change the ALT tag in the logo IMG tag to be alt="[Home] ", or place a space between the image and the title link. In the latter case, you should still might want to make the alt tag alt="[Home]" so it's clearer. The reason is that on LynxBrowser, the following renders as "HomeMeatballWikiBugs": 

<a href="mb.pl?MeatballWiki"><img src="/meatball.gif" alt="Home" border=0 align="right"></a><a href="mb.pl?search=MeatballWikiBugs">MeatballWikiBugs</a></H1>

Fixed in the test wiki, using alt="[Home]".

Someone created a WikiName (by typing in a URL) that begins with a slash:

http://www.ourpla.net/cgi-bin/wiki.pl?/SriLankanActivists

I moved the text to a new name. But now some people (maybe everyone who entered an e-mail in Preferences?) are receiving e-mail announcements they didn't ask for, i think when the last browser to edit the /SriLankanActivists page edits another page.

If it's a question of administrative data in the WikiDataFiles?, what and where? And are there any WikiTools available for a Unix-barely-literate user to interact with such data in the UseModWiki files? (I'll learn to use Perl on the CommandLine?, i'm asking about custom tools :-). --JohnAbbe

The pagename starting with a slash is a confirmed bug (for wikis that allow subpages). The fix should be fairly simple, but I'll want to test it. (The reason it was allowed is that the LinkPattern allows /subpagename links within the text of a page. The checks for a valid pagename need to be slightly stricter.)

As for the email feature, it is probably working as it should. The email feature does not provide subscriptions to individual pages. If someone checks the email-notify box on the edit page, everyone who has signed up with an email address will get the notification. This feature is unlikely to be usable by larger sites, although it can be helpful for small group wikis. (It is also a very low-priority feature, which was included because it was contributed by one of the users.)

For administrative tools, there is only the Unix shell. You can currently (version 0.88 and before) remove pages by removing the .db file of the same name. The data files would be difficult to manipulate with non-Perl tools because they are simply Perl key->value hashes (separated by two-character separators), and the fields are not ordered. --CliffordAdams

Mailto: images

URLs like mailto:saw_this_on_wiki_wiki_sandbox@bug.gif (escaped in nowiki) are interpreted as an image link. This often makes the user's browser start a mail program. Arguably this is a browser defect, but it is far easier to fix the wiki than the popular browsers.

My first instinct is to simply limit images to http: or ftp: URLs. People with gopher-served images will just have to suffer. Any other ideas? --CliffordAdams

Double-Double-Quotes and Wiki:SixSingleQuotes

Two double quotes are not always the same as Wiki:SixSingleQuotes.

For that matter, in the last example, the Six Single Quotes do not break up the link pattern the same way as Wiki:SixSingleQuotes). But this way (simply tossing the first word, but not the rest of the LinkPattern) may be better than Wiki:SixSingleQuotes.

The intention is not that two double quotes be silently removed everywhere they appear, as with six single quotes (which itself is really just an artifact of the markup translation). If you look at the source (or refer to the historical LinkPatternSuggestions), you'll see that they're merely used to flag the end of a link pattern (and when so used, thrown away). In cases where they don't immediately follow a link pattern, they remain in the text. That's by design. Now, whether the design is optimal can be argued. ;-)

Of course it's optimal--it works just the way I like it. :-) Scott's explanation is correct--the double-quotes are only special as a terminator. The Wiki:SixSingleQuotes behavior is not an official feature of UseModWiki--it could conceivably go away. The proper way to get the same behavior in UseModWiki is to use the nowiki tag.

For the last example given, UseModWiki does not require a "word break" (a non-alphabetic character or the beginning of the text) before a LinkPattern. For instance, consider abcLinkPattern. This could be confusing in cases like abcSampleUndefinedPage, since it isn't clear what the question-mark covers. See below for an earlier report of this non-un-misbug. If one really wants to confuse people, one could even make links like LinkPatternLinkPattern (separated by ""). Don't make links like that (or someone will fix them :-). --CliffordAdams

Preview "problems"

The Preview button on the edit page doesn't seem to be working for me. When I hit it, I just get a new edit page. Am I confused, or is this a bug? --JeffDairiki

You might need to scroll down to see the preview--it is displayed below the edit form. If you still don't see the preview, what browser are you using? --CliffordAdams

Aha!/Doh! Yes it's there. Very nice. --JeffDairiki

CategoryMeatballWiki

Discussion

MeatballWiki | RecentChanges | Random Page | Indices | Categories
Edit text of this page | View other revisions
Search: