all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: Pierre Neidhardt <ambrevar@gmail.com>
Cc: "Charles A. Roelli" <charles@aurox.ch>, emacs-devel@gnu.org
Subject: RE: EWW improvements: open in new buffer, tags, quickmarks, search engines, ...
Date: Wed, 25 Apr 2018 08:29:46 -0700 (PDT)	[thread overview]
Message-ID: <9d0ffd44-c4ee-4c56-b29a-fb61674588ec@default> (raw)
In-Reply-To: <87a7trydmp.fsf@gmail.com>

> > It seems a bit silly for EWW to have its own, limited form
> > of "bookmarking".  Perhaps it's time for it to graduate to
> > Emacs bookmarks?
> 
> You mean bookmark+, right?

No, there I meant Emacs normal bookmarks vs the
pseudo-bookmarks that EWW currently uses.

Bookmark+ uses normal Emacs bookmarks.  It does
provide additional features, some of which have
been mentioned (EWW support, tags, etc.).

But the point I was making there was that it seems
silly for EWW not to be using normal Emacs bookmarks.

The only reasons I can guess, so far, for why that
was done are (1) possibly the EWW author was not
familiar with Emacs bookmarks (but I doubt it) or
(2) there was a wish to let you keep EWW bookmarks
separate from other bookmarks.

#2 is not an issue at all with Bookmark+.  It lets
you have all kinds of bookmarks and yet keep them
as separate as you like.  It even has specific
"jumping" commands for different types of bookmarks,
e.g., complete only against names of bookmarks of
a specific type.  There is no problem of mixing or
not mixing EWW bookmarks with other bookmarks.

But perhaps the EWW author can defend his choice
not to use normal Emacs bookmarks for EWW?  Why go
against Occam's razor this way?  What's the advantage?

> As far as I understand, Emacs native bookmarks won't work with EWW.
> `M-x bookmark-set' complains the the EWW buffer does not point to a real
> file.

No, normal Emacs bookmarks do not need a file as
target.  Even vanilla Emacs can bookmark Dired and
Info nodes (albeit not so well).  A bookmark handler
can do anything you want it to do.

The point is that vanilla Emacs, out of the box,
provides a healthy framework for bookmarking.  That
includes the ability for anyone to define new kinds
of bookmarks.

Bookmark+ has defined new kinds of bookmarks, but
the framework (enhanced somewhat by Bookmark+) is
what Emacs provides.

My argument, first and foremost, is for EWW to use
Emacs bookmarks, not some ersatz, alternative
bookmarking system cooked up just for EWW.

Secondarily, I point out that Bookmark+ already
provides support for EWW using ordinary Emacs
bookmarks.  What it does could be incorporated as
is, or Emacs could look to its code for inspiration.
The code is available for GNU Emacs/FSF, if it wants.

> Thanks for all those good points.
> 
> For clarification, I never said I was opposed to bookmark+, I agree
> merging it (or parts of it) would probably be the best path to follow.
> I need to work on it.

Sounds good to me.  Let me know how I might help.

> That said, a few issues I can see at first glance:
> 
> - The package is published on Emacs Wiki.  There does not seem to be any
>   version control.

It could be included in Emacs itself, maintained by
Emacs.  For that, instead of requiring `bookmark.el',
its code that is needed would just be included in the
Bookmark+ files.  Bookmark+ subsumes `bookmark.el'.

I have no special need to maintain it.  I will do so,
if it's not included in Emacs.  And I might do so even
if it is included.  I still have improvements I want
to make to it, when I get time.  But a priori I have
no objection to Emacs taking it over.

As for the doc: The doc I have for Bookmark+ is in the
form of comments - Commentary in file `bookmark+-doc.el'.
You can see the doc as readable plain-text in Finder mode
by using `M-x finder-commentary bookmark+-doc.el'.

The same doc is also in the form of HTML on Emacs Wiki
(maintained there by hand).  If the doc is to be used
by Emacs it would presumably need to be converted to
texinfo/Info.  Or it could just be dropped, providing
only the doc strings.

I would not want to do the conversion to texinfo/Info.
I have no special expertise in that.  But I'd be glad
to help with any content questions or wording, if
needed.

> - It's under GPL license, but I wonder if the lack of version control
>   could hinder the copyright assignment process.  From the comments,
>   Drew Adams and Thierry Volpiatto seem to be the only two authors.
>   Drew, can you confirm?

I am the author, and have been from the outset, at
least as far back as 2004.  Thierry worked only on
a couple features for a few months in 2009.  Both
of us have signed FSF papers and have contributed
previously to GNU Emacs, AFAIK.  There's no problem
with our contributing.

> - The package is _huge_!  About 30k+ lines.  It might require a lot of
>   work to review it and to integrate the needed parts into Emacs.
> 
> What do you think?

23,114 lines, much of which is Commentary.
16,876 lines without comment-only or blank lines.
Much of the code is there to support multiple Emacs
versions.  The byte-compiled code is 950KB.

It's not difficult to integrate.  All that's needed is:

1. Integrate the little bit of `bookmark.el' code that
   is currently needed by `require'.  I've always tried
   to supplement, replacing something only when I needed
   to change its code.  At this point, there is little
   remaining of `bookmark.el' that is needed.

2. Remove support for older Emacs versions, if desired.
   I try to support as many older versions as possible,
   but Emacs doesn't do that.  (Bookmark+ currently
   works with Emacs releases back through Emacs 20.)

3. Remove optional support for other libraries when
   they are available in `load-path': soft-required
   e.g. (require 'thingatpt+ nil t) or via `fboundp'
   or `boundp'.



  parent reply	other threads:[~2018-04-25 15:29 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-16 10:26 EWW improvements: open in new buffer, tags, quickmarks, search engines, Pierre Neidhardt
2018-04-16 10:54 ` Lars Ingebrigtsen
2018-04-16 11:18   ` Pierre Neidhardt
2018-04-16 12:08     ` Lars Ingebrigtsen
2018-04-16 12:22       ` Pierre Neidhardt
2018-04-16 12:27         ` Lars Ingebrigtsen
2018-04-16 12:32         ` Lars Ingebrigtsen
2018-04-16 17:55           ` Eli Zaretskii
2018-04-17 11:18 ` Charles A. Roelli
2018-04-17 19:18   ` Pierre Neidhardt
2018-04-24  5:56     ` Pierre Neidhardt
2018-04-24 14:50       ` Lars Ingebrigtsen
2018-04-24 17:57         ` The importance of secrecy (was: EWW improvements: open in new buffer, tags, quickmarks, search engines, ...) Stefan Monnier
2018-04-24 19:45           ` The importance of secrecy John Wiegley
2018-04-24 20:16           ` The importance of secrecy (was: EWW improvements: open in new buffer, tags, quickmarks, search engines, ...) Joost Kremers
2018-04-24 20:53             ` The importance of secrecy Stefan Monnier
2018-04-24 22:40             ` Lars Ingebrigtsen
2018-04-24 22:44               ` Stefan Monnier
2018-04-24 15:58       ` EWW improvements: open in new buffer, tags, quickmarks, search engines, T.V Raman
2018-04-25  6:48         ` Pierre Neidhardt
2018-04-25 15:25           ` T.V Raman
2018-04-25 16:25             ` Pierre Neidhardt
2018-04-25 23:36               ` T.V Raman
2018-04-26 12:46                 ` Stefan Monnier
2018-04-24 16:24       ` Drew Adams
2018-04-25  7:00         ` Pierre Neidhardt
2018-04-25 12:30           ` Lars Ingebrigtsen
2018-04-25 15:29           ` Drew Adams [this message]
2018-05-03  6:52             ` Pierre Neidhardt
2018-05-03  6:54             ` Pierre Neidhardt
2018-05-03 15:12               ` Drew Adams
2018-04-24 16:49       ` Eli Zaretskii
2018-04-25  6:32         ` Pierre Neidhardt
2018-04-25 15:55           ` Eli Zaretskii
2018-04-25 16:13             ` Pierre Neidhardt
2018-04-25 16:19               ` Eli Zaretskii
2018-04-17 19:01 ` Lars Ingebrigtsen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=9d0ffd44-c4ee-4c56-b29a-fb61674588ec@default \
    --to=drew.adams@oracle.com \
    --cc=ambrevar@gmail.com \
    --cc=charles@aurox.ch \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.