Amp-like jump: remove not relevant overlays after keypress

[perehonchuk]

Old behavior:
open flake.nix -> gw -> helix displays overlays -> press d -> nothing happens -> press e -> helix jumps to .github
https://asciinema.org/a/XblDIDlaqWZ2IWcu07MPiHYGc
New behavior:
open flake.nix -> gw -> helix displays overlays -> press d -> helix removes all overlays which starts not from d -> press e -> helix jumps to .github
https://asciinema.org/a/d0EGCC2I4wnPacqYhywqBNNPh

[the-mikedavis]

I think it's a little disorienting to modify the label that you're trying to jump to. Instead we could remove the labels that can no longer be entered but keep the rest unmodified

[perehonchuk]

I think it's a little disorienting to modify the label that you're trying to jump to. Instead we could remove the labels that can no longer be entered but keep the rest unmodified

Personally I prefer the option I implemented.
But I don't have a strong opinion regarding it, so I updated PR with your suggestions. Please check-out updated asciinema link https://asciinema.org/a/d0EGCC2I4wnPacqYhywqBNNPh

[mandx]

Nitpick: To me what's disorienting about removing inaccessible jump labels is that, since there are now a lot less jump labels on the screen, it's now less clear the current view is in "jump mode" (and IMO the gw on the bottom right corner is still easy to miss).

[perehonchuk]

Nitpick: To me what's disorienting about removing inaccessible jump labels is that, since there are now a lot less jump labels on the screen, it's now less clear the current view is in "jump mode" (and IMO the gw on the bottom right corner is still easy to miss).

well :) the same would be true about many mods. Sometimes I forget that I am in visual mode. Good news that it will quit after any non-existing jump

[clo4]

I can entirely understand why this would be a feature that you'd like!

Personally, I wouldn't want this even with the change of removing the labels you're not jumping to. For context, if I'm using my browser, I'm using the Rango extension to click, and when using my operating system I'm using Homerow to click. Neither of them remove labels when you're typing - they only make a visually minor change to the labels you're jumping to. As far as I can tell this is basically just for people that may be watching along on a screencast, as opposed to being for the person actually clicking.

The way I use a feature like this (and I think most people do this too) is that I look at the thing I want to jump to, read the letters, then type the letters. There's not a middle step of typing one letter, seeing what's left, then typing that. As such it makes sense to minimize the amount of change on screen while you're half typed so you don't get what feels like a flicker.

Hope that made sense. That's just my thoughts on this, and while I have a preference for this I don't have a problem with this being implemented if it turns out more people do want this than not :)

[aukeroorda]

To me it feels more like proper responsiveness than a flicker- you immediately see whether you typed the correct/intended first character, but I agree that the two key presses of the jump follow eachother quite rapidly, so it might be best if this highlight change follows a same approach as the mini modes, where the menu is only shown if the following keypress is delayed by 100ms or so.

[perehonchuk]

I can entirely understand why this would be a feature that you'd like!

Thanks for you feedback. For me it looks like a natural UI thing, when you have an action you should have a response. Otherwise how could I know I pressed the button? In your case Rango did exactly this. And my PR trying to do the same. The only difference that Rango does it by changing the font properties. Which is basically the same "flickering".

The way I use a feature like this (and I think most people do this too) is that I look at the thing I want to jump to, read the letters, then type the letters. There's not a middle step of typing one letter, seeing what's left, then typing that.

My workflow is quite different. I briefly look into the area I wanna jump, find the first letter, press it, wait till the document clean-ups from extra information, find the second letter and press it. This way it is much easier (for me) to navigate in a dense document, like

[the-mikedavis]

I look at the thing I want to jump to, read the letters, then type the letters

This is the exact workflow I have in mind for the feature.

I briefly look into the area I wanna jump, find the first letter, press it, wait till the document clean-ups from extra information, find the second letter and press it

This is strictly slower and more mentally taxing. You're meant to look at an area you want to jump to, pull up the jump labels and read and type only the closest one to where you intend to jump.

Improving the UI so that it's clearer that you've hit the right first character seems nice-to-have but not at the cost of making the intended workflow worse. I'll try this locally for a while and see if the disappearing labels are still distracting.

[the-mikedavis]

Passing in the char isn't necessary. Instead you can enumerate before passing the iterator to the helper function:

let overlays = labels_to_overlays(
    labels.iter().enumerate().skip(outer).take(alphabet.len()),
    alphabet,
    doc!(cx.editor, &doc).text().slice(..),
);
doc_mut!(cx.editor, &doc).set_jump_labels(view, overlays);

[the-mikedavis]

This can move within the jump_to_label function. See

helix/helix-term/src/commands/lsp.rs

Lines 317 to 339 in 545ff1a

	pub fn symbol_picker(cx: &mut Context) {
	fn nested_to_flat(
	list: &mut Vec<SymbolInformationItem>,
	file: &lsp::TextDocumentIdentifier,
	symbol: lsp::DocumentSymbol,
	offset_encoding: OffsetEncoding,
	) {
	#[allow(deprecated)]
	list.push(SymbolInformationItem {
	symbol: lsp::SymbolInformation {
	name: symbol.name,
	kind: symbol.kind,
	tags: symbol.tags,
	deprecated: symbol.deprecated,
	location: lsp::Location::new(file.uri.clone(), symbol.selection_range),
	container_name: None,
	},
	offset_encoding,
	});
	for child in symbol.children.into_iter().flatten() {
	nested_to_flat(list, file, child, offset_encoding);
	}
	}

which is similar

Then alphabet_char can live within this function as it was prior to this change:

let alphabet_char = |i| {
    let mut res = Tendril::new();
    res.push(alphabet[i]);
    res
};

[bjorn-ove]

For what it's worth, my workflow is also to locate where I want, and then press both keys in rapid succession.

[yerlaser]

I don't want to speak against this change, perhaps people who type slowly might appreciate it, but for me it really has no meaning. Like others mentioned earlier, I note the two letters and type them almost simultaneously so I wouldn't notice if there were any ui changes in-between.
So, would be good to understand why you wait after pressing the first button?

[clo4]

Maybe there’s a middle ground here that could work for everyone: Could this be implemented using a timeout so there’s no change if the characters are typed within N ms of each other, and if the second character takes longer than N ms to be received then the labels are updated?

That allows us to not add a toggle option, and we can support both styles with hopefully minimal interruption.

… This is of course only if we want this added in the first place. I have no qualms with it being added but of course every change is some additional complexity to be managed by the maintainers.

[pascalkuthe]

Maybe there’s a middle ground here that could work for everyone: Could this be implemented using a timeout so there’s no change if the characters are typed within N ms of each other, and if the second character takes longer than N ms to be received then the labels are updated?

That allows us to not add a toggle option, and we can support both styles with hopefully minimal interruption.

… This is of course only if we want this added in the first place. I have no qualms with it being added but of course every change is some additional complexity to be managed by the maintainers.

Every new feature adds complexity to the codebase. I would rather keep a simple implementation

[HungryJoe]

To me, this seems like a good candidate for a plugin: It adds complexity to the editor in order to give some niche of users a better experience. I say this as someone who would greatly prefer the UX promised by this PR 😅

[k3d3]

I'm echoing other voices at this point, but I'm not a big fan of the labels disappearing. What might be better is, rather than removing all labels that don't start with "d", you could instead give "d" a different colour, and otherwise leave the rest untouched.

That gives visual feedback that 1) you've pressed one key so far, and 2) you've pressed the key you intended to press, all while not being distracting or causing a "flicker".

That said, I'm also one of those people who looks at a specific spot and types the label, so it probably wouldn't make too much of a difference to me either way.