-pagesInNs not working as expected in "-tree" mode

[Trinity503]

I use this to create a tree:
<nspages .:imrs-wiki -tree -r -exclude -subns -pagesInNs -h1 -textNs="">

With -pagesInNs it should sort pages and namespaces alphabetically, or am I wrong. Unfortunatetly it first lists the namespaces and then the pages.

[fiwswe]

The documentation says nothing about sorting for -pagesInNs . Why would you expect that?

Maybe you should try -naturalOrder or one of the other sort options?

[gturri]

I'm afraid I wrote the code for this option years ago and I don't personnally use it, so I don't remember how it's supposed to work...

However I just ran the test displayed in the screenshot above, and it gives me the feeling that the pages and namespaces are sorted alphabetically, doesn't it?
(for instance the page test appear between the subnamespaces subns and toto).

Do you observe something different on your side?

[gturri]

Re-reading your message I see that you use -tree, so my screenshot above is perhaps not relevant to your use case. Here is a screenshot of what I have with both -tree and -pagesInNs.

Here I see that, as expected with the -tree option, pages are displayed as leaves and subnamespaces are displayed as inner nodes.

Does that make sense? Do you observe something different on your side?

[Trinity503]

Thanks gturri for your fast answer!
Without the "-tree" option your screenshot shows the result I would expect. The pages are - as the documentation says - "among" (in between) the namespaces.
But with the "-tree" option the pages are listed not "in between" the namespaces but "after" the namespaces. I would expect the following:

00-index
abc
page_2
page_3
sub
  test
subns
  a
  test
test
toto
  tata
....

Now the pages are alpahetically "in between" the namespaces. Your Sceenshot shows "Windows Explorer"-like sorting and I would expect macos-finder-sorting :-)
Other sorting options did not work.
Long fix: Change code.
Easy fix: Change the docu.

Thanks for your great plugin!

[popjelev]

Sorry to nudge in but can you please show us what's macOS finder sorting would be like?
I've read the whole posts few times and still can't figure what should be the end result :(

[Trinity503]

Windows Explorer (standard setting: grouped folders and files):

a_folder
b_folder
z_folder
a_file
b_file
z_file

Finder (standard setting: alphabetical):

a_folder
a_file
b_folder
b_file
z_folder
z_file

So, at the moment it looks like this (subs of namespaces not included in this example):

a_namespace
b_namespace
z_namespace
a_page
b_page
z_page

And as the documentation says "pages among (in between) namespaces, I would expect this (subs of namespaces not included in this example):

a_namespace
a_page
b_namespace
b_page
z_namespace
z_page

[popjelev]

This is strange. I'm currently testing with your initial query <nspages .:imrs-wiki -tree -r -exclude -subns -pagesInNs -h1 -textNs=""> and I find that I get namespaces like Finder sorting. What version of the plugin you use and what version of DokuWiki?

[gturri]

When I look at the code I'm afraid @Trinity503 is correct: The PrinterTree::_printTree method (https://github.com/gturri/nspages/blob/master/printers/printerTree.php#L160 ) does this:

        foreach($tree->children as $subTree){
            $this->_printSubTree($subTree, 1);
        }

         foreach($tree->pages as $page){
             $this->_printElement($page, 1);
       }

and the comment at the bottom of the file (https://github.com/gturri/nspages/blob/master/printers/printerTree.php#L206 ) makes it clear that $tree->children represent sub-subnamespaces.
So, for a given subnamespace, we indeed print its pages at after the sub-subnamespaces.

[gturri]

I guess it could be possible to propose the other behavior. If we want to do that I think we should:

• add a new flag for the plugin (in order to not change the behavior for existing users who are happy with the current way it works)
• do the sort directly in the PrinterTree::_printTree method by merging the arrays $children and $pages and sorting this array... by passing it to $this->_sorter->sort I think.
  (I guess in this case we would not need to call _orderTree on L22 (https://github.com/gturri/nspages/blob/master/printers/printerTree.php#L22 ) then)

For the record @Trinity503 , on a scale from 1 to 10 where 10 is "you really want this feature" and 1 is "you were surprised by this behavior but do not really care", how much would you appreciate this feature? :D

[Trinity503]

DokuWiki: Release 2023-04-04a "Jack Jackrum"
nspages: 2023-07-11 (gturri-nspages-8e7a7fc)

gturri just agreed with me about the sorting. Thank you, I already thought, I'm crazy.

This is what I am seeing:

This is what I would expect:

As you can see in the first picture "adam" is listed as namespace with a link to that page and also as a page with a link to that page (this is the same in the next picture without tree):

Is there any way to avoid this?

[popjelev]

Now I've got it with this example :D

[Trinity503]

I guess it could be possible to propose the other behavior. If we want to do that I think we should:

• add a new flag for the plugin (in order to not change the behavior for existing users who are happy with the current way it works)
• do the sort directly in the PrinterTree::_printTree method by merging the arrays $children and $pages and sorting this array... by passing it to $this->_sorter->sort I think.
  (I guess in this case we would not need to call _orderTree on L22 (https://github.com/gturri/nspages/blob/master/printers/printerTree.php#L22 ) then)

For the record @Trinity503 , on a scale from 1 to 10 where 10 is "you really want this feature" and 1 is "you were surprised by this behavior but do not really care", how much would you appreciate this feature? :D

Well the thing with the "double" entries is a 10 for me. The other one is a 6, which means, I would have to try to do this on my own with my limited programming skills.

[gturri]

I agree that the double entry behavior is not great.
I think it's a bit related to what dokuwiki consider to be namespace. In a nutshell: I think your page "adam" has id adam, but if you move it to adam:start then nspages will not make it appear as a page node (and dokuwiki will in both case consider that it is a namespace). I think this behavior is the same as the one described on #142 and #128 .
That reminds me that part of #140 is supposed to fix this behavior, but I'm afraid I never really had time to look thoroughly at this PR