Mark added to first line of multiline prompt.

I use a multi-line prompt (see attached), and iTerm2 puts the mark at the first line instead of the last.

OSX 10.10.4 iTerm2 Build 2.9.20150626

com.googlecode.iterm2.plist

This is kind of intended, although it looks bad with your prompt. I'm not sure what the right fix is for this--some prompts look better with it on the first line of the multiline prompt so I can't please everyone.

Milestone changed to Future Release

I can't please everyone.

I hear that!

Could iTerm watch for a special character or escape code to position the mark on that particular line? Default to first line, unless it sees the code?

Milestone changed to Feature Complete 3.1

@dansherman Instead of relying on the default shell integration script, I'm wondering if you could just go ahead and manually create your own preferred PS1, containing your own stuff and the iterm-specific stuff in the order that best suits your needs?

Unfortunately we don't respect our own escape codes :( The shell integration codes are:

OSC 133 ; A: Start of prompt OSC 133 ; B: End of prompt OSC 133 ; C: Start of command output OSC 133 ; D: End of command output

What Dan wants is the A code to occur in the middle of his prompt. Unfortunately we don't record the location of the D code (I assumed it would always be adjacent to A). Things like "copy output of last command" will do the wrong thing if they're not adjacent. I hope to fix this in 3.1 so that you can put OSC 133; A in your prompt and we'll detect it and not add it in the shell integration script.

Despite I don't see much value in having it as the first line instead the last line of the prompt, here are a couple of simple solutions that could work for everybody, and should not be difficult to implement.

1. a simple preference setting (maybe in the Advanced section), where the user can specify whether he want the mark on the first line or the last line of his prompt. Something like "marks on the last line of the prompt" defaulted to false to ensure current behaviour.

2. a simple preference setting (maybe in the Advanced section), where the user can specify a "offset lines" integer. Defaulted to 0 will emit the mark at the first line, but for multi-line prompts, the user may want to set it as the second or third, or whatever line of his prompt.

The second solution is more flexible, but the first could work as well. Please, implement whatever is simpler for you ;).

Thanks for your wonderful job!

@gnachman: A possible workaround (waiting for a proper implementation) is switching the escape sequences of "iterm2_prompt_start" and "iterm2_prompt_end". That are defined in the shell integration script.

I don't know the other possible implications of that hack, but the behavior is that it correctly marks the last line instead of the first line of a multi-line prompt.

I can appreciate the coolness of the marking feature now that I see the mark on the same line of the issued command! :)

And while at it... just a minimal suggestion...

While the mark of a failed command is correctly rendered in red color, while the mark of a successful command is blue? Aren't we all used to see green for OK and red for NOT OK?

IMO a green color would just feel more right in that context.

Milestone changed to Feature Complete 3.2

I'd just like to chime in that I have the same issue, and this was the only other reference I could find to it.