Different prompt for breakpoint

[mrak]

I like to be able to have prompt for a stopping at a breakpoint be different than the default. Like showing function/line number, for instance.

If there is a way to detect that you are in a "breakpoint reached" mode either through the status builtin or some other method would be great :)

Right now it's hard to see the difference between the prompt being normal and one with a breakpoint's context available

[zanchey]

Seems like a good idea!

[ElijahLynn]

I like the idea of the prompt changing to the line number when paused!

[ridiculousfish]

This sounds good to me too.

[faho]

This probably won't happen for 2.3.0, retargeting.

[krader1961]

Adding a status is-breakpoint is trivial (I already have it working). But while testing it I noticed that I can type breakpoint at an interactive prompt. Which doesn't report an error but does set $status to one. It also pushes a breakpoint block on the parser stack. That's definitely a bogosity. It shouldn't be possible to execute that command interactively. Once I merge this it will be easy enough to do something like this in fish_prompt:

if status is-breakpoint
    echo (status current-function):(status current-line)
end

Do we want to add a fish_breakpoint_prompt, analogous to fish_mode_prompt, that is always added to the output of fish_prompt? Or do we want to define a new prompt function that is used when status is-breakpoint is true rather than fish_prompt? Or, perhaps use fish_breakpoint_prompt as a substitute for fish_right_prompt if we're inside a breakpoint?

[krader1961]

I found another bug. The breakpoint command is not a no-op in non-interactive shells.

[zanchey]

I think fish_breakpoint_prompt is a sensible idea; there's really no reason for it to be the same as fish_prompt and that confused the heck out of me the first time I used a breakpoint.

[krader1961]

I'm leaning towards using fish_breakpoint_prompt as a replacement for fish_right_prompt (rather than fish_prompt) when in breakpoint context. That's because a) I suspect few people are using a right prompt and b) those that are using one are likely displaying information like the current time that isn't interesting when debugging. Having to duplicate large parts of the left prompt in a debug prompt is likely to be more painful. I would also consider naming this new function fish_debug_prompt but I like the obvious tie to the breakpoint command by naming it fish_breakpoint_prompt.

[krader1961]

On the other hand using a custom right prompt and leaving the left prompt the user's standard prompt may not make the fact we're in the debugger sufficiently clear. Nonetheless, I'm going to implement it as a right prompt replacement. We can easily change it to be a left prompt replacement if user feedback suggests that is necessary.

[krader1961]

I've tested using the breakpoint prompt as an alternative right prompt. This is probably not viable because the length of the debug prompt is likely to be long enough that the entire right prompt gets suppressed. Even if we only display the function name and line number. It's practically certain to be suppressed if we include the filename -- even if just limited to a fraction of the pathname. I tested this on a terminal 90 chars in width with a moderately long left prompt. So the debug prompt will have to be an alternative for the left prompt. If people want to include components of their left prompt in the debug prompt they will have to define their own fish_breakpoint_prompt function.

[krader1961]

Note that we need a way to get the context in which a breakpoint command was executed. The current status current-* functions do not provide this. So I'm going to add -B / --breakpoint flags to specify that is the context of interest when executing status. At this time the proposed debug prompt out for review does not provide the correct context. Thus that change is a proof of concept intended to verify the basic approach. That is, using an alternative left prompt and using the fish_color_status var when displaying breakpoint context.

[krader1961]

For those keeping track I have merged changes which will result in a distinct fish prompt when asking for user input in the context of a breakpoint. The information in that prompt will be incorrect because we currently do not have a way to get the correct information from within a prompt function. While imperfect this is a huge improvement over the previous situation which presented the user with a prompt that was extremely misleading.

[krader1961]

Closing this issue since I've fixed it. The user now sees a very distinctive prompt when a breakpoint command is executed. That prompt includes the correct function name and line number of the breakpoint.

There is more work to be done to make status useful in other contexts such as a hypothetical trap DEBUG context which would allow creating more flexible alternative to the set -x of other shells. But that work isn't relevant to this issue.

[hellow554]

Although it's closed for 2 years, the documention states otherwise: https://fishshell.com/docs/current/index.html#debugging

Note: At the moment the debug prompt is identical to your normal fish prompt. This can make it hard to recognize that you've entered a debug session. Issue 1310 is open to improve this.

[krobelus]

@hellow554 right, fixed in 5ce4cb6