Re: EWW improvements: open in new buffer, tags, quickmarks, search engines, ...

[Lars Ingebrigtsen <larsi@gnus.org>]

Pierre Neidhardt <ambrevar@gmail.com> 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