Ha! you beat me to it :)

I don't think it's just the chrome dev tools term that drives this. I'm not sure "column" is intuitive.

But let's ask the users here to see what they think

Inline breakpoints is a lot clearer. Using the same name as the chrome tools for the same concept is a welcome bonus.

Inline breakpoint is pretty good, but maybe callback breakpoint is a good alternative. Depends on how it works. Is this specifically meant for debugging async calls or also for debugging one of many statements in a single line of code?

Thanks for the feedback.
If inline breakpoints is what the users expect we can change the name - it works for me.

Let's wait and try to get @weinand @roblourens feedback.

I'd go with Inline Breakpoint.

Inline Breakpoint has a broader sense in comparison to Column Breakpoint.

Also, it stays pretty agnostic in comparison to callback breakpoint, which could have sense only in the js world assuming this functionality will be used also with other languages.

Async point? Async debug?

@urbanit "Column breakpoints" are independent from any language (feature). You can set a column breakpoint even in Fortran 77 (but I doubt that they support an "async" language construct yet...)

We use the term "column" because the editor refers to the character positions within a line as "Columns":

I see your point @weinand . Despite the fact that editor refers to Col, term "Column" is kind of unfamiliar to, at least to me. But, you are right about the need of lang neutrality. I will go with Inline then. ;-)

positions within a line

aka inline

Inline is fine with me. Maybe "column breakpoints" is more of an implementation-focused term.

I have no strong feelings about this, so "Inline Breakpoint" is fine by me.
But changing the name of a feature needs appropriate communication.
@isidorn please plan and execute accordingly.

@weinand sure, I will change it everywhere in the UI and mention it in the release notes.
The only command id which has column breakpoint in it will stay the same editor.debug.action.toggleColumnBreakpoint to not break existing behavior. This is fine since it is not user facing most of the time.
Thanks

@isidorn I suggest to introduce a new command id with an appropriate name but keep the old id forever for backward compatability (like ‚workspaceRoot‘). Ideally the old name should not show up in the keyboard shortcuts UI.
Keeping only the old id is confusing and not really discoverable.

thank you for exploring this