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 14:08:44 +0200 Message-ID: <87tvsb2w1f.fsf@mouse.gnus.org> References: <87zi23bg67.fsf@gmail.com> <87o9ij4e12.fsf@mouse.gnus.org> <87wox7bdr7.fsf@gmail.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1523880460 5195 195.159.176.226 (16 Apr 2018 12:07:40 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 16 Apr 2018 12:07:40 +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 14:07:36 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 1f82uz-0001Ce-5a for ged-emacs-devel@m.gmane.org; Mon, 16 Apr 2018 14:07:33 +0200 Original-Received: from localhost ([::1]:41736 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f82x3-00045k-UK for ged-emacs-devel@m.gmane.org; Mon, 16 Apr 2018 08:09:41 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55590) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f82wn-00043F-LH for emacs-devel@gnu.org; Mon, 16 Apr 2018 08:09:27 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1f82wj-0005Os-Kr for emacs-devel@gnu.org; Mon, 16 Apr 2018 08:09:25 -0400 Original-Received: from hermes.netfonds.no ([80.91.224.195]:52644) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1f82wj-0005Nv-EG for emacs-devel@gnu.org; Mon, 16 Apr 2018 08:09:21 -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 1f82we-0001JJ-Uz; Mon, 16 Apr 2018 14:09:19 +0200 Original-Received: from larsi by corrigan with local (Exim 4.89) (envelope-from ) id 1f82wB-0006dY-1A; Mon, 16 Apr 2018 14:08:47 +0200 In-Reply-To: <87wox7bdr7.fsf@gmail.com> (Pierre Neidhardt's message of "Mon, 16 Apr 2018 16:48:52 +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:224637 Archived-At: Pierre Neidhardt writes: >>> - 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? > > Emacs (and all GNU) mailing list archives for a start! :) > Many websites use increments in URL while they forget the previous/next > hint. Hm... The numbers in the URLs often (usually) don't refer to the next/previous article, but are a global thing that count upwards. But perhaps it'll work out nice on many web sites. I'm not against adding this and see how it works out. If it turns out to be less than helpful, we can remove it again. >>> - 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. > > Sorry, I meant when there is no link under point. > Right now there is no way to just open a new eww buffer. Oh, I see. Yes, that's a 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. > > Why not useful? Because the vast majority of users won't create such a function. It's more useful (i.e., for more people) if things work the way it should be default. > `eww-add-bookmark' already does duplicate detection, except that it's > very dumb: it won't realize if two bookmarks are the same up to the > protocol. But then it should be smarter, I think. :-) >> 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. > > Maybe I should have explained the overall bookmark logic beforehand :p > > - "tags" are optional words used to categorize bookmarks, e.g. "cinema", "emacs", > "books". They can be used to filter & lookup bookmarks. > > - "mark" serves two purposes: it allows to open a link with a simple > keybinding (optional) + it serves as a prefix for search engines (in > which case it's no longer optional). For example, say github has mark > "gh", then > > M-x eww RET gh > > opens github, so does `C-c e g h' if `C-c e' is quickmark prefix key. > If github comes with a search engine `:search "/search?q=%s", then > > M-x eww RET gh foobar > > opens a github search query of "foobar". Ah, I see. Yes, that sounds very nice and useful. >>> - 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? > > We could also do, but that does not compose as well as my suggestion. > For instance, how would you filter bookmarks by tags? Add a "narrow to tag" command to the mode? >> 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... > > I am assigned to Emms, does it count? Hm... If it's specific to Emms, I don't think it's enough? Anybody know? -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no