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: bookmark.el and lisp/gnus/gnus-bookmark.el Date: Sun, 09 Mar 2008 22:29:09 -0400 Message-ID: <8763vv8g7e.fsf@red-bean.com> References: <874pbj682f.fsf@red-bean.com> <87zltbhbq8.fsf@bzg.ath.cx> <87iqzzigv6.fsf@bzg.ath.cx> <87ejan7xhq.fsf@member.fsf.org> <87hcfi3egg.fsf@bzg.ath.cx> <87abla8w6b.fsf@member.fsf.org> <87bq5qhba6.fsf@bzg.ath.cx> <871w6m8t59.fsf@member.fsf.org> <87ablamphg.fsf@red-bean.com> <87skz2lacp.fsf@bzg.ath.cx> <87tzjil9oz.fsf@red-bean.com> <8763vyl964.fsf@bzg.ath.cx> <874pbiypad.fsf@bzg.ath.cx> <87ejalv8an.fsf@bzg.ath.cx> <87pru5gcy9.fsf@bzg.ath.cx> 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 1205116167 20999 80.91.229.12 (10 Mar 2008 02:29:27 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 10 Mar 2008 02:29:27 +0000 (UTC) Cc: Bastien , Tassilo Horn , Reiner Steib , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Mar 10 03:29:54 2008 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 1JYXlv-0001T1-Ci for ged-emacs-devel@m.gmane.org; Mon, 10 Mar 2008 03:29:51 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JYXlN-0008S6-2L for ged-emacs-devel@m.gmane.org; Sun, 09 Mar 2008 22:29:17 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JYXlI-0008RQ-V9 for emacs-devel@gnu.org; Sun, 09 Mar 2008 22:29:12 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JYXlI-0008RD-GK for emacs-devel@gnu.org; Sun, 09 Mar 2008 22:29:12 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JYXlI-0008R5-8E for emacs-devel@gnu.org; Sun, 09 Mar 2008 22:29:12 -0400 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 1JYXlI-0007At-6g for emacs-devel@gnu.org; Sun, 09 Mar 2008 22:29:12 -0400 Original-Received: from localhost ([127.0.0.1]:45510 helo=floss ident=kfogel) by sanpietro.red-bean.com with esmtp (Exim 4.69) (envelope-from ) id 1JYXlF-0002OX-KR; Sun, 09 Mar 2008 21:29:09 -0500 In-Reply-To: (Stefan Monnier's message of "Sat, 08 Mar 2008 18:20:30 -0500") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (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:91981 Archived-At: Stefan Monnier writes: >> For now `bookmark-set' asks for an annotation (if required), sends it to >> `bookmark-make' which calls `bookmark-make-record-function' with the >> annotation as an argument. > >> IIUC Tassilo suggested that the annotation should be directly handled by >> `bookmark-make-record-function', which seems correct to me. What you >> propose is to handle annotation in `bookmark-set' (or preferrably in >> `bookmark-make') -- this is _feasible_, but it looks weird to me since >> the annotation is really part of the record. > > The record has various parts: a name to select it, an annotation, > a bunch of data to find the place, there could be more (date the record > was created, when it was last used, ...). > > The bookmark-make-record-function should only concern itself with > providing the data to find the place. It may also provide a default > name, a default annotation, ... but it's better if it doesn't need to > handle annotations since those are (or rather should be) handled > identically for *all* bookmark-make-record-function. I agree with Stefan's analysis here. A bookmark record is not an opaque object: it is okay for `bookmark-set' or any other bookmark.el function to supply parts of the record that are not specific to the mode generating the bookmark. The external mode code should concern itself with the location data -- that code is both producer and consumer of that data. Since bookmark.el is always the consumer of the annotation data, it should be the producer of that data as well. Fortunately, we're using alists here, so all data is labeled in comprehensible ways. It should be easy to keep things straight.