[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
In article <831b9c3a58.fjgraute@xxxxxxxxx>,
Fred Graute <fjgraute@xxxxxxxxx> wrote:
> It's as not easy as it might seem from the outside. The code assumes
> that the size of the sorted area is exactly the same as the size of the
> unsorted original.
> The whole operation is linked closely to how undo works. In fact, if
> undo is off then the text can't be sorted.
> Also, would it be okay for StrongED to insert that newline? That is to
> change the text on its own accord? It might only be a newline but still.
I see no problem with that. There are two cases to consider
1: Where part of a line has been included in the block: This clearly is a
user error. Can it ever make sense for this to be what is wanted?
2: Where it is an end of file. Can there be a situation where adding a
couple of bytes to the end because of a sort causes a problem?
> At the moment I'm looking for a way to resolve this but coming up with a
> good solution might take a while.
We all live with the present situation: it takes a Zap user to make any
big ripples! Yes perhaps the error is a bit confusing for some, but only
on the EOF case I think.
A block (or file) to be sorted is, ipso facto, a list. It will be a
different list after sorting. How will a couple of bytes added cause any
http://StrongED.Torrens.org for StrongEDinstructions (in preparation) and mailing list archives