From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Pierre Neidhardt Newsgroups: gmane.emacs.devel Subject: Re: EWW improvements: open in new buffer, tags, quickmarks, search engines, ... Date: Mon, 16 Apr 2018 16:48:52 +0530 Message-ID: <87wox7bdr7.fsf@gmail.com> References: <87zi23bg67.fsf@gmail.com> <87o9ij4e12.fsf@mouse.gnus.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Trace: blaine.gmane.org 1523877640 2260 195.159.176.226 (16 Apr 2018 11:20:40 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 16 Apr 2018 11:20:40 +0000 (UTC) User-Agent: mu4e 1.0; emacs 26.1 Cc: emacs-devel@gnu.org To: Lars Ingebrigtsen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Apr 16 13:20: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 1f82BW-0000Qb-0t for ged-emacs-devel@m.gmane.org; Mon, 16 Apr 2018 13:20:34 +0200 Original-Received: from localhost ([::1]:38009 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f82Dc-0005hg-O8 for ged-emacs-devel@m.gmane.org; Mon, 16 Apr 2018 07:22:44 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51385) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f82A2-00032G-Cq for emacs-devel@gnu.org; Mon, 16 Apr 2018 07:19:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1f829x-00051l-6i for emacs-devel@gnu.org; Mon, 16 Apr 2018 07:19:02 -0400 Original-Received: from mail-pl0-x22a.google.com ([2607:f8b0:400e:c01::22a]:36966) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1f829w-00051T-UJ for emacs-devel@gnu.org; Mon, 16 Apr 2018 07:18:57 -0400 Original-Received: by mail-pl0-x22a.google.com with SMTP id f7-v6so2806209plr.4 for ; Mon, 16 Apr 2018 04:18:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=references:user-agent:from:to:cc:subject:in-reply-to:date :message-id:mime-version; bh=e+lSvc14kE+5lAlpJizRBk40cBjBOWpSwwMMGcaM9qU=; b=WvE2ILOmMKQPss6wui59p2fQvwb4x/JXG/eLhJaD4qToQpj/ELaG+pmh+2SQrJl53d K04YAeF6f6W6oO/kDM/mRvcByzRuAz0iPIVI8m8WsX4zsjNA5BmUT9mEA8QZ1SG3s4hG mLeP19ut47PbqsKEQdlyhWUAFbcsnaoS/UVmSEgI9Kk6IHkhZ0ykmocOq0tmYCXHvSCE kasILjU12jbRhZAI3pJw/OGrNYPx5/pXkLsH4OOgHfL/FefzgvIWsY2IDvpNOu1HafQ0 Rn33g6keh5LucqHhB7APLdPwDRucmUPmqwRmaBNS31Q4ctpW/i1/kClUUexpEDACmcfY Vmjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:references:user-agent:from:to:cc:subject :in-reply-to:date:message-id:mime-version; bh=e+lSvc14kE+5lAlpJizRBk40cBjBOWpSwwMMGcaM9qU=; b=YGAE/kJE5EwmarUqx5KHPqGkpdIH1e7NQF5bXsaKyfers3gHIPyxUgKyT3hNvaJY5i 7hATLTzwHmMmN/TSiUTCuoHy/p98XTSf6AyNNYbw/3LCDecAY+6Ap99rzCPaP7m2/IzI OFnPGFWICV/fgay9SJktmhRYZQVJ+NHLnFC6wYtKxyBypVOCsGj4dQnqx8kh3MBZWzeD 9wZizL1GXs6peNIuFU6JoZAsvl03secFGO/85+RJx/kCUe3x4vzne1NlEp222rAPzXPN m8wmfU8YBTqV+v/p2AU7mq2elsTEwW7NaePzZRJFkEc7utrXRMNSB4z3j3YJXrpLiW6T cOPQ== X-Gm-Message-State: ALQs6tCFT6BnJslvYP/8aXMGF1BjDz2K8Rv7HKSG9pKT5bLGlHKZp3Bv iG+PKLCueL43wzzGvlP+4AhvqcHO X-Google-Smtp-Source: AIpwx4/jdPNvd4lVYPSgsqM0m3Dacl9ce3R3T6ZDwjo/Qv9vaW4erZRlO1n70xohcrn2g1IHNPNnXw== X-Received: by 2002:a17:902:6ac3:: with SMTP id i3-v6mr9203929plt.142.1523877535795; Mon, 16 Apr 2018 04:18:55 -0700 (PDT) Original-Received: from mimimi ([103.61.255.46]) by smtp.gmail.com with ESMTPSA id b62sm5815032pfk.24.2018.04.16.04.18.53 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 16 Apr 2018 04:18:55 -0700 (PDT) In-reply-to: <87o9ij4e12.fsf@mouse.gnus.org> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:400e:c01::22a 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:224635 Archived-At: --=-=-= Content-Type: text/plain Lars Ingebrigtsen 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. >> - 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. >> - 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). Sure. >> - 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? `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. The command would obviously explain what's wrong when erroring out. >> - 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. 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". The point of centralizing search engines, quickmarks and bookmarks is that it makes it easier to configure and, most importantly, it allows for searching for all URLs at the same spot (name the bookmarks). >> - 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. See my previous comment. I think this is actually simpler that adding search engine support with seperate functions and variables. With my suggestion we re-use the current implementation without adding any new variable / function. >> - 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? Narrowind and sorting would not be enough. >> - 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. The description is, but in practice it's crystal clear and always does what you want. > 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? -- Pierre Neidhardt --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEUPM+LlsMPZAEJKvom9z0l6S7zH8FAlrUhpwACgkQm9z0l6S7 zH+YrggApRUR2sHHaX9+YSzIGvLQfEeOAYLPcdIMgNWhkQ2SkB2d4hCA5AFNh3Jj b1m4cSYply+GpS9rOIdjtp7eVcfyQRwlGUj2j+951KaCYQHQnbFkSM3qfgMb0bJH BjwukMCUidSkGKEOkm321aSCe8izefWSExSfVHolOHbALPaNfwS78syPftvqMAmL jhcJD4Y7/81YMubHbg6Luw3Slp9V1XnOd+bmg+QfGsrpdvcCtOzYNNm7Q6uoEU8i g5o8lvpUZAR1mtdvLoC2kbruCJPJRz/JKALhe5HcUMQ4aT5ydTrO9ubsMXADUvz9 UD5rgg8eCC15p6/QRIBu9thftDRhaQ== =+Bds -----END PGP SIGNATURE----- --=-=-=--