Mon, 27 May 2002 11:53:26 -0700 (PDT)
On Mon, 27 May 2002, Tim Rowledge wrote:
> How about (h1: [question]) ?
Hmm, that's an interesting one. The rule being, appending a colon to a
tag name means the entire contents should be treated as text? So, for
(p: This is a test).
I don't hate it. What about when the tag has attributes?
(p: align: right This is a test) looks a little funny. There's also a
problem if the first word of your text ends with a colon, since it will be
treated as an attribute. So maybe that means that (p: align: right This
is a text) should be taken as (p 'align: right This is a test')?
> One thing I'd like to see attempted is a decent integration of
> _whatever_ syntax is used with the normal tools (or some decent
> alternative tools I suppose) for finding references. A major pain with
> ComSwiki is the complete inability to meaningfully track down senders
> and implementors, even with the swikibrowser.
Using the sexpr syntax definitely helps with this. A couple of things
that might improve it:
- use/allow spaces instead of dots in paths. Tim probably likes this one
anyway. And then,
- allow a similar trick for attributes as the above for contents, giving
(input type: text sea:id: (item name)) instead of
(input type: text sea:id: 'item.name')
I'm more comfortable with this change, in fact, than I am with the other
one, because it's always clear what's an attribute value and what's not
just because of its position. As for spaces vs. dots, I kinda like the
dot notation expressly because it doesn't look like message sends, and so
it's less confusing when it doesn't act exactly the same way. But I
definitely see the advantages of letting 'find senders' do its job.