From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.devel Subject: RE: EWW improvements: open in new buffer, tags, quickmarks, search engines, ... Date: Wed, 25 Apr 2018 08:29:46 -0700 (PDT) Message-ID: <9d0ffd44-c4ee-4c56-b29a-fb61674588ec@default> References: <87zi23bg67.fsf@gmail.com> <87efjd3alj.fsf@gmail.com> <878t9dw3it.fsf@gmail.com> <92db8445-5829-4c34-8c47-9eb6e9c6cbcb@default> <87a7trydmp.fsf@gmail.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1524670155 23366 195.159.176.226 (25 Apr 2018 15:29:15 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 25 Apr 2018 15:29:15 +0000 (UTC) Cc: "Charles A. Roelli" , emacs-devel@gnu.org To: Pierre Neidhardt Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Apr 25 17:29:11 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 1fBMM2-0005zm-R1 for ged-emacs-devel@m.gmane.org; Wed, 25 Apr 2018 17:29:11 +0200 Original-Received: from localhost ([::1]:37659 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fBMO9-00045C-KG for ged-emacs-devel@m.gmane.org; Wed, 25 Apr 2018 11:31:21 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51550) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fBMMr-0003wN-JV for emacs-devel@gnu.org; Wed, 25 Apr 2018 11:30:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fBMMo-0002aX-9i for emacs-devel@gnu.org; Wed, 25 Apr 2018 11:30:01 -0400 Original-Received: from userp2130.oracle.com ([156.151.31.86]:46692) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1fBMMo-0002ZZ-1O for emacs-devel@gnu.org; Wed, 25 Apr 2018 11:29:58 -0400 Original-Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w3PFQdvq050229; Wed, 25 Apr 2018 15:29:48 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2017-10-26; bh=VLXkHGX8tWj03Gd0Pmmn1kqZAzmnWSmp9E6N5t5vZ5A=; b=qcOTUf8I1ZVqYDL5VpJmDd/YbmtsChJ1rB5+vljmMSLbuYlQ5nhbBmSCaxtCGMuWyrWj IZMEV5MRfKIHtfRp0mts9hK/0KAjstHg7rs+99uaqhlxryZ2NJwo+/IaI9v9jotLZ8cl C8eEzIRkH2AXCpTHrj5082Pe80YXVl2ujiFK+/BSQQlC29gRd8C/MVSQngnj1O41rS2H IkBuNUiQoGdVt2uzFHaV2TcC+O18qt0qaVz+V9FoP7zwRlAyBkGi+QAk8p9QZ93ziGX4 dnhK/tzzbjdey/cYyqF0ylwCB9Ao1qiCa8qqCJdHn/2KiyWyOpGvCM8A2lWbSueQ43oJ lw== Original-Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp2130.oracle.com with ESMTP id 2hfvrbyaqv-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 25 Apr 2018 15:29:48 +0000 Original-Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id w3PFTlAh025431 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 25 Apr 2018 15:29:47 GMT Original-Received: from abhmp0011.oracle.com (abhmp0011.oracle.com [141.146.116.17]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id w3PFTlQh012129; Wed, 25 Apr 2018 15:29:47 GMT In-Reply-To: <87a7trydmp.fsf@gmail.com> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4678.0 (x86)] X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8874 signatures=668698 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1804250145 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [generic] [fuzzy] X-Received-From: 156.151.31.86 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:224871 Archived-At: > > 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? >=20 > 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. >=20 > 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: >=20 > - 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. >=20 > 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'.