This means that I get the order:

WebTopicList
Weblogs

AC

try this:

Index: Store.pm
===================================================================
--- Store.pm    (revision 11101)
+++ Store.pm    (working copy)
@@ -1544,7 +1544,7 @@
     $web =~ s#\.#/#go;

     my $handler = $this->_getHandler( $web );
-    return $handler->getTopicNames();
+    return sort { lc $a cmp lc $b } $handler->getTopicNames();
 }

 =pod

WN

---

This would be preferable, but would it have a large inpact on performance?

AC

Looking at the code I see that handler getTopicNames is called from a lot of places where order does not really matter. So sorting the list in these cases will be overkill.

That would plead for using sort in TWiki.pm: TWiki:_TOPICLIST only.

But there is also Func:getTopicList. Would it be useful to have an optional sort parameter?

-- AC

I would be very careful, add no-case sorting only if performance is not impacted. Better to test with many topics in a web, such as 10K topics.

-- PTh

I read from this that the sort parameter would be useful. With a note about inpact on performance.

AC

I do not feel strongly one way or the other of case insensitive sort (assuming the performance is OK.)

-- PTh

Note that sorting case-insensitive will result in variable random orders, as 'ThisTopic', 'ThistopIC' and 'THISToPic' will all be treated as equivalent and will end up in an unpredictable order relative to eachother.

I recommend that this be discarded.

CC

---

I want to avoid perceived randomness. To a user who is not a programmer it will not be obvious that Weblogs will be below (often out of sight) WebTopicList. And in Crawford's example the topics will at least be listed in each other's neighbourhood, which I prefer to the current situation.

-- AC

I think the case-insensitive is best too. People are not programmers in general so they do not understand that A and a are far apart in the alphabet.

But before anyone jumps and implements anything, measure performance first. We should not just change and add a note about a possible performance hit. We should try it and measure and then decide. If the performance drops significantly then it is not worth it

KJL

I really can't see this as "Normal" priority, compared to other issues at that priority, so regrading to "Low".

CC

One thing to try is to configure I18N with a locale such as en_US.ISO-8859-1 - you may find it does case insensitive sorting automatically, though you would also require a one-line fix from Item3680.

RD

The sort order is well established now, and since unicode support is inherent it isn't going to change.

-- Main.CrawfordCurrie - 25 Jun 2015 - 06:15