External users such as, for example, lualine may want to identify and
add special handling for Avante buffers. This is easily done for Avante
result, input, selected files and todos buffers as they all set a unique
file type. However the selected code buffer inherits file type from the
buffer where the code came from (to have proper syntax highlighting),
and so filetype can not be used to identify it as Avante buffer.
One option would be to add a custom buffer variable, such as
vim.b.avante_buf_type and use it in plugins. Unfortunately lualine
triggers everything on file type, so that would not work.
Solve this by setting file type of the selected code buffer to
"AvanteSelectedCode" and manually activate treesitter parser with
language of the source buffer if treesitter is active there. If the
original code buffer uses legacy syntax highlighting then activate it.
This keeps syntax highlighting active for the code while allowing
external users identify Avante selected code buffer.
Current implementation always says that first 5 lines of code is shown
when selected code does not fully fit into its window. This is not
correct as the window can be resized, may have a header occupying one
line, and the lines may not be the first ones. Also the wording is
awkward.
Correct these issues by checking current window height, accounting for
the potential header presence by checking sidebar.enabled config flag,
and updating the message format to be more concise:
" Selected Code (4/15 lines)"
While at it switch to using Utils.count_lines() which does not need
creating temporary tables.
Note that this does not deal with the header info being stale after
resizing sidebar windows.
Change the constructor to accept role and a single content item instead
of raw AvanteLLMMessage instance. This will help when we will start
changing message.content from being a string or a list of tables to just
a string or a single table.
This adds History.Helpers.get_text_data() helper to fetch contents of a
"text" message. This removes the need to know internals of message
structure outside of history module.
It is unwieldy to handle fields in opt table one by one. Luckily there
is vim.bl_extend("force", ...) that can help us here.
Also move annotation for opts from parameter to a separate class to make
it easier to work with.
- Refactor TODOs handling: move logic to `context_messages` instead of using `template_opts`
- Improve todo message filtering by using more precise tags (`<todos>...</todos>`)
- Append TODOs after history messages
- Remove the TODOs section from `_task-guidelines.avanterules` template
Signed-off-by: doodleEsc <cinuor@gmail.com>
Commit a9b01e7 ("chores: use stopinsert (#1745)") replaced uses of
vim.api.nvim_feedkeys(...) with proper commands to exit and enter insert
mode. However "stopinsert" does not help when editor is in visual mode.
Unfortunately there is no dedicated command to exit visual mode so we
have to go back to simulating keystrokes again.
Now that we have a table listing all containers and can iterate over it
we no longer need a separate table with window IDs that we need to
maintain. Remove it.
Maintaining secondary table of window IDs is cumbersome and is prone to
getting out of sync with the true state of the sidebar. In preparation
for removal of winids table move all containers (sub-windows of the
sidebar) into "containers" table.
The change is mostly mechanical rename with following exceptions:
- Sidebar:reifresh_winids() and other places where the code scanned
entire Sidebar object looking for tables with specific fields, such
as "winid", or "mount" needed to be adjusted for the new structure
- Sidebar:new() and Sidebar:reset() have been adjusted to make better
use of the new sub-table.
Under the hood vim.list_extend() does the same loop over the source
table and uses table.insert() to append the values to the destination
table, so using a temporary table makes little sense.
Switch to directly inserting (appending) values into history_lines
table.
When updating chat history to be used in LLM request there are several
instances where we do O(n^2) operations: scanning all messages to locate
a tool "use" and for each use scan messages again to locate
corresponding "result".
Refactor the code to scan messages once collecting tool uses and results
together, and then do 2nd scan to drop incomplete tool invocations and
refresh "view" and "edit" results with the latest content.
Also reduce number of pre-scan loops (where we discard partially
generated messages or messages that are not interesting or too-old) by
combining them when possible.
This reduces time to scan initial 417 messages on my system (which
result in 576 final messages) from 0.32 to 0.12 seconds.
Rate limit handling seems to be broken: it starts an one-shot timer
with callback that reschedules the timer each second and prints/updates
messages. Simultaneously it schedules a deferred by 1 second function
that cancels the timer and resumes the stream. This results in the timer
executing at most once, and stream resume happening way too early.
Fix this by switching to use repeating timer with first instance
executing immediately. All message handling is moved into the timer
callback. Once countdown is complete the same callback will stop and
destroy the timer and resume the stream.
