From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Lars Ingebrigtsen Newsgroups: gmane.emacs.devel Subject: Re: EWW improvements: open in new buffer, tags, quickmarks, search engines, ... Date: Mon, 16 Apr 2018 12:54:49 +0200 Message-ID: <87o9ij4e12.fsf@mouse.gnus.org> References: <87zi23bg67.fsf@gmail.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1523875994 18068 195.159.176.226 (16 Apr 2018 10:53:14 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 16 Apr 2018 10:53:14 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: emacs-devel@gnu.org To: Pierre Neidhardt Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Apr 16 12:53:10 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1f81kz-0004cO-D7 for ged-emacs-devel@m.gmane.org; Mon, 16 Apr 2018 12:53:09 +0200 Original-Received: from localhost ([::1]:36474 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f81n6-00038n-0Q for ged-emacs-devel@m.gmane.org; Mon, 16 Apr 2018 06:55:20 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37951) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f81mu-00036u-70 for emacs-devel@gnu.org; Mon, 16 Apr 2018 06:55:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1f81mr-0005LB-57 for emacs-devel@gnu.org; Mon, 16 Apr 2018 06:55:08 -0400 Original-Received: from hermes.netfonds.no ([80.91.224.195]:51011) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1f81mq-0005K6-SK for emacs-devel@gnu.org; Mon, 16 Apr 2018 06:55:05 -0400 Original-Received: from 46.67.12.60.tmi.telenormobil.no ([46.67.12.60] helo=corrigan) by hermes.netfonds.no with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1f81ml-0001Ez-89; Mon, 16 Apr 2018 12:55:01 +0200 Original-Received: from larsi by corrigan with local (Exim 4.89) (envelope-from ) id 1f81mb-0006NX-Th; Mon, 16 Apr 2018 12:54:49 +0200 In-Reply-To: <87zi23bg67.fsf@gmail.com> (Pierre Neidhardt's message of "Mon, 16 Apr 2018 15:56:40 +0530") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 80.91.224.195 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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" Xref: news.gmane.org gmane.emacs.devel:224634 Archived-At: Pierre Neidhardt writes: > I've recently hacked around EWW and since it's coming into good shape > I'm thinking of committing this upstream. > > Before sending a patch, here is the current state of my hacks: Please send separate patches for each feature. :-) > - Add `eww-copy-page-title' that mirrors `eww-copy-page-url', it's > useful enough. Yup. > - Enhances eww-next-url / eww-previous-url so that when there is no next / > previous links, it tries to increment / decrement the last number in > the last element of the URL. ("do what you mean" style.) Hm... Are there many web sites where that is meaningful? > - Add a `eww-reload-all' command to reload all *eww* buffers, it's > useful when using desktop-mode but when `eww-restore-desktop' is nil. Sure. > - Make `eww' so that the default value is in the prompt, ready to be > edited by the user. Very convenient in my opinion. No, that's against Emacs' convention for prompting. The default is always stashed in `M-n'. > - Change `eww-open-in-new-buffer' so that it queries for a URL instead > of cloning the current buffer (which is not very useful in my > opinion). That's not what it's supposed to do -- it opens the link under point in a new buffer. > - Make eww-update-header-line-format also update the buffer name so that > it contains the page title. _Very useful_ to browse / search *eww* > buffers (think Ivy/Helm). Sounds nice, but also sounds like something not everybody would want, so it should have a configuration option to switch on/off (but can default to on). > - Ask for tags when saving a bookmark. Tags are stored under the key > :tags as a list of strings. Good idea. > - Make `eww-add-bookmark' run a customizable function to decide when. > to error out. For instance, error out when a duplicate is detected > with protocol stripped out (https://foo.bar is seen as a duplicate of > http://foo.bar). Hm... Doesn't really sound all that useful? But having that command give feedback (and perhaps query the user about what to do) in that situation would be handy. > - Make `eww-write-bookmarks' run a customizable function before saving > the file. That function can be used, for instance, to detect > duplicates or to sort the bookmarks. This would make the eww-bookmarks > file more friendly to versioning. Sure. > - Bookmarks can have a mark which is a string saved under the key :mark. > The mark should be unique. It could be used like the "quickmark" > function found in some browsers: use it to quickly load a > bookmark. (Work in progress.) A mark in addition to a tag? Sounds like a bit more than most users would want to invest in a bookmarking system, but I don't object. > - Bookmarks can have a search engine which is either appended to the > bookmark' URL if it does not start with "https?://", or used as-is > otherwise. > The search engine is stored as a string under the key :search. > A "%s" must be present in the search engine string as a place-holder > for the query. Hm. Sounds more complicated than users will want to do to me. > - Make `eww-bookmark-prepare' only load bookmarks from file if not > already set. This makes it possible to display a custom / narrowed > list of bookmarks in the bookmark buffer. I don't quite follow... What about just adding narrowing and sorting to that mode? > - Make `eww-bookmark-prepare' display the mark, the tags and the search > engine, if available. Work in progress. I'm thinking of using a > different face for the mark if a search engine is present. Sure. > - Add a `eww-bookmarks-by-tags' command which queries the user for a > completing list of tags and then displays a bookmark buffers of all > the bookmarks which match the tags. The matching can be either > inclusive or exclusive (bookmarks which match at least one tag vs. all > of them). Sounds nice. > - Make `eww--dwim-expand-url' follow a different logic to bind it all together: > > - With a multi-word query, if first word is a mark of a bookmark with a search engine, > then use the said search engine over the rest of the query. > > - With a single word query, if first word is a mark then open the > corresponding bookmark. > > - Else query the default search engine. Sounds confusing. :-) But also quite DWIM, which I like. > - Fix `eww-forward-url' as it seems to corrupt the history. (Work in progress.) > > Of course in its present state my hacks are what they are, very hacky. > It needs to be made more customizable and interfaceable. > > What do you think? Sounds great to me. :-) Make each thing into a patch (with documentation) and let the apply-to-Emacs-fest commence. That is, if you've been through the assign-copyright-to-the-FSF-process. I don't see you in the copyright.list file, but that's apparently out of date these days... -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no