Clicking a prompt line with no input shouldn’t move the cursor to the start of the input

Discussed in #11420

^{Originally posted by hlcfan March 12, 2026}

What do you want to change?

Context

I'm using starship prompt for the terminal, it shows a whole line for the prompt, e.g.

{username} {cwd} // prompt line
> ls -lah        // input

When I click on the prompt line, it moves the cursor to the beginning of the input. IMO, if the prompt line and input are at the same row, clicking on the prompt area should move the cursor to the start of the input. But if the prompt line is a separate line, it doesn't make sense to move the cursor to the beginning. One example, sometimes I double click on the prompt area to copy some text, then press cmd+v to paste to the end of current input line.

Screen.Recording.2026-03-12.at.10.09.07.PM.mov

Proposal

When the prompt area isn't in the same line as the input line, clicking the prompt area shouldn't move the cursor
[Current behavior] When the prompt area is in the same line as the input line, clicking the prompt area moves the cursor

Why do you want to make this change?

It prevents unexpectedly moving the cursor to the start of the input line when clicking on a dedicated prompt line.

I acknowledge that:

I have read the Contributing Guide and understand the contribution process.
I have read and agree to follow the AI Usage Policy.
I wrote this vouch request myself, in my own voice, without AI generating it.

I want to be specific that this should only be true for clicking on purely a prompt line. If a prompt line contains any input area, then we should still process prompt clicks.

I made some changes https://github.com/ghostty-org/ghostty/compare/main...hlcfan:ghostty:prompt-click-cursor-movement?expand=1 here, lemme know if this is good.

@hlcfan

Hey @hlcfan still catching up on how the code around your changes work but I tested this and I want to know if this is the behavior we want.

When we click on a word in the prompt area the fix behaves properly but when we click in the empty space of the prompt line the cursor still goes to the beginning. Is that space still "prompt area" because if it is then we're breaking the proposal requisite

When the prompt area isn't in the same line as the input line, clicking the prompt area shouldn't move the cursor

trimmed.mov

@jesusvazquez

Hi @jesusvazquez You're right, I should've checked the click pin's row.semantic_prompt instead of the cell.semantic_content. Can you pull the latest changes from the branch and build it?

Screen.Recording.2026-03-17.at.10.52.31.PM.mov

I tested again and that works perfectly for me 👍

I only have a one comment on this. I see rowAndCell() is called before the loop and right when it starts. This can be optimized. The first iteration of the loop could reuse click_rac.

@jesusvazquez

Removed the extra method call, thanks! @jesusvazquez

Right I think there is a tiny small imporvement over the existing code but I don't want us to do a full review in the issue. I was trying to help get your code function as stated in the issue and i think we're there now. Now you'd need to be vouched if you are not yet and then open a PR and we can do the rest of the improvements there.

That being siad click_rac is now a var so it leaks after the loop. You can do the following instead:

Make the click row a const
Keep an inner var for the row and cell which is the thing that you loop through.

const click_row = click_pin.rowAndCell().row;
if (click_row.semantic_prompt != .none) {
    var row_pin = click_pin;
    prompt: while (true) {
        const rac = row_pin.rowAndCell();
        const cells = row_pin.node.data.getCells(rac.row);
        for (cells) |cell| {
            if (cell.semantic_content == .input) break :prompt;
        }
        if (!rac.row.wrap) return .zero;
        row_pin = row_pin.down(1) orelse return .zero;
    }
}

@mitchellh

@mitchellh Please advise how to get a vouch from #11420.

@mitchellh Please advise how to get a vouch from #11420.

Oh my mistake, I misread the category. Vouching you now.

Any news on this? this is getting super annoying.
Any copy / paste inside terminal causing cursor jumps :(

Hi folks- any updates or status checks on this issue and PR?

Looks like this was already fixed. I can't reproduce it anymore in v1.3.1

I'm able to reproduce from https://github.com/ghostty-org/ghostty/commits/5f5b988c5 nightly build.

IMO, if the prompt line and input are at the same row, clicking on the prompt area should move the cursor to the start of the input.

Should it though?

One example, sometimes I double click on the prompt area to copy some text, then press cmd+v to paste to the end of current input line.

I use a one line prompt, and this exact thing still bites me every so often.

Any updates for 1.3.2?

Navigation Menu

Repository navigation

Clicking a prompt line with no input shouldn’t move the cursor to the start of the input #11462

Discussed in #11420

What do you want to change?

Context

Proposal

Why do you want to make this change?

I acknowledge that:

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Clicking a prompt line with no input shouldn’t move the cursor to the start of the input #11462

Description

Discussed in #11420

What do you want to change?

Context

Proposal

Why do you want to make this change?

I acknowledge that:

Activity

mitchellh commented on Mar 13, 2026

hlcfan commented on Mar 15, 2026

jesusvazquez commented on Mar 17, 2026

hlcfan commented on Mar 17, 2026

jesusvazquez commented on Mar 17, 2026

hlcfan commented on Mar 18, 2026

jesusvazquez commented on Mar 18, 2026

hlcfan commented on Mar 20, 2026

mitchellh commented on Mar 20, 2026

sielaq commented on May 7, 2026

rbelando commented on Jun 12, 2026

divijg19 commented on Aug 17, 2026

sergiocharpineljr commented on Aug 26, 2026

hlcfan commented on Aug 26, 2026

rgoya commented on Sep 18, 2026

rishangbhavsar commented on Oct 12, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions