Tony Mechelynck wrote:
> After applying the recent patches (up to 7.4.960) I notice a
> duplication in the help, as follows (eval.txt lines 5818 to 5828):
>
>
> The sort is stable, items which compare equal (as number or as
> string) will keep their relative position. E.g.,
After applying the recent patches (up to 7.4.960) I notice a
duplication in the help, as follows (eval.txt lines 5818 to 5828):
The sort is stable, items which compare equal (as number or as
string) will keep their relative position. E.g., when sorting
on numbers, text
Hello,
I'm not sure whether sort() can be applied with 'n' parameter on lists of
strings that encode numbers.
Right now (v7.4-908) the result produced is: ['1', '5', '48', '25', '5', '28',
'6'] which is really odd.
Is this a vim bug, or an undefined behaviour?
Regards,
--
Luc Hermitte
--
Hi Jürgen,
- Mail original -
> > [...]
> > Is this a vim bug, or an undefined behaviour?
>
> see the fifth paragraph of ":help sort()". Note that Strings are
> explicitly mentioned "to be considered as being 0". Also read the
> second to last paragraph which explains why the order of the
Hi,
Luc Hermitte schrieb am 03.12.2015 um 14:52:
>
> I'm not sure whether sort() can be applied with 'n' parameter on lists of
> strings that encode numbers.
>
> Right now (v7.4-908) the result produced is: ['1', '5', '48', '25', '5',
> '28', '6'] which is really odd.
>
> Is this a vim bug,
Luc Hermitte wrote:
> I'm not sure whether sort() can be applied with 'n' parameter on lists of
> strings that encode numbers.
>
> Right now (v7.4-908) the result produced is: ['1', '5', '48', '25', '5',
> '28', '6'] which is really odd.
>
> Is this a vim bug, or an undefined behaviour?
As
