Skip to content

default insert mode for the overlay#161

Closed
aakash2330 wants to merge 1 commit intoThePrimeagen:masterfrom
aakash2330:aakash/default-insert-mode
Closed

default insert mode for the overlay#161
aakash2330 wants to merge 1 commit intoThePrimeagen:masterfrom
aakash2330:aakash/default-insert-mode

Conversation

@aakash2330
Copy link

@aakash2330 aakash2330 commented Mar 16, 2026

opens the overlay in insert mode by default so you can start typing right away.

Copy link

@cursor cursor bot left a comment

Choose a reason for hiding this comment

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

Cursor Bugbot has reviewed your changes and found 1 potential issue.

Fix All in Cursor

Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.

)
end

vim.cmd("startinsert")
Copy link

Choose a reason for hiding this comment

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

Insert mode forced on read-only select input overlay

High Severity

vim.cmd("startinsert") is added unconditionally in capture_input, but capture_select_input also calls capture_input and then makes the buffer read-only and non-modifiable via a vim.scheduled on_load callback. This puts the user in insert mode on a buffer that immediately becomes non-modifiable, causing errors when typing and breaking the selection workflow. The startinsert call needs to be conditional or moved to only the text-input callers.

Additional Locations (1)
Fix in Cursor Fix in Web

)
end

vim.cmd("startinsert")
Copy link

Choose a reason for hiding this comment

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

Bug: capture_input unconditionally enters insert mode, which breaks capture_select_input's read-only selection window by putting the user in insert mode instead of normal mode for navigation.
Severity: HIGH

Suggested Fix

The call to vim.cmd("startinsert") should be conditional. It should only be executed for input buffers, not for selection buffers. This could be controlled by a new option in the opts table passed to M.capture_input.

Prompt for AI Agent
Review the code at the location below. A potential bug has been identified by an AI
agent.
Verify if this is a real issue. If it is, propose a fix; if not, explain why it's not
valid.

Location: lua/99/window/init.lua#L549

Potential issue: The function `M.capture_input` is modified to always call
`vim.cmd("startinsert")` before returning. However, this function is also used by
`M.capture_select_input` to create a read-only selection window. Due to a timing issue
with `vim.schedule`, the user is placed in insert mode *before* the buffer is made
read-only by the `on_load` callback. This leads to a broken user experience in selection
windows, where users expect to navigate in normal mode but are instead in insert mode.
Any attempt to type will result in an `E21: Cannot make changes, 'modifiable' is off`
error once the buffer becomes non-modifiable.

Did we get this right? 👍 / 👎 to inform future reviews.

@ThePrimeagen
Copy link
Owner

yeah, i dont think i like this.

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.

2 participants