Re^3: The ability to delete (self reap)

That'd be less ugly than an empty node or even one full of long stretches of ~~strike~~d text...

It wouldn't make the node owned by the NodeReaper, which leads to questions like unreaping and exclusion from searches, etc.

On the other hand, it is uglier than a node with a mature update that is more informative and customized to the specific circumstances.

On the gripping hand, I don't foresee such getting implemented anyway. So I'm not going try to hash out more details of the design. (I prefer the previously identified route of getting preview for updates and then edit histories).

- tye

Comment on Re^3: The ability to delete (self reap)

Replies are listed 'Best First'.
Re^4: The ability to delete (self reap) by McDarren (Abbot) on Oct 26, 2005 at 02:48 UTC
(I prefer the previously identified route of getting preview for updates and then edit histories). I'm curious about this.... I certainly appreciate having the preview button available when creating a node, and I miss it when when updating. I tried a [id://Super Search] on "previewing updates" which turned up nothing. Is there a separate discussion on this elsewhere, or plans to implement it?	[reply]
Re^5: The ability to delete (update preview) by tye (Sage) on Oct 26, 2005 at 04:05 UTC
Sorry, I don't have a ready pointer to a node on this subject nor a good lead on a quick way to find one. One reason for preview is to reduce the number of changes that get logged. I suspect that additional tricks will be required to reduce the resource requirements for logging changes to a reasonable level, though. We already have previews (and change logging) for other types of updates. - tye	[reply]


Don't ask to ask, just ask
	PerlMonks