Sort by file modified time (using the rg --sort flag)

[bs]

I tried sorting by modified time by including sort --modified in the ripgrep commands section, but this does not change the order rendered. (See this issue and commit for rg)

Use case- long list of notes (daily journal) with TODOs in them, and want to see them by most recently added!

Thanks for your work. <3

[Gruntfuggly]

I'll have a look at how easy this would be - hopefully it's just a case of not doing any sorting.

[bs]

I'll dive into the code if I get a chance over the weekend. Off the top of your head is there any reason adding sort --modified would not be respected? Does it get sorted elsewhere?

[Gruntfuggly]

Yes, the tree gets sorted when it's populated. I've already started looking at it - I think it should be possible. There may be a performance impact as it sounds like ripgrep has to go into threaded mode to sort it's results. I guess it will depend on the size of your workspace.

[Gruntfuggly]

Got it working - I've added a preference to turn off sorting in the extension. Then it will use whatever order ripgrep returns it's results in.

[Gruntfuggly]

Hmm - found an issue. Because the tree is also updated with open files, you'll need to set some other configuration options, otherwise the tree behaves oddly when files are already open or selected in the editor.

I'm going to have to have a think...

[bs]

Thanks for looking into it. Agreed that there will be a performance cost as it goes single threaded. Not terrible, though. On my workspace of >500 files it's practically identical.

Is the issue when it you use the view 'scan open files'? How did you work around when sorting alphabetically?

[Gruntfuggly]

OK - I've published a new version which supports sorting via ripgrep. I've also added a new scan more (scan workspace only) which may be useful if you find the tree is unstable when changing files. You may also want to disable auto-refresh.

Let me know how you get on with it.

[Gruntfuggly]

I've just published a new version with timestamps in the debug logging. Please let me know if it reveals anything.

[bs]

OK, been playing with this this morning!

I've found the magic incantation of settings to get close to the behavior! 😅

        "todo-tree.tree.sort": false,
        "todo-tree.tree.scanMode": "workspace only",
        "todo-tree.tree.autoRefresh": false,

If scanMode is set to workspace, it seems like some additional sorting is happening that is not completely transparent. (I'm assuming this is with open files.)

Notably, both autoRefresh and fileWatcher do not update the tree once a file has been modified. Is this because they call out to your internal sort and do not execute rg again? Apologies for not being able to dive into the code right now and look for myself!

A few other questions:

• What does stable mean? That the tree is up-to-date?
• What is the difference between auto-refresh and using the file-watcher

Thanks for this fix!

[Gruntfuggly]

When I say stable, I just mean that the tree nodes stay in the same place. So when I had auto-refresh turned on and was showing the tags only view, every time I changed file in the editor, the tree would refresh differently, due to refreshing the open files. That was the reason for adding the 'workspace only' option.

When it's set to 'workspace', it refreshes the open files and scans the workspace. That means that if you move TODO's around in an open file, they're updated appropriately. The problem is how you would add TODO's to the tree for open files and from the workspace at the same time, if you're sorting on modification time.

Auto-refresh basically causes the tree to be updated when you modify open editors (as above). The file-watcher will cause the tree to be updated even when the a file is changed which is not open in vscode. To be honest, the use case for the file-watcher is very specific. I don't really believe it's that useful unless someone is using an external tool to modify files somehow.

[bs]

When I say stable, I just mean that the tree nodes stay in the same place. So when I had auto-refresh turned on and was showing the tags only view, every time I changed file in the editor, the tree would refresh differently, due to refreshing the open files. That was the reason for adding the 'workspace only' option.

When it's set to 'workspace', it refreshes the open files and scans the workspace. That means that if you move TODO's around in an open file, they're updated appropriately. The problem is how you would add TODO's to the tree for open files and from the workspace at the same time, if you're sorting on modification time.

Got it. I wonder if there shouldn't be a sort dropdown that includes name and modified and sets the other flags as necessary. It seems like sorting + open files is not clearly delineated in the UI?

Auto-refresh basically causes the tree to be updated when you modify open editors (as above). The file-watcher will cause the tree to be updated even when the a file is changed which is not open in vscode. To be honest, the use case for the file-watcher is very specific. I don't really believe it's that useful unless someone is using an external tool to modify files somehow.

This wasn't working for me, when sorting. Turning either of these on did not obey rg's responses. I would only see rg's sort'd results when I manually refreshed.

Wouldn't file-watcher be a superset of auto-refresh's functionally and the latter could be removed?

[Gruntfuggly]

Sorry for the delay in responding to this.

The file-watcher would be a heavy handed and lazy way to refresh the files when they are updated. An event is generated when a file is saved so it's much simpler to refresh just that file at that point.

Is there anything outstanding in this issue now ? Sorry it's been a long time since I looked at it and I'm trying to do some housekeeping on open issues. If not, do you mind if I close this now?

[bs]

Hey! Just coming back to this on my end as well. It seems like it's still not sorting by modified date. Did something break?

[Gruntfuggly]

I thought it was working at one point? There have been a few releases since October, so if you have time you could try older versions and see if you can find one that works. Let me know if you do as I'll be able to work out what changed.

I've got a whole bunch of changes in the pipeline, including an overhaul of sorting so I'll make sure it's working for the next release.

[Gruntfuggly]

I've just uploaded v0.0.197 which simplifies the sorting.

It should sort by modified date now, although you need to use --sortr=modified to put the most recent at the top.

It makes most sense in the tags only or flat views. With the tree view it will sort by modified within each folder.

[bs]

Works perfectly! Thank you!

Now if I could only dig into the contents via some awk - sed - sort foo 😈

[Gruntfuggly]

How do you mean?

The new version also includes a new todo-tree.regex.subTagRegex setting which allows you to extract further information from the right of the tag for grouping and highlighting. Maybe that will help? 🙂

Are you OK for me to close this issue now?

[bs]

Totally good to close!

I'm just thinking about how to sort todos based on the modified date inside their frontmatter. I will play with subTagRegex and see if that satisfies!