Re: Conkeror-like functionality for EWW

[Tassilo Horn <tsdh@gnu.org>]

Andrey Kotlarski <m00naticus@gmail.com> writes:

>> Well, a user might know what he's looking for.  Or do you mean that
>> statement in a more technical sense?
>
> If there are matches further down, they have to be shown somehow so
> user doesn't blindly RET on the first without knowing what it is.
> This interface makes sense only on visible part of page.

Yes, sure.  So matches further down have to be made visible, e.g., by
excluding lines/links that don't match the current input string.  That
is, `f i' might not show the ImageMagick link already but further typing
`f imag' probably does.

>> In the latter case, `helm-occur' does something similar namely
>> dynamically narrowing down a buffer to lines that match a given regex
>> as you type it.  It does that in a separate buffer and prefixes the
>> the matching lines with some metadata (file, line), but I think that
>> should be doable also on the current buffer.
>
> helm-occur is very nice (probably even separate help-eww-links source)
> but it shows just one line context and somewhat restricted way to jump
> directly to particular match if many.  It is good in many cases but
> sufficiently different than the conkeror-style interface to somehow
> combine them.

Agreed.  I just wanted to point out that narrowing down to show only
lines with links that match a given input in a dynamic as-you-type
manner looks feasible.  Of course, it would still be nice to have
conkeror-style numbers and the first matching link selected.

> By the way helm integration is something I'd like to do for the
> eww-lnum-universal command where link/form/button is first selected
> and then number of actions offered.

Yeah, cool.

Bye,
Tassilo