From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Karl Fogel Newsgroups: gmane.emacs.devel Subject: Re: doc-view support for bookmark.el Date: Wed, 26 Dec 2007 10:53:39 -0800 Message-ID: <87lk7hz3rg.fsf@red-bean.com> References: <8763yn3v07.fsf@member.fsf.org> <87prwu3kg0.fsf@member.fsf.org> <87prwu77ug.fsf@member.fsf.org> Reply-To: Karl Fogel NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1198688024 1822 80.91.229.12 (26 Dec 2007 16:53:44 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 26 Dec 2007 16:53:44 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Dec 26 17:53:56 2007 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1J7ZVz-00017E-B2 for ged-emacs-devel@m.gmane.org; Wed, 26 Dec 2007 17:53:55 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1J7ZVe-0002LU-H1 for ged-emacs-devel@m.gmane.org; Wed, 26 Dec 2007 11:53:34 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1J7ZVa-0002HQ-1q for emacs-devel@gnu.org; Wed, 26 Dec 2007 11:53:30 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1J7ZVV-0002Fu-Mh for emacs-devel@gnu.org; Wed, 26 Dec 2007 11:53:29 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1J7ZVV-0002Fr-Gu for emacs-devel@gnu.org; Wed, 26 Dec 2007 11:53:25 -0500 Original-Received: from sanpietro.red-bean.com ([66.146.193.61]) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1J7ZVV-0004xI-BZ for emacs-devel@gnu.org; Wed, 26 Dec 2007 11:53:25 -0500 Original-Received: from localhost ([127.0.0.1]:36967) by sanpietro.red-bean.com with esmtp (Exim 4.68) (envelope-from ) id 1J7ZVT-00020F-RO for emacs-devel@gnu.org; Wed, 26 Dec 2007 10:53:23 -0600 In-Reply-To: <87prwu77ug.fsf@member.fsf.org> (Tassilo Horn's message of "Tue\, 25 Dec 2007 23\:00\:39 +0100") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1.50 (gnu/linux) X-detected-kernel: by monty-python.gnu.org: Linux 2.6 (newer, 3) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:85478 Archived-At: I like your new bookmark abstractions, Tassilo! A few comments: Tassilo Horn writes: > --- lisp/bookmark.el 25 Sep 2007 10:43:39 -0000 1.98 > +++ lisp/bookmark.el 25 Dec 2007 21:51:50 -0000 > @@ -480,6 +482,22 @@ > (interactive-p) > (setq bookmark-history (cons ,string bookmark-history)))) > > +(defvar bookmark-make-cell-function 'bookmark-make-cell-for-text-file > + "A function that should be called to create the bookmark > +record. Modes may set this variable buffer-locally to enable > +bookmarking of non-text files like images or pdf documents. > + > +The function will be called with two arguments: ANNOTATION and > +INFO-NODE. See `bookmark-make-cell-for-text-file' for a > +description. > + > +The returned record may contain a special cons (handler > +. some-function) which sets the handler function that should be > +used to open this bookmark instead of `bookmark-jump-noselect'. > +It should return a cons (BUFFER . POINT) indicating buffer > +showing the bookmarked location and the value of point in that > +buffer. Like `bookmark-jump-noselect' the buffer shouldn't be > +selected by the handler.") Okay, so "(BUFFER . POINT)" is now an exported interface, not just an internal interface that we would be free to change inside bookmark.el. Therefore, let's make it more extensible than a dotted pair. The cleanest thing would probably be an association list: '((buffer BUFFER) (point POINT)) That way, callers will be compatible even if we extend the type later: '((buffer BUFFER) (point POINT) ...) And a comment regarding documentation: Normally, a function type's documentation should all be in one place, I think, not referring out to specific instances. So normally, I would suggest replacing this... The function will be called with two arguments: ANNOTATION and INFO-NODE. See `bookmark-make-cell-for-text-file' for a description. ... with full documentation of the INFO-NODE argument. But in this case, the better thing might be to implement `bookmark-make-cell-for-info-node' as a separate instance of `bookmark-make-cell-function', adjusting everything else in the obvious way. Thoughts? -Karl