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: Fri, 07 Mar 2008 13:08:29 -0500 Message-ID: <877igel84i.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> 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 1204913341 4130 80.91.229.12 (7 Mar 2008 18:09:01 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 7 Mar 2008 18:09:01 +0000 (UTC) Cc: Tassilo Horn , Stefan Monnier , Reiner Steib , emacs-devel@gnu.org To: Bastien Guerry Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Mar 07 19:09:27 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 1JXh0K-0006Mg-KM for ged-emacs-devel@m.gmane.org; Fri, 07 Mar 2008 19:09:12 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JXgzm-0003wv-S2 for ged-emacs-devel@m.gmane.org; Fri, 07 Mar 2008 13:08:38 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JXgzi-0003t1-4M for emacs-devel@gnu.org; Fri, 07 Mar 2008 13:08:34 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JXgzh-0003r7-E9 for emacs-devel@gnu.org; Fri, 07 Mar 2008 13:08:33 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JXgzh-0003qv-7S for emacs-devel@gnu.org; Fri, 07 Mar 2008 13:08:33 -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 1JXgzg-0005Py-Ce for emacs-devel@gnu.org; Fri, 07 Mar 2008 13:08:33 -0500 Original-Received: from localhost ([127.0.0.1]:47414 helo=floss ident=kfogel) by sanpietro.red-bean.com with esmtp (Exim 4.68) (envelope-from ) id 1JXgze-00080c-72; Fri, 07 Mar 2008 12:08:30 -0600 In-Reply-To: <8763vyl964.fsf@bzg.ath.cx> (Bastien Guerry's message of "Fri, 07 Mar 2008 17:45:55 +0000") 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:91655 Archived-At: Bastien Guerry writes: > My single remaining hesitation is this one: having two buffer local > variables is a bit too much, since each mode would have to set them > both. Better use `bookmark-make-record-function' for both purposes: > returning a name *or* returning a record. Ick :-). I don't think having an optional argument change the return semantics of the function would be a good solution. Remember, we're already asking external callers to implement two bookmark functions: the make-record function, and the jump function. Adding make-name to that is no great burden: clearly, any caller for who `buffer-file-name' or any of the other default fallbacks won't suffice is going to have to implement a name generator. Whether they do that as a separate function or not doesn't change the burden. I would suggest writing a `bookmark-initialize' function that sets up whatever local variables are necessary. That way, that function's doc string can remind people what interfaces they have to implement, and they can go read up more on those interfaces. > I think it's easier. Each mode should have to worry about one > buffer-local variable (and each dev would only read one docstring...) See above about setting buffer-local and having a doc string. -Karl