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

[Pierre Neidhardt <ambrevar@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 5058 bytes --]


Lars Ingebrigtsen <larsi@gnus.org> 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


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]