Tags:
create new tag
view all tags
On http://plone.org (zope), which seems high in the simplistic/looks dept. (though lacking in the power of perl, of course), is the following wiki-ism (they call it StructuredText):

wiki text rendered as
"Link with string":http://www.some.where
Link with string

You might recognize this to be similar to the square bracket wiki-ism. I think it's better:

  • there's no closing terminator. I dunno about y'all, but my most frequent wiki typo is forgetting a trailing bracket(s) when using [[http://www.some.where][Link with brackets]]

  • it separates "forced links" usage (discouraged) from "specific links" usage (encouraged). Since square brackets are discouraged for [[Links with spaces & funny characters, like this]], this is a good thing.

  • I believe it's easier to input. Though I'll leave that up to the consensus vote..

It handles the other protocols as well, I'd guess (not just http: but mailto:, https:, ftp:, etc)

They have a different syntax for #anchors, so double-square brackets are virtually removed from usage.

-- JonathanCline - 10 May 2003

Main reasons I came here were to:

  • Thank you for clarifying the Zope syntax for creating a link. I had recently been on the xwin.org wiki, based on Zope, and I gave up (rather quickly) trying to figure out how to create a link (even though I skimmed the appropriate help or text formatting pages).
  • Register a vote against removing the square bracket syntax. I don't object to your alternate as an option, but I prefer the square bracket syntax to the StudlyCaps (or whatever the approach TWiki uses is called) and I like the trailing terminators.
    • JonathanCline - 10 May 2003 responds:
      • I'm always looking for easier ways for making links. Why do you like trailing terminators? They seem like extra characters to me. I also like making wikilinks with spaces, instead of making WikiWords, so double-brackets are still useful there.

        Habit to start with, and I like wikilinks with spaces. (I would also the target page to include those spaces in the page title as well.) I also like the ending delimiter because it provides "closure" in some sense (it marks the end of what's included in the link). (One other point (as a reminder to me), I would prefer that the syntax be reversed, so my chosen link name became before the URL, because, at least most of the time for me, if I want to sort a list of links alphabetically, I prefer to do it by the link name that appears on the page rather than the URL. I do note that your approach is already arranged so that sorting would work properly. I still prefer the double square brackets. wink ) —rhk
      • the wiki in question also creates forced links with just double quotes. It specially formats text after colon-colon-plus-newline (if I wanted to show example-text:: blockquote-text). So colons and quotes have other meanings.
      • double quotes seems more natural for creating links, as follows. If I were talking about some nice music I might say I like "Dark Side Of the Moon":http://pinkfloydhyperbase.dk/albums/dark.htm Note how I entered this link: 1. Type quote, text string, unquote. 2. Control-V for paste. 3. Type next sentence. This is my normal data entry method (also explains why I forget the trailing brackets). I guess it depends on your past experiences — the double square brackets seem more natural to me. —rhk

  • At first I didn't know what you meant by "forced link", now I do and am recording a "TWiki newbie" comment (for myself): a forced link is when you use (on TWiki) the double square bracket syntax to create (force) a link to a non-WikiWord.

Then, incidentally, because I just read your question about <verbatim> tags and recognized for myself that <verbatim> tags don't (usually??) work unless they are on separate lines, and that there is an alternate way (using <nop>) to disable a double bracket square link, I made appropriate changes in your original text.

I do wish all wikis used the same markup language, or there was a universal translator built into our (everyone's) editors so that I could type the wiki markup I'm used to, and depending on which wiki I was working on, the correct markup for that wiki would be generated. Maybe next year. wink

  • the markup keeps improving as internet usage evolves. -- JonathanCline - 10 May 2003 Yes, but there will probably be differences of opinion for a long time (until a new generation comes up and the old generation dies out?) about things like our difference of opinion re double square brackets vs. the quoted link approach (above). —rhk

regards,
RandyKramer - 10 May 2003

You can use EasierExternalLinking on TWiki for external links - e.g. =[[http://www.some.where Link with brackets]]. This is a bit easier to type.

  • Yes, that is easier. Though it still has the trailing brackets. -- JonathanCline - 10 May 2003

-- RichardDonkin - 10 May 2003

Look how long it took for the automobile industry to evolve a standard set of controls - aka user interface. And there were a lot more automobile users in those first few years than there are Wiki users.

-- AntonAylward - 11 May 2003

Responded to JonathanCline's comments to my comments, marking them with —rhk

--(rhk) RandyKramer - 11 May 2003

I like double [] syntax for links: easy to type and easy to see in text, and does not collide with possible other usage. Quotes are harder to see, harder to type (shift), and does collide with the most standard usage of it for plain quoting. Violates RuleOne.

Still, I like how Jonathan questioned standard, because "text first, URL later" is also how my brain works: Important, human-readable info should be first. Rest is for computers, I'll skip over it - and please provide a character to show where to end skipping.

Maybe we could have something like [[nice text]URL]? Another idea for BetterDefaults.

  • Another thought. My rule one is different: my primary requirement is to be able to cut & paste from text(email) -> wiki, and visa versa, with as little editting as possible, and having both applications (wiki and email client) treat the text as close to each other as possible. With the trailing brackets last, another application may treat the trailing characters as part of a url, like this http://pinkfloydhyperbase.dk/albums/dark.htm]] which breaks the link. -- JonathanCline - 13 May 2003

-- PeterMasiar - 12 May 2003

Just summarizing, maybe mostly for myself:

JonathanCline makes a good point, and thus I see two motivations for potential change from the above discussion:

  • User readable text should come before URL for (my) preferred sorting order
  • Cut and paste to and from other applications should be considered; in particular, to email (the possibility of trailing "]]" being treated as part of the URL in an email).

-- RandyKramer - 13 May 2003

Something like [[text of link]]URL using a SPACE as end delimiter? [[Original Twiki]]http://twiki.org will meet most criteria, but is it intuitive enough? And using SPACE as end delimiter is not robust enough: I read somewhere on Twiki today that spaces will be allowed in page names. So we do need other delimiter, not SPACE.

  • JonathanCline - 14 May 2003 says:
    • This is a classic design fault which is common among developers (I fall into this trap myself sometimes): the bottom up approach instead of top down; that is, you're arguing against delimiters based on the inherent problems of implementing the code for their use. This is an ease-of-use discussion, so focus on that first, and figure out how it can be developed later. To counter the point above: if necessary, code can always search through a list of page names to eliminate or create links for spaced-words-which-are-page-names. Etc. Yes, there exist design tradeoffs later, but implementation must be split from user-interface design. I suppose I am approaching this from the standpoint that "excessive linking" (where twiki believes something should be a link, but the author did not intend it to be a link) is better than "unreadable linking" (where my readability/cut-paste ideal requirement is broken). If unknown links are shown with better readability (NonExistentWordMarker) then excessive linking is not a problem (anyone disagree?).
      1. Example: Yes, quotes are used a lot in normal text. I used them in the above paragraph. Is there anything wrong with those quoted-strings becoming links (even if I didn't intend them to be)? I'd say there isn't.
      2. Example: since URLs/URNs/URIs/whatevers always begin with the protocol type (by definition), no explicit seperator is required. regex can detect the link automatically, after a spaced-wiki-word is seen.
      3. Example: I learned twiki's wiki markup in about 15 mins. I can learn a completely new set just as fast. Don't stick to existing convention just because it's the ad hoc standard; stick to it because it satisfies existing and new requirements. Any necessary conversion of old-data to new-data can be automated. That means there's low risk for any necessary change.

I don't want to sound learning disabled (because I'm not, but I am getting older wink ) — I've been using TWiki for almost three years, and there are still fairly common TWiki markups that I have to look up because I don't use them often enough to remember. I perhaps learned the basics (just type in ordinary text and separate paragraphs with a blank line) in less than 15 minutes. Learning a new markup is not trivial, nor is dealing with more than one markup (like if I wanted to contribute to more than one wiki on a regular basis). -- RandyKramer - 14 May 2003

I found another clean wiki: JSPwiki. They have [[text|URL]] syntax, IIRC. Pipe | separates URL from text of the link.

-- PeterMasiar - 13 May 2003

inline comments above

-- JonathanCline - 14 May 2003

dunno how I missed this conversation earlier... I too would much prefer to write the text first and then the link. I am forever screwing things up because I trip over the http: part first. The point about the protocol (ftp://) already being a delimiter is important.

-- MattWilkie - 22 Oct 2003

The funny thing is that TWiki originally had the [[text][link]] rule, but I switched that after getting feedback that this is too confusing for people who know HTML.

-- PeterThoeny - 26 Oct 2003

Hmm, interesting point, makes your life interesting, I'm sure. wink

Anyway, I just wanted to re-register a vote for the text first for more "logical" (to the reader) sorting.

-- RandyKramer - 26 Oct 2003

The code can support both. Whichever the user enters, perl can find the scheme:// part.

In fact, the code could perform more rendering on non-bracketted links, so that http://some.where.example.com/somepath/somedoc adds a link but shows only example.com somedoc (although this would completely break cut & pasting from rendered twiki to text).

  • oooh, I like that. In cases where a body wanted to insist the url be displayed whole one could use [[http://blah]] syntax -- MattWilkie - 28 Oct 2003
-- JonathanCline - 28 Oct 2003
Edit | Attach | Watch | Print version | History: r18 < r17 < r16 < r15 < r14 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r18 - 2003-10-28 - MattWilkie
 
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2026 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.