Provide Context for the New Feature or Enhancement You Would Like

nomad currently builds the entire tree before it is displayed in the terminal. While this is not an issue when running nomad within smaller directories, it becomes substantial when running it in very large directories like /, for example. After running nd, it appears the command is hanging but nomad is actually just building the tree in the background.

Like what the original tree command appears to do, live-printing the tree as nomad finds new files or directories would provide a better user experience.

Explain Why You Believe This Would Be a Good Feature

Everyone loves a program that runs fast. Who actually likes waiting, especially for something written in Rust?

The hanging effect after running nd in big directories in the terminal may also cause confusion for the end user (ie. "did nomad crash?").

Is Your Request Related To a Problem?

I did not open a separate bug report for this since this is technically not a bug, but rather a performance issue.

Describe Alternatives You Have Considered

I have considered writing my own implementation of a tree-building library; however, I believe ptree is already a great crate, so why reinvent the wheel?

Additional Context

This is currently just a limitation of the default method of tree building that the ptree crate offers, since I did not implement a custom TreeItem trait and just used the provided TreeBuilder struct and print_tree_with() function to create and display the tree with custom formatting settings.

I believe this feature may be fulfilled once I take a deeper dive into the inner workings of ptree. If it is not possible to do by just implementing my own TreeItem trait, perhaps I would have to modify the source code and maybe even open a pull request for ptree adding a live print option of some sort when I figure it out. If I do open a PR for ptree and it is not accepted, I will just have to fork my own version of the crate and include it in nomad's source code.

Provide Context for the New Feature or Enhancement You Would Like

There is currently no way to scroll or expand the Tree (Normal) View within Rootless mode. This may become an issue with longer filenames, deeply nested items, or when displaying file metadata.

I would like to add two different ways to adjust the size of the Tree View:

• Add a keybinding that will expand the Tree View so that it takes up the entire width of the terminal, hiding the File View in the process.
• Add two keybindings to increase or decrease the width of the Tree View incrementally.

Explain Why You Believe This Would Be a Good Feature

It would be nice to see everything in the tree.

Is Your Request Related To a Problem?

N/A

Describe Alternatives You Have Considered

N/A

Additional Context

Ideas for the new keybindings:

• Map "F" for the Tree View to toggle fullscreen/full-width mode.
• Map "+" and "-" for the Tree View to increment/decrement the width of the widget.

Provide Context for the New Feature or Enhancement You Would Like

There are currently two different panes that are related within Rootless mode - the current settings and the available keybindings for each mode. These panes may be toggled with the "s" and "k" keys respectively.

This makes the UI feel a little clunky; a friend suggested (thanks @LukeDSchenk) I should merge these two panes to improve the user experience.

Explain Why You Believe This Would Be a Good Feature

Everyone loves a streamlined user interface. Rootless mode already has a bit of a learning curve since it currently (beta) does not support mouse events, ie. clicks and cursor tracking. This means users will have to navigate solely by keybindings. Making it as simple as possible is in everyone's best interest.

Is Your Request Related To a Problem?

N/A

Describe Alternatives You Have Considered

N/A

Additional Context

The only concern I have with merging the two is displaying the keybindings for the Breadcrumbs widget:

Would it still make sense to just hit "s" when in the Breadcrumbs widget, even though "s" represents the current settings, to bring up the available keybindings for this widget?

Describe The Bug

Running nd git add when adding (staging) files on a new branch will not work.

Expected Behavior

This subcommand should successfully stage a file by modifying the Git index.

Actual Behavior

nomad throws an error stating it is unable to stage files and does not modify the Git index.

Steps To Reproduce

• git checkout a new branch.
• Create a throwaway file and run nd git add <FILE_OR_DIRECTORY_IDENTIFIER>.
  • An error should be raised here stating nomad is unable to stage the file.

Traceback/Output

"Unable to stage files": Error { code: -9, klass: 4, message: "reference 'refs/heads/master' not found" }

Additional Context

According to the error that was returned, I may need to revisit how the Git refs are pulled from a repository.

Provide Context for the New Feature or Enhancement You Would Like

I recently learned some people do not run git push --set-upstream origin <BRANCH_NAME> when pushing code from a new branch upstream. nomad currently assumes a user would do this, and displays the number of commits ahead of an upstream branch assuming the user has ran that Git command.

A message "No upstream branch found" is displayed if the user does not run that Git command and runs the nd git status subcommand.

Explain Why You Believe This Would Be a Good Feature

The "No upstream branch found" message may become annoying for anyone who does not run that Git command to set the upstream branch. I think I should remove this message and only display the number of commits ahead if the user chooses to set the upstream branch.

Is Your Request Related To a Problem?

N/A

Describe Alternatives You Have Considered

N/A

Additional Context

N/A

Describe The Bug

Empty directories are missing in the tree.

Expected Behavior

Empty directories absolutely should be included in trees.

Actual Behavior

nomad skips over all empty directories.

Steps To Reproduce

• cd into a directory containing empty subdirectories (or run mkdir <DIRECTORY_NAME> and do not add any files into the new directory).
• Run nd to display a tree visual of the directory's structure.
  • The empty subdirectory/subdirectories or the newly created empty subdirectory will not be included in the tree.

Traceback/Output

N/A

Additional Context

I need to revisit the ToTree trait in src/traverse/traits.rs since this trait is where the tree is built. I think it should (hopefully) be a simple fix once I find where the issue is occurring.

Provide Context for the New Feature or Enhancement You Would Like

The --tokei flag currently displays the number of blank, code, comments, and total number of lines within individual files. It would be nice to also see the total statistics for an entire directory, instead of doing math to figure out this number.

I want to add the ability to display the total number of blank, code, comments, and lines of all files in a given directory next to or underneath that directory as a summary of sorts.

Explain Why You Believe This Would Be a Good Feature

It would just be interesting/useful to see this information.

Is Your Request Related To a Problem?

N/A

Describe Alternatives You Have Considered

N/A

Additional Context

N/A

Describe The Bug

The nd git status subcommand should usually display some branch information on top of the tree containing changed files. Running this command on a new branch or a new repository will display an error instead of the branch information.

Expected Behavior

This subcommand should successfully display branch information and upstream branch information, if applicable.

Actual Behavior

An error message appears in lieu of the branch information.

Steps To Reproduce

• git checkout a new branch or create a new Git repository locally.
• Run nd git status.
  • An error should be displayed on top of the tree containing changed files.

Traceback/Output

Could not get repository HEAD!

# The Git status tree is displayed here.
# ...
# ...
# ...

Additional Context

I need to revisit the git2 crate and figure out a different way, or perhaps how to handle different conditions, to go about extracting branch and upstream branch information from a Git repository.