I'm not set on TermiFind, so discussion for a better name can happen here.

• Many of the new() functions can be broken up into smaller functions, these can be cleaned up by calling non-self functions and these new functions should be directly below the new() function.
• Some of the sub-functions of print_path(), such as update_start_and_end_iteration_tuple() are too long and need to be broken up

Look for the // REFACTOR comments

The only code left now to make generic would be the get_average() function, since the rest has been moved out into https://crates.io/crates/outliers.

Keeping dependencies counts down is good. Termion can do the same thing term_size can and more, if it is to be used for screen clearing, it should be used for getting terminal dimensions and term_size should be removed.

Instead of TruncationOptions holding an enum value for None, just wrap the enum in an Option and then allow it to be None. Remove the None option from it after.

Some function names and variable names currently are not that descriptive, such as print_path(), these should be fixed up and made to be more descriptive.

Rename:

• horizontal_spacing_between_directory_containers
• vertical_spacing_between_directory_containers

Add struct char variables for the symbols that use the previous variables

In some places, there are enums that are being used by methods in different impl blocks in different files, despite being defined directly next to only one of the impl blocks, which is a bit misleading. It may make sense to move them all to their own file that can be included wherever they are needed.

This is my most unorganized item. Here are my notes that I had for this item, but it should be cleaned up at some point.

Truncation options for DirectoryContainer

• 1. None
  • No truncation of file names
• 2. Constant
  • Truncates all file names to the same length
• 3. Level
  • Level 0 -> does not truncate file names, Level 1 -> truncate longest file name to be length of second longest name, Level 1, truncate longest and second longest file name to be length of third longest name, etc.
• 4. AverageFileNameLength
  • Get the average file name length and truncate all files to it
• 5. Outliers
  • Using some sort of statistical measurement, identify outliers by some definition and truncate them using Level
• 6. HorizontalFit
  • Perform some sort of calculation on all DirectoryContainers and find the appropriate file length so that all DirectoryContainers can be printing in one line. This will use the Constant mechanism. This should also probably set the horizontal_spacing_between_directory_containers to 0

It should be noted that we can choose whether or not the string that is used to denote a file name has been truncated can be customized and it can be included in the overall truncation length or it can be excluded from the overall truncation length.

• If the directory container name is longer than the truncation value, then use container name as the truncation value

Things to consider, but that have not been decided on:

• Option to allow truncation of directory name too? Not sure, but leaning towards not allowing it, as the directory name is rather important.

• Should truncation string be placed at the end of the string or in the middle? If it is decided to put it in the middle, changes need to be made to the underlying utility function and unit tests need to be updated. Maybe there could be an option to switch between placing truncation string at the middle or end of the file name.

Should directory items be number? If so, should it be optional (a user configurable setting)?

Instead of printing the full path, under this option, the path would just print the last x amount of DirectoryContainers (configurable), the current one, and if the current item selected is a directory, the next DirectoryContainer (see item 2 here). This setting could be used by those who don't care to see too many previous directories and want to reduce the chances of the print wrapping to a new line.

As it is, there are probably some items in the codebase with the pub keyword that can be made private without causing any issues.

Or we can find a good way to let the user decide where the settings file goes, so its path can also be customized.

Similarly to how we no longer print the final horizontal spacing at the end of a row, we should skip the vertical spacing at the last row.

When working on this, set:

• spacing_between_directory_containers_char
• spacing_between_directory_container_rows_char
• filler_char

All to symbols other than that space. It makes it easier to debug with.

A cool thing to maybe implement is an option that, when turned on, would show arrows coming from a selected directory and pointing to the DirectoryContainer name that it relates to. Directories in the current path are already highlighted a specific color, so this isn't necessary, it is just a neat idea.

 -------------      ---------------  
|      /      |   >|     Users     |
|=============|  | |===============|
| (F) .DS_... |  | | (F) .local... |
| (D) .PKI... |  | | (D) Shared    |
| (S) .Vol... |  | | (D) joseph... |
| (F) .file   |  |  --------------- 
| (D) .fse... |  |                
| (D) .vol    |  |                
| (D) Appl... |  |                
| (D) Library |  |                
| (D) System  |  |                
| (D) Users   | -                 
| (D) Volumes |                  
| (D) bin     |                  
| (D) cores   |                                   
| (D) dev     |                                   
| (S) etc     |                                   
| (S) home    |                                   
| (D) opt     |                                   
| (D) private |                                   
| (D) sbin    |                                   
| (S) tmp     |                                   
| (D) usr     |                                   
| (S) var     |                                   
-------------   

More information: The amount of extra space being generated at the end of the path print is equal to the number of DirectoryContainters * the length of the horizontal_spacing_between_directory_containers value.

Note: There will always be one extra line on the right side of the printed path, this is accounted for by the invisible newline characters there.

The DirectoryContainer struct / impl should have a generalized version of it refactored out. This would be a new struct / impl block that is simply a container that accepts a name and a vector of items. The DirectoryContainer class would then use this new class and then this new class could also be used to display the metadata of a file.

There are a handful of unwraps and expects in the code base that should be handled properly at some point.

Note that there are a ton of other options for handling error and options outside of match, such as unwrap_or_else:

https://doc.rust-lang.org/std/option/enum.Option.html

TermiFind will most likely blow up when a folder is empty. Test it out and fix any errors that prevent TermiFind working with an empty folder.

Make an empty folder and run it with:

• Truncation mode set to None
• Truncation mode set to Outliers (fixed)
• Truncation mode set to Level (needs fixed)
• Others

In some places where there are Strings being used and clones of those strings are occurring, it would be nice to investigate if it would be possible to replace them with &strs, but #LifetimesAren'tEasyForMe.

Delete TODO.md when done

Find a place to display:

• number of items in the directory
• size of the space being used by all files
• the breakdown of file types (etc. 15 .doc, 3 .rs)
• any other items

This might be best at the bottom of the directory or the top under the name.

• What string to use to indicate a file name has been truncated - 6f66613
• Item type indicators - 57d164a
• Colors and styling of text
• Others (add to this list)

Make a decision on whether pub (functions, struct members, etc.) should be listed at the top or the bottom of the area they are in and use that convention.

The order within the groups of pub versus non-pub items can either be by order of when they are called or alphabetical.

If you set spacing_between_directory_container_rows_char to any other char, you'd expect to see one more more (depending on spacing_between_directory_container_rows) horizontal line of that character below each row of DirectoryContainers, but the algorithm that uses this char doesn't quite use it this way and you see a very different result. Either rework the algorithm for this to work the way you'd expect, or remove the setting to be able to use any char and for them to use ' '.

It would be nice to have this function return a printable object versus having it do the printing. This function calls a function in the utils that would need to change as well.

If it could be converted into a function that returns the styled object, then it would not need to be called separately from the get_file_name() function. After changing print_styled_file_name() to get_styled_file_name(), it could be made private and called directly by get_file_name(). get_file_name() would need a new boolean parameter for "should_style_file_name`.

Currently, there is an if statement wrapping the match block. The if statement is there to avoid the match when printing the last row of the DirectoryContainer. Ideally, match would cover it all:

    match row_number {
        0 => print top row
        ),
        1 => print directory name row
        2 => print separator between directory name and directory items
        range from 3 to the second to the last => print items
        _ => print last row
        }
    }
} 

I attempted this before, but was unsuccessful; an error relating to using a range in the match wouldn't allow me, but maybe there's a way around it.

I don't have a good way to test these platforms. I'd appreciate any feedback on these platforms that I can get, such as things breaking or not.

Tuples are nice, but they are often hard to read (what does thing.3 mean?), so I'm leaning towards removing all tuples in favor of structs

I'm not sure what all this might affect. Do we still include the files in the the file counts and any statistical measurements that require file counts when hidden files are not shown? I'm leaning towards not using hidden files in calculation if they are not displayed.

Make a decision to either:

1. Use type annotations across the board
2. Only use them where the compiler complains

And stick with that convention

Tests should be written to cover methods in impl blocks.

Currently, the system supports some customization:

• Truncation Options
• Whether the length of the string that denotes truncation should be included in the overall truncation length
• Vertical and horizontal spacing of DirectoryContainers (amount and character used)
• chars that are used to build the DirectoryContainers (vertical lines, horizontal lines, dividing line)
• sort_directory_items() takes in a boolean representing if it should sort the file names by file type or by file name alone

But all of these settings are just sprinkled throughout the system and are only configurable through the code. At some point, these will need to be accessible in a way that they can be saved to a file and loaded.

• Should provide default settings if any of the operations for getting the settings file fail.

Inside update_start_and_end_iteration_tuple(), there are two variables a and b, these suck and are there only because I had no idea what to name them. Fix them at some point.

This will require another issue of implementing some sort of scrolling mechanism, which relates to #2. The point of this would be to limit the height of DirectoryContainers so that rows that wrap around aren't forced down much further because of one long DirectoryContainer. The same sort of statistical measurements that are used on truncating file names (Constant, Level, Average, Outlier) could be used to limit the height of a DirectoryContainer.

TermiFind's ultimate goal is to be interactive, like the macOS Finder. It needs to be fitted with a mechanism to allow for moving through directories and selecting files. This could require some Terminal manipulation libraries, such as:

ncurses-rs
crossterm

These can be used to wipe the screen entirely and reprint the whole structure with any changes based on the interaction or certain parts of the screen can be updated. The second option will probably require a rewrite of the system. I'm more in favor of leaning towards any options that avoid using crates with unsafe Rust code.

Some actions that should be possible are:

1. Left and right arrow keys to navigate directories, popping off or adding DirectoryContainers on the right side.
2. Up and down arrow keys to browse files
   • Highlighting a new directory should show a preview of its contents, as either a new DirectoryContainer to the right of the current one.
   • Highlighting a file should show a container with the file's metadata in it.
3. Pressing enter to open a system application for that file type or to open a terminal editor
4. Maybe an action to return the currently selected path to the shell and close TermiFind.

Currently, there are a few functions that call get_file_name_lengths_and_positions_vec(). One of them requires the vector returned be in reverse order and one that doesn't care about the order. Currently, the vector is generated in ascending order and then reversed later, but it might be better just to binary insert into it in reverse order to begin with. Once this is done, the reverse() in get_truncation_value_by_level() can be removed.

The console crate that is used can style text to be bold or italic. It might be worth it to consider styling important things such as directory names, directories in the current path the, currently selected item, etc, in addition to how they are currently color coded.

If there terminal window is too narrow to display any of the DirectoryContainers, TermiFind will infinitely print in a loop. The Terminal needs to be at least as wide as the widest DirectoryContainer. An error message should show if not and the application should exit.

The fix can be: "If the terminal width is smaller than the current DirectoryContainer, then exit the application with an error. The error could have useful information as to why it crashed, but also maybe at what DirectoryContainer it crashed at.

Remove dead_code tags for items that have been implemented.

Something to consider would be printing a color key telling the user what each color means

The screenshots show the error in the wrapping (TermiFind would wrap down to a new column of DirectoryContainers when it still had room to print in the previous row). Take some new ones.

Should a directory container have just the name of the folder or should the dividing symbol (e.g. Uni / Linux =/) be included before it? It makes sense in that if you look at all of the DirectoryContainer names, they would form a valid path if the separator was included, but maybe its prettier to not show it.