Bijan, I don't need tables, list or whatever else. Just text (well mostly, a few images here and there would be nice). Perhaps I should say a bit about the situation in which I _really_ want something like this: I work within many images at the same time (usually no less than four or five, all parts of different projects) but there are quite a number of thoughts and writeups that _should_ be cross-linked between them. So, right now, I'm having all these workspaces hanging around in the individual images and whenever I want to look up something I need to find the right image and the right workspace.
The alternative is to use a Swiki for this kind of information (and Swikis are just about perfect for this). But then, there's this problem that I have no (S)wiki running all the time (I'm doing tons of experimental stuff and I don't like having a web-server affect my machine in any way). So that's why I was asking about editing Swiki pages locally. But even if I would have a swiki running I would still have this "edit, compile, run" cycle - which (for obvious reason) I am not very fond of. So what I really want is to take a workspace and just type in the text, perhaps add a bit of emphasis, make the font size right etc. Then I want to say "save on swiki" and the system should just take what's there, translate it into the right format and store it in the Swiki. Even if the formatting would go wrong I wouldn't really care because most of these bits of information are thoughts where the words are much more important than any emphasis. However, the ability to cross-link information _is_ critical, and yes, I'd be willing to work on those UI aspects. Cheers, - Andreas > I meant that the more HTML features you support, the more > interface work you have to do. > > For example, if you want to support tables, that is authoring > tables, you have to come up with a UI for it (e.g., like Word's or > Dreamweaver). That's a lot more work than supporting just the > classic Wiki markup (and I mean "support WYSIWIGiclly). > > > So there ain't no stinkin' HTML as far > > as I am concerned. Only text. > > Text a la MacWrite, text a la Word 6, or text a la WikiText? > > > Or - in Squeak terms - only instances of > > Text. > > Instances of text can contain HTML :) > > > > And even that isn't tough if you don't have people adding > > > arbitrary HTML from the "edit mode" interface. > > > > So what?! Scamper can render these pages, can it?! > > Not well, yet, all of it. > > > So all it needs is to > > provide me that page of text, then allow me to edit it > wysiwig-style and > > post it back to the Swiki. > > That's the tricky bit. Well, not tricky. Just needs to be done. I was > working toward that in my SqueakNews series. > > For example, there is, as yet, no good Squeak UI for editing > lists. It's > *easier* (for me) to write the HTML (and even easier to use a Wiki > syntax). > > Supporting a subset that matches existing capability is easier than > supporting the whole shebang where you have to come up with the UI, > etc. for it. That's *all* I'm saying. > > > > > Anyone ever thought about this?! > > > > > > Indeed. For PWS swiki I had an in squeak swiki editor that used > > > SwikiSyntax (i.e., an edit mode). Worked great. > > > > Well, again, I don't want no "syntax". I'm writing text and > text has no > > syntax other than implied by the language. > > Hmm. Fine. > > One key difference between Wikis and Swikis is that Wikis > support a fixed > subset of markup whereas swikis generally include arbitary HTML in a > variety of ways. A general WYSIWIG HTML editor is a > substantially larger > project than a WYSIWIKI editor. that's *all* I'm saying. > > But far be it from me to discourage the creation of a full > WYSIWIG HTML > editor! > > Note that Scamper really only takes you part of the way, > notably punting > on tables and frames. > > (There is a T-Gen grammar for HTML4.0 floating about, perhaps > on a Heeg > wiki?) > > Cheers, > Bijan Parsia. >
