The stdlib (under our nose) has added a bunch of very useful methods for us: https://modules.vlang.io/encoding.utf8.html

Need to take advantage of a bunch of them soon.

If lilly is opened from anywhere other than the base directory of the project (where the .git file is found) then the git branch isn't resolved.

The issue is in ./src/lib/workspace/workspace.v in the resolve_git_branch_name function, is_dir is called just on the workspace directory checking for .git

We can walk back up directories until we find .git, but there has to be a limit.

For some reason each time Lilly starts the background/cell highlighting colour changes to a different shade when it should be consistently the same as what is set in the configuration.

At this time the cause is completely unknown and will require some investigation.

See title 😉.

Create a first draft for LSP interface

When running commands such as :w, we get a nice response/status message rendered in the status line.

When we run the same command again, the status line remains blank, which provides confusing feedback for the user, ie., has the document been saved or not??

This should be fixed, in that there needs to always be a response message rendered.

This change to the V compiler causes Lilly to panic on start: vlang/v@112fc950

As described by core contributor spytheman, the issue:

in effect, your code, when compiled with the new version of the compiler passed invalid pointers to functions that expected callbacks that accept voidptr (thus the type system allowed you to pass for example both fn frame(mut app &App) { and fn frame(mut app App) { in such places, without complaining)
it can not be, since voidptr is an escape hatch, designed to allow you exactly that; it trade offs flexibility for type safety
an alternative would be to redesign term.ui for example to have generic functions, that do more type checking on the passed callbacks, but that needs changing a lot of code and expectations

The panic capture writes should probably be prefixed with some kind of timestamp for easier tracking of issues.

I think it would be great if there was a <leader>qq to quit Lilly. It should also be part of the menu listing at start so people see it.

The behaviour change relates to how we load files/workspaces:

• Expect a directory path which it opens as the "workspace"
• Expect a file path which it opens directly but also loads the file's parent directory as the "workspace"
• Allow neither and opens the PWD as the "workspace"

https://choosealicense.com/licenses/apache-2.0/

Example line: mut line_segments, _ := resolve_line_segments(resolve_text_syntax(), line, 0, false)
^ cursor is here
On the next press of w the cursor just skips the rest of the line, and jumps down to the next one. Why?

When pressing escape the cursor moves back one place

What is the best build solution? Because not everyone has just. But it seems nice too.

A core keybinding in vim is the a and A commands, for appending from the current cursor position and appending at the end of the current line.

This work should also include tests reflecting the functionality of both functions of the a key.

Going forward any contributions to Lilly should try and abide by https://www.conventionalcommits.org/en/v1.0.0/
In order to communicate this to everyone this should be added to the README.

The Levenshtein ratio, which is (a+b - LevenshteinScore)/(a+b), where a and b are the lengths of the two strings being compared.

When you exec a command, :w for example, you get a message to tell you if its been successful or not, or not recognised.

This message persists even when using the space in the UI, for example performing a search:

The rendering of the document has inconsistent colouring directives depending on whether a word is captured by a syntax segment, and affects whether certain parts of the lines are rendered in one instruction call, or as a full line of text. This is making it harder to implement aspects such as highlighting found search results for example. Additionally the view pane is unable to behave independently to the actual number of lines and position of the cursor etc.,

A refactor/overhaul of how we render is necessary at this point.

When I try to remove the character on the right of my cursor in insert mode using the remove key, Lilly won't remove it but kind of bug out. Below I've attached a video of me using remove in Neovim and in Lilly to demonstrate what I mean.

V provides an action for setting up V in CI, and has an article about running tests in CI, so this should be pretty straight forward to implement.

https://blog.vlang.io/setting-up-github-actions-for-v/

The repo settings will need updating to protect main, not allowing branches to be merged unless CI is passing.

For local development of actions developers can consider the use of https://github.com/nektos/act

Why does lilly not allow me to start it like a normal application?

When I start the application I get this error:

# ./lilly
too many file paths, expected just one

I expect to be able to start the editor like any normal TUI application.

https://www.youtube.com/shorts/EvRKLO3TcOg

I see hardcoded numbers for the status line. Any plans to refactor the code to make it easy to recompile with status line at the top? Or even having a runtime option to set status line to the top instead of bottom?

Thanks!