From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bastien Subject: Re: Problems with (defvar foo) and Emacs 23 Date: Wed, 04 Apr 2012 09:25:28 +0200 Message-ID: <87d37oklg7.fsf@gnu.org> References: <87sjgngtzk.fsf@norang.ca> <87aa2vp5ri.fsf@Rainer.invalid> <87aa2vw5mq.fsf@gnu.org> <87y5qfp2wd.fsf@Rainer.invalid> <87398m642v.fsf@gnu.org> <87bonaats8.fsf@Rainer.invalid> <8762dhs6u7.fsf@gnu.org> <87ehs5fj0b.fsf@Rainer.invalid> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([208.118.235.92]:35373) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SFKZl-0000Uj-Pg for emacs-orgmode@gnu.org; Wed, 04 Apr 2012 03:24:19 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SFKZk-0003wV-0b for emacs-orgmode@gnu.org; Wed, 04 Apr 2012 03:24:17 -0400 Received: from mail-wg0-f41.google.com ([74.125.82.41]:33512) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SFKZj-0003wL-Nl for emacs-orgmode@gnu.org; Wed, 04 Apr 2012 03:24:15 -0400 Received: by wgbds1 with SMTP id ds1so211038wgb.0 for ; Wed, 04 Apr 2012 00:24:13 -0700 (PDT) In-Reply-To: <87ehs5fj0b.fsf@Rainer.invalid> (Achim Gratz's message of "Tue, 03 Apr 2012 08:04:52 +0200") List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Achim Gratz Cc: emacs-orgmode@gnu.org Achim Gratz writes: > Bastien writes: >> 1. one about `buffer-substring-filters' >> We should write a compatibility function to get rid of the first >> warning. > > Actually it is a variable and it "just" needs to be aliased suitably, > depending on which Emacs version it encounters. I'm afraid this is not that straightforward, because the use of `filter-buffer-substring-functions' and `buffer-substring-filters' differ. > This should be done > with a macro in org-compat.el (which doesn't exist yet, see my attempt > at such a macro in another thread), then org can use the aliased name > only. In general I'd say org-compat.el is in need of some love. Make yourself at home there :) > >> 2. one about `entry' not having a prefix >> Prefixing `entry' is not straightforward but should be possible. > > I don't know enough about its uses to help here. No problem. >> 3. one about `date', `annotation', 'initial' not having a prefix >> As for the last warnings, I think we'll have to live with it, >> but chasing down places where *some* instance can be prefixed >> (or renamed with a more explicit name) could be good. Not a >> high priority though. > > I think one could also alias these (the prefix should be that of the > package where they come from), so that all uses within org use that > prefix. That would probably leave one warning at the point where the > alias is defined, which could be wrapped into with-no-warning. Good idea. When you have time for a patch to testing this solution, let me know. Thanks! -- Bastien