Skip to content

Conversation

@sudo-tee
Copy link
Owner

This PR is adding a context bar to manage/view context being sent by the plugin

@sudo-tee sudo-tee changed the title Draft: feat(context): context bar DRAFT: feat(context): context bar Oct 16, 2025
@sudo-tee sudo-tee mentioned this pull request Oct 17, 2025
15 tasks
@cameronr
Copy link
Collaborator

Ooh, I'm looking forward to this!

@sudo-tee
Copy link
Owner Author

Yes I have some small issues after the rebase. But it's coming together.

@sudo-tee sudo-tee force-pushed the context-bar branch 6 times, most recently from 502a4c1 to ab1e7fd Compare October 30, 2025 10:06
@sudo-tee sudo-tee changed the title DRAFT: feat(context): context bar feat(context): context bar Oct 30, 2025
@sudo-tee
Copy link
Owner Author

@cameronr

Whenever you have time you can have a look ?

You can review the code if you like and also tell me if the feature works for you.

I think it's going to be a nice feature but I might be biased :)

@cameronr
Copy link
Collaborator

Yes, I'm very excited for this feature! will test and review today.

@cameronr
Copy link
Collaborator

cameronr commented Oct 30, 2025

I haven't looked at the code yet but, for this kind of feature, I like to start with a review of the design / functionality

Design:

  • Overall, it looks nice :)
  • The # popup menu is great
  • Given how tight the input_window area is on space, I think it's worth asking two questions:
    1. Is the gear icon necessary?
    2. The extra line between the context bar and the prompt looks nice but it might be sacrificing too much vertical space. If we right align the content, maybe we could get away without needing that extra line? Here's what that would look like (at least with my config):
Screenshot 2025-10-30 at 13 47 42

Functionality:

  • Pressing #, highlighting an item, and then canceling selection / closing the blink autocomplete window, leaves the cursor on the line above where prompt input starts:

Kapture 2025-10-30 at 13 22 07

  • The lines seem to behave strangely when pressing enter. I think it's related to that extra padding line? Most noticeable with set nu in the input window.

Kapture 2025-10-30 at 13 51 09

It seems like that extra padding line is creating some interaction issues so I think the big question is if it's really necessary?

@sudo-tee
Copy link
Owner Author

Thanks for the great feedback.

You are right about the padding. I added it for looks because it looked weird with the winbar ( mostly my frontend dev background though it looked better 😅). I like the suggestion to align it to the right. I will see what I can do about it.

I also saw some quirky behaviour with the padded line. I will remove it and see if it feels better.

Don't hesitate if you have other ideas to improve it.

Thanks for your review.

Copy link
Collaborator

@cameronr cameronr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A really nice feature and will be great when it goes out!

Comment on lines +208 to +223
local _, col = unpack(vim.api.nvim_win_get_cursor(0))
local line = vim.api.nvim_get_current_line()
local key = config.get_key_for_function('input_window', 'context_items')

local completion_text = key .. (item.label or item.insert_text or '')
local text_start = col - #completion_text

if text_start >= 0 and line:sub(text_start + 1, col) == completion_text then
line = line:sub(1, text_start) .. line:sub(col + 1)
input_win.set_current_line(line)
vim.api.nvim_win_set_cursor(0, { vim.api.nvim_win_get_cursor(0)[1], text_start })
elseif col > 0 and line:sub(col, col) == key then
line = line:sub(1, col - 1) .. line:sub(col + 1)
input_win.set_current_line(line)
end
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

emmylua_ls suggests a nil check on col (and maybe this is a slightly cleaner way to get col):

  local col = vim.api.nvim_win_get_cursor(0)[2]

  if not col then
    return
  end

Comment on lines 500 to 527
vim.api.nvim_create_autocmd('BufWritePost', {
pattern = '*',
callback = function(args)
local buf = args.buf
local curr_buf = state.current_code_buf or vim.api.nvim_get_current_buf()
if buf == curr_buf and util.is_buf_a_file(buf) then
M.load()
end
end,
})

vim.api.nvim_create_autocmd('DiagnosticChanged', {
pattern = '*',
callback = function(args)
local buf = args.buf
local curr_buf = state.current_code_buf or vim.api.nvim_get_current_buf()
if buf == curr_buf and util.is_buf_a_file(buf) and M.is_context_enabled('diagnostics') then
M.load()
end
end,
})
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

could consider not setting up these autocmds if context is disabled?

Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see your point, but if you toggle it later with something like

Opencode run context=enabled=true hello there

you might end up with some stale context.

-- context
last_sent_context = nil,
current_context_config = {},
context_updated_at = nil,
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I only see context_updated_at written to. Is it actually used/needed?

Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The context_bar is listening to it
image

This related to the reactive_state file. I wanted to wrap the context to be able to subscribe to individual fields, but it ended up more complex than just having a timestamp. It's a bit of an anti-pattern but LuaJit does not support ipairs in memtables so we cannot loop over indexed arrays when wrapped in memtables.

Maybe I will find a better pattern later, but this one works for now and is simple enough

@sudo-tee sudo-tee force-pushed the context-bar branch 3 times, most recently from dda859d to 7121f13 Compare October 31, 2025 12:26
@sudo-tee
Copy link
Owner Author

@cameronr

I did align the bar to the right and removed padding, It was a really great suggestion. It seems to work really well. I didn't encounter cursor jumps.

Let me know what you think.

There is still a couple of stuff I want to add like un the user message show that diagnostics have been shared like with section and now cursor data, a part from that I'm almost done

@cameronr
Copy link
Collaborator

cameronr commented Oct 31, 2025

I took a quick look and it looks great!

My only other thought was if we should move the guard icon to be left aligned in the context bar? I think that would make more sense and probably look good?

@cameronr
Copy link
Collaborator

Actually, now that I think about it, I wonder if the agent mode should be there too? It's not as clear (input guard is clearly input related) where as agent mode is more output related. That said, making sure the mode is set correctly before submitting is important and reducing the visual distance to verify that could be an improvement. Maybe it's worth at least looking at?

@sudo-tee
Copy link
Owner Author

Those are great suggestions.

Current Model is also something related to input, but this could make the bar a little to crowded

I will play around with that idea.

@sudo-tee
Copy link
Owner Author

I moved the prompt guard into the context-bar and you are right it make more sense there

image

@sudo-tee
Copy link
Owner Author

sudo-tee commented Oct 31, 2025

Not convinced about the mode though. It looks a bit odd to me
image

Maybe it could be a future task to find a better place for the model and mode

@cameronr
Copy link
Collaborator

cameronr commented Oct 31, 2025

Yeah, mode may be a stretch. My last idea is trying mode on the left rather than the right. My thinking is that from left to right it's conceptually:

  • can i submit? (prompt guard, and, most of the time, it's not there)
  • what mode am i submitting in (build/plan)
  • what context am i including?

but it's possible that mode on the left just won't look good :)

if it doesn't look good, we can leave it up in the output_window winbar for now.

@sudo-tee
Copy link
Owner Author

sudo-tee commented Nov 1, 2025

image

It could work.. but I think it's to punchy and to close to the content.

I will leave it at the top, until I find a better way to display it. Maybe the status bar which is almost empty might be a good place in the future

With the bar aligned to the right there is no need for the icon anymore
@sudo-tee sudo-tee merged commit 36f609d into main Nov 3, 2025
10 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants