[Lispweb] CLiki fixes

Francois-Rene Rideau fare at tunes.org
Sat May 22 08:09:24 CDT 2004

On Thu, May 20, 2004 at 11:45:24PM +0100, Daniel Barlow wrote:
> Nice try, but to be honest it's about 5% as useful as an ordinary
> unified diff would have been
OK. I actually tried that at a time when CVS was down,
and I was trying to adapt my code between multiple tarballs of CLiki.
Working with a modified tree and using diff was just not an option.
Then again, I've gotten interested in this approach to incremental development:
with incremental changes. I admit my increments might not be well fit for you,
but it's only by lack of positive interaction with you.

> now I have to trace through each
> function in its entirety comparing to the upstream version, to decide
> whether it's (a) unchanged, (b) bugfix, (c) needed only for a new
> feature that I may or may not want, or would probably want to
> implement differently if I did (e.g. the _(foo|bar) stuff)
It's always changed, and there's always a note telling from which version,
and a FIXED: note as to what was fixed.
If you're interested in the difference between (b) and (c),
I'll make it explicit.

>> 1- indexing of backlinks and topic contents now works correctly
>>  (hasn't worked for a long time, if it ever worked correctly)
> This would be a very welcome feature if it can be disentangled from
> the rest
It probably can, though it concerns many files.

>> 2- _(label|link) and _(label|http://url) style of links,
>>  (it's now well supported including for indexing of backlinks)
> I'm still unsure about this.  label|cliki_page ok, but overloading it
> to deal with URLs as well seems like storing up trouble.  Call me
> over-cautious
(1) It opens the way for things like automatic verification of MIA links
(2) There's a boolean flag that clearly distinguishes the two
(3) It opens the way for things like inter-cliki links, with a cliki object
 instead of a boolean flag as the distinction mark.

>> 3- can view source for older revisions by clicking
>>  (makes it easier to salvage old data from e.g. vandalism)
> Sounds good.  Note that this should just be a change to the page
> template: the underlying functionality is there already (e.g.  see
> http://www.cliki.net/CLiki%20Sandbox?source&v=2)
It is just such a change indeed.

>> 4- better consistency checking at initialization time
>>  (only for administrators who edit titles files or have truly old clikis)
> I'm actually quite pleased to hear that editing the titles files works
> at all, as I've never run a cliki that used them.
I didn't use them. But apparently there were upper/lower case aliases
in CTO, maybe dating back from times when Cliki would have been case sensitive.

>> 5- Cleanups and packaging for developers, so you can embrace and extend CTO
>>  (instead of a klugy fork from old versions of araneida and cliki)
> I'm not sure what's meant by this item, unless it's the changes to
> cliki-page-header and cliki-page-footer to e.g. break the disclaimer
That, plus my merge of html and html-stream, plus bad typography
(lacking ending stop marks), bad html, an html table issue, etc.

> 1) cliki-page-header and cliki-page-footer are _deprecated_.
Yes, but they are here, and I'm not the one who'll replace them.
I'm not doing any structural change that I'm sure you'd reject as well,
so I'm changing as little as possible.

> Use
> cliki-page-surround instead (or even better, produce a feature similar
> to cliki-page-surround that doesn't require the magic CLIKI::OUT
> variable)
I have nothing against such variable, except that it could have a magic name.

> 2) in any case, a global variable is not much good if you're running
> more than 1 cliki in the same lisp image 
Indeed, it could be made an object field of fancy-cliki.
But I didn't want to unnecessarily extend the cliki-instance class.

Once again, the goal of my patch was to cleanup while making as little
structural changes to the original, considering that I can't know which
structural changes you'd approve.

I understand your concerns, and I'm ready to make my patch easier for you
to digest, but only if my efforts could actually make it digestable.

> please don't plan on the expectation
> that it'll be merged into the upstream cliki unchanged.
I don't plan on it. But if it could be merged while changed, it's great.

[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
[  TUNES project for a Free Reflective Computing System  | http://tunes.org  ]
Clothes make the man.  Naked people have little or no influence on society.
		-- Mark Twain

More information about the lispweb mailing list