One of the best things about a CLI application is Banner.

We want to create a great banner for Notya, it could be a banner similar to the example below.

Currently rename could take only base note's title from arguments, and not the second title - new-title of note.

It would be absolutely good if new-title could be passed as arguments or from flags:

> notya rename new_title.txt my_new_note.txt
                   ||            ||
                base file      new title

A simple command to display [current] version of the Notya.

> notya version
v0.1.2

Note: version instance could be found at {pkg/constants.go} as > pkg.Version

-Make copy command independent from CGO-

Current clipboard package 'causes a lot of problems while building binaries for different platforms. And the releaser package that we use, does not support compiling go files that use CGO.

Anyways, we should avoid using CGO. the only package that needs CGO is the clipboard. Alternative -> Creating our writeClipboard() function, which'll execute platform-specific command, to copy file body to clipboard.

Something similar to open-via-editor functionality: os.exec(..)

As a view, remove, edit and etc commands, has the ability to take note title that we wanna do some action with it, also, create should have the same functionality.

Now, it's not available to call something: notya create new_note.txt actually we could but, it won't take new_note.txt as created note's title and would ask again for note's title.

Ability to create note with body in one command like git commit -m command: -b, --body

notya create newnote -b "Note body here" notya create newnote -b "Note body here"

See also issue 94

For example, here, in the case of the view command, folder-type nodes shouldn't be listed in the suggestion. Because the view command does nothing in case of calling for a folder.

In case of calling the file related command with folder-type node path, CLI's repsonse should be an error:

 [X] <your-file-name> is not a file, you can't execute file-related commands on it.

We need a command, or a flag/subcommand to the settings command to provide a simple way of connecting remote service to the application.

For example: remote command

notya remote connect
[?] Choose a remote-service type:
> FIREBASE

or notya remote connect "FIREBASE"

notya remote disconnect
[?] Choose a remote-service type:
> FIREBASE

or notya remote disconnect "FIREBASE"

Current settings is definitely suck, even for myself it is hard to figure out some customizations. it has to be redesigned by improving the user-experience or (programmer experience)

Current version of firebase connection has no foldering functionality. That means you can not upload your folders to the connected firebase (firestore)collection.

Decided to rewrite entire CLI application with Rust programming language.

Go is great for Microservices and cloud base applications, but by getting more and more stuff to done with go, the simplicity causes too many issues. I won't spend my time by comparing Go(lang) and Rust. Go is good, And also rust is good, but +1 point for CLI flexibility.

as the command line interface of this is going to be used by developers mostly, it will be a good idea to make command line arguments more like GitHub:

• notya add [notename]
• notya -d, --delete [note Id or anything that identifies the note]
• notya push
• notya restore

The programmable command, which gonna be a command itself like ("alias", "short" etc...)
and it gonna have a list of sub actions (identified with their names).
Like:

notya short clean                                                                                      

• "And it will look up for the registered "clean" action find it and execute".

After implementing this functionality, the create command's "edit-ask" operation should be removed.
Because, with this functionality users gonna be able to create and program in low-level their commands. So, if user wants to create something like:

• create a file and open it via editor, this definetly could be an short command.
  That first calls for the "create" command and then the edit command.

A flag to create command. Which gonna create note, edit it via editor automatically and when you done with it, it gonna copy it automatically and remove.

notya create --onetime

title: ... ... editing ... wanna copy ?

Information

• Machine: [e.g: MacBook Air - Apple Silicon M1]
• OS: [MacOS Monterey 12.4]
• Version [v.0.1.3]
• The way you installed notya.

Both installation ways gives me these errors:

A clone command, that could be able to fetch a web page(from provided URL), convert it to pure text, and generate a note file automatically (appropriate to that file).

Example:

notya clone https://github.com/anonistas/notya/blob/main/README.md

To make that web-to-text parser accessible from each platform(CLI/mobile(coming-soon)), we should provide a simple API(instead of putting the main parser into the notya-cli) to generate text from web pages.

https://localhost:8080/<url>

In the current version, notya uses cobra's auto-generated help txt. To make it better look we should use our custom one.

Something like:

  _   _    ___    _____  __   __    _
 | \ | |  / _ \  |_   _| \ \ / /   / \
 |  \| | | | | |   | |    \   /   / _ \
 | |\  | | |_| |   | |     | |   / ___ \
 |_| \_|  \___/    |_|     |_|  /_/   \_\

 Usage: notya [command]
 Take notes quickly and expeditiously

 Common Commands
╭──────────────────────────────────────────────────╮
│ init           Initialize application            │
│ settings       Customize defaults & behavior     │
│                                                  │
│ view           Print note's metadata             │
│ list           Print a list of all notes         │
│ create         Create new note file              │
│ remove         Remove exiting note file          │
│ edit           Edit note with editor             │
│ rename         Rename note file                  │
╰──────────────────────────────────────────────────╯

 For more info on a specific command, use:
  > notya help [command]

Requirements:

• The banner should be pure white
• Usage: notya [command] should be grey.
• Take notes quickly and expeditiously should be grey.
• Common Commands title should be colorized [purple, yellow etc ...]
• For more info on a specific command, use: title should be with 0.5 opacity.
• > notya help [command] should be pure white.