From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Tassilo Horn Newsgroups: gmane.emacs.devel Subject: Re: Conkeror-like functionality for EWW Date: Wed, 05 Nov 2014 13:19:02 +0100 Message-ID: <87zjc57scp.fsf@thinkpad-t440p.tsdh.org> References: <87vbtdz513.fsf@gmail.com> <87oasobdtl.fsf@lifelogs.com> <87r3xjz6qf.fsf@thinkpad-t440p.tsdh.org> <87h9ye3q90.fsf@thinkpad-t440p.tsdh.org> <87egth99rp.fsf@thinkpad-t440p.tsdh.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1415190016 19548 80.91.229.3 (5 Nov 2014 12:20:16 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 5 Nov 2014 12:20:16 +0000 (UTC) Cc: emacs-devel@gnu.org To: Andrey Kotlarski Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Nov 05 13:20:06 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XlzZF-0007da-EW for ged-emacs-devel@m.gmane.org; Wed, 05 Nov 2014 13:20:05 +0100 Original-Received: from localhost ([::1]:45996 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XlzZE-0005fO-VT for ged-emacs-devel@m.gmane.org; Wed, 05 Nov 2014 07:20:04 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37936) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XlzZ2-0005f3-CS for emacs-devel@gnu.org; Wed, 05 Nov 2014 07:20:00 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XlzYu-0002WV-Rx for emacs-devel@gnu.org; Wed, 05 Nov 2014 07:19:52 -0500 Original-Received: from deliver.uni-koblenz.de ([141.26.64.15]:57508) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XlzYu-0002WJ-M1 for emacs-devel@gnu.org; Wed, 05 Nov 2014 07:19:44 -0500 Original-Received: from localhost (localhost [127.0.0.1]) by deliver.uni-koblenz.de (Postfix) with ESMTP id 6999C1A8417; Wed, 5 Nov 2014 13:19:39 +0100 (CET) X-Virus-Scanned: amavisd-new at uni-koblenz.de Original-Received: from deliver.uni-koblenz.de ([127.0.0.1]) by localhost (deliver.uni-koblenz.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4maOtuUrlKSs; Wed, 5 Nov 2014 13:19:39 +0100 (CET) X-CHKRCPT: Envelopesender noch tsdh@gnu.org Original-Received: from thinkpad-t440p.tsdh.org (dhcp133.uni-koblenz.de [141.26.71.133]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by deliver.uni-koblenz.de (Postfix) with ESMTPSA id 6E45D1A846B; Wed, 5 Nov 2014 13:19:02 +0100 (CET) In-Reply-To: (Andrey Kotlarski's message of "Wed, 05 Nov 2014 14:00:38 +0200") User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/25.0.50 (gnu/linux) Mail-Followup-To: Andrey Kotlarski , emacs-devel@gnu.org X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 141.26.64.15 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:176394 Archived-At: Andrey Kotlarski 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