@codebrainz too

@Kugel thanks for making a testable version of #259, reviewed but unfortunately I can't test ATM, maybe someone else will test in the meantime.

@Kugel sorry, I meant @kugel- but your user comes up first on the autocomplete, and hey us humans make mistakes.

all open files are tree'ified. Its just that once a project is open it is ensured that its base path gets its own tree node (labeled after the project)

Oh, ok, thats sort of unexpected, so it needs to be explained more clearly (if only so we can close issues and point people to the manual that says thats how its meant to work :)

@kugel- yep, will propose something as soon as I'm happy I understand :)

But on looking at the above example again.

No, all open files are tree'ified.

But in your additional example you have shown foo/dev_build as not being expanded the way foo/src is?

But in your additional example you have shown foo/dev_build as not being expanded the way foo/src is?

foo/dev_build is one tree node because no file in foo itself is open. foo->src is two tree nodes because foo represents the project (therefore always gets its own top-level node) and src is a subdirectory (with an open file).

Might be easier if you just try the patch and see yourself, Github/mail kind of sucks for showing examples.

Might be easier if you just try the patch and see yourself, Github/mail kind of sucks for showing examples.

Two things:

1. I said above I can't try it ATM

2. guessing how its meant to work from experiments is a poor way of getting an explanation for users

@elextr do you need more information on how it's supposed to work?

Yes, above I said:

But on looking at the above example again.

No, all open files are tree'ified.

But in your additional example you have shown foo/dev_build as not being expanded the way foo/src is?

I had previously asked if only the project tree was expanded and you said no as quoted above, so to be clear the question is, if "all open files are treeified" then why isn't foo/dev_build expanded but foo/src is expanded?

This proves that I'm not good at documenting such things for end users :-)

There is additional confusion since your example has two foo folders and the project is named foo as well. I'll rename to illustrate:

/data -- the raid array mount point
    foo
        bar -- the git tree and the project base dir in baz.geany
             src
                 xx.cpp
                 lots more source
        baz.geany -- project name renamed from foo to baz
        dev_build -- out of tree build dir
              foo -- the executable
              test_output -- unit test output file
              lots more stuff the build makes

So accordingly, in your next example foo/src becomes bar/src.

If xx.cpp and test_output are open, then it's displayed as follows:

baz
  src
    xx.cpp
/data/foo/dev_build
  test_output

This is because of the following rules:

• The directory of a filename is folded as much as possible
• if two or more documents have common parents, then a tree is formed at that parent (repeat for any common parent encountered)
• If a project is open, then the project's base path will get a separate tree node at the root (labeled after the project). This happens regardless of whether parts of the project base path has common parents with open documents outside of the project. Folding of subdirectories (below the project base path) is performed if possible.

Compare to the situation when there is no project open:

/data/foo
  bar/src
    xx.cpp
  dev_build
    test_output

This proves that I'm not good at documenting such things for end users :-)

Thats ok, thats why I'm asking all these annoying questions :-)

I think the confusion is that I understood that the difference between this option and the existing option was that all directories on the path to open files expanded, but in fact they only expand if more than one thing inside them is open.

To confirm by example, if my project src directory had three sub-directories front_end, middle_end and back_end then if only a file was open in front_end the result for the project tree would be:

baz
    src/front_end
        xxx.cpp

but if I had a file open in each of front_end and back_end the result would be:

baz
    src
        back_end
            yyy.cpp
        front_end
            xxx.cpp

with back_end and front_end sorted and middle_end not showing.

Correct

@kugel- I still can't do anything with github, so I have posted my suggested text below.

Document list views
^^^^^^^^^^^^^^^^^^^

There are three different ways to display documents on the sidebar if *Show
documents list* is active. To switch between views press the right mouse button
on documents list and select one of those radio buttons:

Documents Only
    Show only file names of open documents in sorted order.

    .. image:: ./images/sidebar_documents_only.png

Show Paths
    Show open documents as a two-level tree in which first level is the paths
    of directories containing open files and the second level is the file names of 
    the documents open in that path.  All documents with the same path are grouped 
    together under the same first level item.  Paths are in sorted order and 
    documents are sorted within each group.

    .. image:: ./images/sidebar_show_paths.png

Show Tree
    Show paths as above, but as a multiple level partial tree.  The tree is only 
    expanded at positions where two or more directory paths to open documents 
    share the same prefix.  The common prefix is shown as a parent level, and 
    the remainer of those paths are shown as child levels.  This applies 
    recursively down the paths making a tree to the file names of open documents, 
    which are grouped in sorted order as an additional level below the last path 
    segment.
    
    For convenience two common file locations are handled specifically, open 
    files below the users home directory, and open files below an open project 
    base path.  Each of these is moved to its own top level tree instead of 
    being in place in the normal tree.  The top level of these trees are each 
    labelled differently.  For the home directory tree the path of the home 
    directory is shown as ``~``, and for the project tree the path to the project
    base path is shown simply as the project name.

    .. image:: ./images/sidebar_show_tree.png

In all cases paths and file names that do not fit in the width available are ellipsised.

Works for me, thanks.

I get the following warning when building the manual:

[WARNING] image.py:463 image /home/kugel/dev/geany.git/doc/./images/sidebar_documents_only.png is too tall for the frame, rescaling
[WARNING] image.py:463 image /home/kugel/dev/geany.git/doc/./images/sidebar_documents_only.png is too tall for the frame, rescaling

In the generated pdf sidebar_documents_only.png appears very small. The HTML manual is fine though. Does anyone know what to do about it?

@elextr Actually, the home directory is merely abbreviated (using ~), it doesn't get an individual root node unlike the project base path. See the doc/sidebar_show_tree.png

@kugel-, erm, ok, what happens if there are two directories open along the path to ~ eg if HOME is /file_server/home/this_user and I have the files /file_server/home/this_user/my_file.cpp, /file_server/home/this_user/a_dir/also_mine.cpp and /file_servert/home/another_user/their_file.cpp open?

~
    a_dir
        also_mine.cpp
    my_file.cpp
/file_server/home/another_user
    their_file.cpp

or

/file_server/home
    ~
        a_dir
            also_mine.cpp
        my_file.cpp
    another_user
        their_file.cpp

or no ~

/file_server/home
    this_user
        a_dir
            also_mine.cpp
        my_file.cpp
    another_user
        their_file.cpp

changed which @kugel- :)

I think the second. However, upon trying I found there is a crash (but only when there are open files of another user AND a file located in ~ itself). I'll dig into it.

On a side note, having a file of another user open seems unlikely, as Geany is a poor program for pair programming :-)

@kugel- various daemons and databases run under other users and have their config files in that home dir as another use-case. But even if we can't think of a use-case, if its at all possible, somebody will do it 😄

I amended the commit message of 7552d5f due to typos. There are no code changes, except the three new commits on top of @elextr change.

@elextr Upon looking at the code handling the home directory, I think the intention was to match your first case, and it was a bit buggy. Since I think this is the most useful behavior, so I fixed the code to match that behavior.

@elextr is your approval still valid even after my changes? I'd like to merge this finally.

@b4n @elextr @eht16 please review. Without any further feedback I'll probably go ahead and merge in a week or so

@kugel- sorry, I totally lost track of this PR. Tested, some observations below, not sure if they are deliberate? But they were surprising, appeared inconsistent, and in at least one case annoying.

Initial layout:

V /data/nexciidoc/attic
    old_spec.edoc
V ~/tmpgeany/geany
    V data
        geany-3.0.css
    V src
        document.c
        > tagmanager

The V means unrolled, and > folded up, there is a file open in tagmanager but I folded it up.

Note the path starting with ~ sorts after /data which is correct because ~ is second last ASCII character

Opened ~/atest.edoc got:

V ~
    atest.edoc
    V /tmpgeany/geany
        V data
            geany-3.0.css
    V src
        document.c
        > tagmanager
V /data/nexciidoc/attic
    old_spec.edoc

Note the resorting of /data when ~ became a top level, but the previous top level path still started with ~ and sorted after /data.

When I closed ~/atest.edoc:

V ~
    V /tmpgeany/geany
        V data
            geany-3.0.css
        V src
            document.c
            > tagmanager
V /data/nexciidoc/attic
    old_spec.edoc

The ~ stayed separated even though it now had only one entry open.

When I closed geany-3.0.css:

I expected:

V ~
    V /tmpgeany/geany/src
        document.c
        > tagmanager
V /data/nexciidoc/attic
    old_spec.edoc

but got:

V ~
    > /tmpgeany/geany/src
V /data/nexciidoc/attic
    old_spec.edoc

Note /tmpgeany/geany/src folded uncommanded, that would get annoying if it kept happening.

Also ~ still doesn't recombine, but when I closed and reopened Geany it combined and sorted after /data which opened folded up even though it was unfolded, and tagmanager which was folded opened unfolded. I am not sure if you tried to save the fold state across Geany close, but its not right ATM.

Thanks, I'll check. It's quite hard to get GTK to do what you want. Remembering fold state is not supported by GTK directly so I have to code around it, basically using a hammer so long until it fits.

Do you have comments aside the fold state memory?

Do you have comments aside the fold state memory?

The resorting of ~ when it became a standalone level

Sorting weirdness seems to be caused by g_utf8_collate_key_for_filename() simply ignoring ~. However, I an acceptable workaround (tread ~ as . for sorting). Now I'm looking why nodes below ~ aren't merged back properly.

Sorting weirdness seems to be caused by g_utf8_collate_key_for_filename() simply ignoring ~.

Makes sense, it probably is intended to work on absolute filenames, or at least filenames with the same root (ie directory).

Now I'm looking why nodes below ~ aren't merged back properly.

Getting ordering and merging stable will probably make saved fold state work a lot easier.

@elextr I think I got this right now. Please check.

LGTM now! Thanks.

Great, thanks! I'll merge in a few days then. @elextr do you plan more tests and/or review or are you fine with this now as well?

@kugel- Intending to test this weekend.

@kugel- its better, ~ handling seems more correct, successfully recombines ~ and child when reduced from two children to one.

But folding saving doesn't seem to be right yet.

Initial state

v ~
  v old_geany/geany/src
    document.c
  > rpggeany/geany/src  // note this is folded
v /data/misc
  parser.cpp

close and re-open Geany gives

> ~                // now whole of ~ is folded
v /data/misc
  parser.cpp

set back to same initial state and close and re-open, Geany opens with everything unfolded and from then on always seemed to re-open with everything unfolded, no matter what I did.

Thanks for testing. I'll check.

Just leaving the note here that folding state is not stored to disk anywhere so re-opening Geany begins anew.

Just leaving the note here that folding state is not stored to disk anywhere so re-opening Geany begins anew.

Ok, so opening all unfolded is fine then, so the only issue is the ~ opening folded one time. Since it didn't repeat the few times I tried maybe its an uninitialised variable that is mostly the correct value, but occasionally bad.

I made a minor change that should fix startup (the expectation is that everything is unfolded on startup). Please check again. I couldn't reproduce your second example even without the last correction.

Ok, now seems consistent, can't cause any bad behaviour, always opens unfolded, ~ coalescing seems to work. :-)

To be explicit, looks ok to merge.

I could reproduce the your second example (all under ~ starts up folded). Depends on the order on which documents are opened. I could fix that with another minor tweak.

So if nothing comes up last minute I will merge by the weekend or so.

Depends on the order on which documents are opened. I could fix that with another minor tweak.

Would have been useful to detail the reproducer for testers.

Anyway I found an order that reliably reproduced the problem and your latest push seems to fix it.

So if nothing comes up last minute I will merge by the weekend or so.

As I have said before, its important to allow a whole weekend before merging, I just happened to have time today, but many people only have weekends to try anything.

Merging after CI is done. The last push was just a squash of the fixup (as well as splitting the unit test commit into two). No diff to the previous state.