$ brainylog a this is some info

Should add

(2020-06-27T13:25:53+05:30)[1593244553012.0]5609c717-8ff8-4b33-808f-c208feacfb0d>this is some info
into a new line in log.bl.

Also support multiline info:

$ brainylog a "this is one line
this is the next?
Yup"

Only the first line will have the timestamps and uuids

On line match, display surrounding lines too.

Need clarification on exact functionality - would this be done by default on every get? - might lead to lots of text, maybe the user can specify the number of surrounding lines as an option.

Another important requirement is to display the surrounding lines of a particular line using its hash.

For version v 0.1, for any line uuid or pos number, we'll display 5 lines above and below if the following command is entered:

$ brainyLog g -u lyg66g7 (based on uuid)
$ brainyLog g -n 3 (based on temporary positional number)

Instead of simple searches based on if any of the keywords match, use the following algo to come up with scores to determine the relevance of a line in the result and return the lines in order of relevance whenever the get command is used:

Parameters affecting relevance
tf-idf - use a smart version of this
timeStamp - more recent lines are more relevant

In addition to the default log.bl, users should be able to create their own .bl files for organization.

Support lookups and adds on a specific file, as well across all of the user's .bl files.

Currently, the task processing outputs success when done on info logs.

There is no change in the log itself, but this message should be changed to say
"Cannot change task state on info log!"

We need to come up with a design for our web UI.

The following are the priorities from a user perspective:

1. Clean interface, focus on operations, no clutter.
2. Minimal taps, UI elements resize based on current action so the most important ones are in view.

A basic transition: Landing Page -> sign up -> Available memories (files) -> add or get
If add -> Fill up UI with editable section, the user adds an element.
If get -> searchbar and results on whole page -> the user selects an element - > the search elements resize and a new view with actions on the given element along with a section based on the action selected fills up the view.

Having your log file full of unwanted data is no fun!
Mark lines as deleted so they won't be retrieved by brainyLog.

Have a status metadata for every line (s-00 by default)

Status 00 means it's a normal line.
Status 01 means it's deleted.

Delete lines using the following command:

$ brainyLog d u 724gh

Or using temporary positional number:

$ brainyLog d n 3

Lines once deleted cannot be undeleted (at least for now!)

Change the path of the file to the current directory.
This will require the user to actually be in the same directory as the file to execute commands that require the file

All brainyLog commands should output meaningful messages when executed.

Major interface redesign! Showing all the line metadata by default makes no sense. The UUID should hardly ever be visible to the user, and the temporary positional number should be used instead. The UUID could have been used as a quick way to refer to a particular line with 100% certainty, but now seems silly as the get command is supposed to return relevant results all the time anyway.

For info logs:
Show line content and positional number.

For tasks:
Show line content, status, and positional number.

nm shows only line contents, and the temporary positional number should not be updated in this case.

This should help ensure the interface isn't intimidating and is joyous to use.

The keywords needn't be entirely contained in the line.
Typos and missing chars can be allowed.
Relevance to be determined.

Currently, the file path bin/log.bl is used to access the file, change this so it can be accessed from anywhere.

Proposed solution:

• Set an env variable containing the path to the file (can be done using a "setup" command.
• Reference this env variable in all file accesses in code.
• If the file is found, use it, else look for .log.bl in the current directory.
• If neither match, display an error to the user.

Ensure compatibility with Windows/ Linux and MacOS

To keep things simple, if no log.bl exists in the current directory, brainyLog errors, and asks the user to create an empty log.bl in the current directory, with the warning that the file would be empty if the command is an add.

For commands other than add, brainyLog simply errors.

Standard Release Procedures:

1. Ensure README is up to date
2. Verify binary works on Windows, Linux and Mac
3. Reach out to potential users and receive feedback on improvements, bugs, and features.

v0.1 Specific Procedures:

$ brainylog v

should provide basic version info.

In addition to working with log.bl, users can use the get command with the l key on any text file. It should return the contents at matching lines along with the line numbers.

This would be quite useful to analyse pre-exisitng files.

Currently, brainyLog g gets matching lines along with all their metadata.

Edit the below description - we will generate a scratch file on every write. The user can play around. But on next write the changes would be overwritten with whatever's in the .bl file.

This can be the default behavior. But also allow a --filemode flag to define the view

$ brainyLog g --filemode

This creates a file named .log-scratch.bl in the same directory as .log.bl.
This would be a regular text file that's editable independent of brainyLog, with lines in temporal order.

The command also outputs a list of line numbers corresponding to the matches of the g command in the .log-scratch.bl file.

Once this file has been created by brainyLog, it's completed independent. The user can do whatever he wants with the file, but it will be overwritten on next run of the g command with --filemode.
The command can prompt a confirmation if the file would be overwriten, allowing the user to make a copy of the file if necessary.

While we could technically incorporate multi-line logs at this early stage, there would be several things that would need to be polished. We'd need to set limits (or not?), decide how to display them to the user and so on.

For now, in our goal to deliver a smooth, clean experience with every version, we're only going to support single-line logs.

Prevent user from entering multi-line log in brainyLog a

Currently, the user needs to input the UUID of the required line for certain operations.

The get command should also return a temporary line identifier (can be digits from 0-...) and the user can enter these instead of the UUID for those operations.

Simple keyword matching for now. Ignore relevance and fuzzy matching.
Linear search for keywords - list all lines that have keywords that match along with timestamps and hashes
For multiline info, show only the first line with (m) before all line metadata for that line.

Using -'s is hard on a mobile keyboard.
Also, we need a way of identifying when the command's arguments have ended and when the log actually begins so we can enter argument chars in the actual log too.

$ brainyLog a t l bake a cake
Add a task "bake a cake"

$ brainyLog g t progress l l is a wonderful letter
Get in-progress tasks that match l is a wonderful letter

It's time to bring together relevant logs - temporal locality to the rescue!

Steps:

1. User does a search:

$ brainyLog g milk
drink milk [0]
milk is good for you [1]
This milk has gone sour [2]

2. The user uses the a command with the n (temporal positioning) key and the value as the positional number to add the new log just after the specified one:

$ brainyLog a n 2 l milk goes sour if left undrunk

n can be combined with the t flag to temporally position tasks.

The user can retrieve all tasks in a given state using the get command with the -t option:

$ brainyLog g -t created

Also provide an all option to get all tasks:
-t all

The user can also optionally specify a search input to filter tasks:

$ brainyLog g -t progress heat leftovers

Not all tasks are equal. Some are more important than others. And some simply need to be done now!

Provide an interface for prioritizing tasks, as well as setting deadlines (soft and hard).

And then provide quick and easy methods to get the tasks you should be working on.

Currently using nromalize term frequency on tokens and exact match scores on keywords to get scores for each line.

Can be improved using idf and other heuristics.

Refer to the last comment issue:
#26
for current implementation details

The user should be able to pass in a -t flag while adding a log to denote it as a "task" log.
Append the following to the end of the epoch element [...]: (T0)

Retrieval works exactly the same as for info logs for now.

Use nm to display line contents without metadata info.

Escape sequences that could potentially match our metadata (timestamp-uuid combination).
Appropriate processing needs to be done on retrieval as well.

Since tasks could be repeatedly entered (example: buy milk!), having all these entries show up when we're looking for some information would be annoying at the very least!

Allow an i flag for g commands which only search for info logs.

Add (user-john) metadata info.
This would be useful for collaboration.

The following are the task states and the command option to move them to that state
T-0 - Task Created - automatically done when a task log is added
T-1 - Task In Progress - progress
T-2 - Task Suspended - suspend
T-3 - Task Cancelled - cancel
T-4 - Task Completed - complete

The user can move any task log to any one of these states at any time using the t command:

$ brainyLog t ggh67y complete

Since brainyLog is supposed to help you find whatever, there might be loads of matches on every get l.

To avoid filing up the interface with loads of irrelevant results, paginate the results, showing the next set of results only on a particular keypress.

This helps ensure matches are (mostly) always found, even though poor search terms may require a lot of sifting through results.

Currently, to share information with other users, a user would have to send him a copy of his .bl file.

But we can also have a feature to merge memories in a single .bl file in real-time for collaboration.

Need more information on the requirements:

What kind of files? What do they contain?
Lookup by filename only or based on contents also?

Currently, if a deleted line is found in g m, it is still counted in in m, even if it's not displayed.
Fix this to not count deleted lines when using g m.

Use a standard of (key-value) for any line metadata info.
For example, tasks: (T-0)
User: (U-john)

This info would come after the epoch ending [...] and before the UUID.

Temporal locality works fine with the n < position >, but if the user wants to add multiple entries one after the other, always referencing the same position will result in the entries being added in reverse order.

The N flag would also be a convenient way to work on immediate data.

Eg:

$ brainyLog g l some info
$ brainyLog a n 3 l some info 1
$ brainyLog a N l some info 2
$ brainyLog a N l some info 3

This would add the three info's just after some info in that order.

Can also be used with the t and d commands to process the immediately added/retrieved line.

The line bound to N is unaffected if multi-line retrieval is performed.

This is a bit fiddly. We can simply do a search on each line, that's fine. But for tasks, we need some special demarcation, maybe a (T-0) at the end?

The task states would then be manually entered by the user using (T-< state number >)

This is on the user to ensure the manual editing of text files is accurate. BrainyLog provides no guarantees, only conveniences on such files.