On 31/03/17 10:19, Rufus Laggren wrote:
> Public bug reported:
> 
> When dealing with 100k++ number of files it would GREATLY, HUGELY help
> if one could build, on the fly, a list of "preferred dirs". When
> activated (various ways possible) the "preferred dirs" feature would,
> when a "preferred dir" existed in a group, automatically select dupes
> (lines) within each group which did NOT contain the "preferred dir".
> When the "preferred dirs" feature left more than "n" line(s) unselected
> in a group (multiple files w/same "preferred dir", or multiple
> "preferred dirs" in same group) those groups would (optionally, set in
> preferences) be highlighted for easy identification for further
> selections; alternatively, groups with n unselected lines or less (see
> below), based on "preferred dirs", could be hidden or auto-collapsed
> which would leave normal groups, or those w/too many unselected lines,
> visible for normal editing. Thinking about it, the second options seems
> cleaner, less "busy", an easier interface to work with. A group could
> not be highlighted, hidden or collapsed unless it contained "preferred
> dirs".
> 
> There are probably other useful perversions of this idea possible but I
> only can visualize the above at this point. The "n" number maybe could
> be made part of processing each group and serve additional functions but
> I have not tried to evaluate that, especially not knowing the logic flow
> you use.
> 
> The preferences setting could:
> 
> 1) Enable/disable the feature.
> 
> 2) Spec n where "number of unselected lines" > n either causes
> highlighting, or disable hide/collapse for that group. Default n=1.
> 
> 3) Select highlighting, hide/collapse, or "no special display" for
> groups altered by this feature.
> 
> Usage: On the fly, when working with a group, one could rt-click on the
> _unselected_ line(s) and add the dir on that line to a "new preferred"
> list; when satisfied, the "new preferred(s" would be posted to the
> active "preferred dirs" list. (The rt-clk context menu could have the
> top choice "add single dir" and the second choice "add multiple dirs" so
> that the common(?) case where there is only one "preferred dir" would be
> quick and easy.) The new items would be active immediately in the
> current session. If no "preferred dirs had been defined yet for this
> session or if a list had not been loaded, the "add dir" click would open
> a "new list" dialog. Once defined or loaded for a session, that
> "preferrred dirs" list would be used automatically for all succeeding
> processing (dupe selection) until the "preferred dirs" context menu or
> dialog was invoked again (by rt-clicking on an unselected line). Ideally
> a config file containing this list and other options defined for this
> session could be automatically associated with a saved search and
> loaded, eg. from the "File" menu.
> 
> It would be greatly helpful if the auto-selections would be immediately
> applied. This instant clutter reduction would greatly speed and simply
> subsequent selection process resulting in a huge time savings.
> 
> Fslint is a fine, Fine tool. It's just that wading into gigabytes of
> overgrown data directories, screwed up with multiple overlapping
> restores or syncing runs over years, using slightly (or greatly)
> differing directory structures is still a really, really bad job. In the
> job I'm just completing (which inspired this post) there were 200k++
> files w/an average of 4 dupes; there were dozens in some cases but those
> are special. Unfortunately the first/last choices just didn't work at
> all for this job.
> 
> A perversion of this filter which just occurred to me would be a "must
> retain" list. It would need to be built from a gui by clicking high (or
> low) on the directory tree, though - else the build for a new job would
> probably be prohibitive for the user.
> 
> Regards
> 
> Rufus
> (sorry if there is a better place to post suggestions - didn't see it right off.)
> 
> ** Affects: fslint (Ubuntu)
>      Importance: Undecided
>          Status: New
> 
> 
> ** Tags: fslint wish
> 

This is already tracked upstream at:
https://github.com/pixelb/fslint/issues/24

cheers,
Pádraig