Account Options

  1. Sign in
The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Google Groups Home
« Groups Home
Message from discussion Does b:undo_ftplugin actually work?

Received: by 10.58.151.104 with SMTP id up8mr2718874veb.6.1348865585877;
        Fri, 28 Sep 2012 13:53:05 -0700 (PDT)
X-BeenThere: vim_dev@googlegroups.com
Received: by 10.220.149.129 with SMTP id t1ls3848347vcv.0.gmail; Fri, 28 Sep
 2012 13:53:03 -0700 (PDT)
Received: by 10.58.145.65 with SMTP id ss1mr2576957veb.39.1348865583278;
        Fri, 28 Sep 2012 13:53:03 -0700 (PDT)
Received: by 10.58.145.65 with SMTP id ss1mr2576956veb.39.1348865583270;
        Fri, 28 Sep 2012 13:53:03 -0700 (PDT)
Return-Path: <cbli...@256bit.org>
Received: from 256bit.org ([85.214.140.184])
        by gmr-mx.google.com with ESMTPS id ef10si579268vdb.3.2012.09.28.13.53.02
        (version=TLSv1/SSLv3 cipher=OTHER);
        Fri, 28 Sep 2012 13:53:02 -0700 (PDT)
Received-SPF: neutral (google.com: 85.214.140.184 is neither permitted nor denied by best guess record for domain of cbli...@256bit.org) client-ip=85.214.140.184;
Authentication-Results: gmr-mx.google.com; spf=neutral (google.com: 85.214.140.184 is neither permitted nor denied by best guess record for domain of cbli...@256bit.org) smtp.mail=cbli...@256bit.org
Received: from chrisbra by 256bit.org with local (Exim 4.72)
	(envelope-from <cbli...@256bit.org>)
	id 1THhYT-0003JQ-GO
	for vim_dev@googlegroups.com; Fri, 28 Sep 2012 22:53:01 +0200
Date: Fri, 28 Sep 2012 22:53:01 +0200
From: Christian Brabandt <cbli...@256bit.org>
To: vim_dev@googlegroups.com
Subject: Re: Does b:undo_ftplugin actually work?
Message-ID: <20120928205301.GJ19145@256bit.org>
Mail-Followup-To: vim_dev@googlegroups.com
References: <20120928040356.GA12181@phoenix>
 <c82dfe2f-0e18-4ea9-960a-ca14769bcb8f@googlegroups.com>
 <20120928060146.GB12181@phoenix>
 <20120928122127.GA19145@256bit.org>
 <0bc14fed-3b5e-4b1a-a994-0aaf5b1e9158@googlegroups.com>
 <20120928184735.GB19145@256bit.org>
 <ec720e64-62c1-4801-a63d-398f5f776941@googlegroups.com>
 <a5dbeca6-6bfa-406d-a0e4-f32785aaad18@googlegroups.com>
 <20120928201526.GH19145@256bit.org>
 <dda6f901-67cd-4d22-bead-53f80aa38e8c@googlegroups.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <dda6f901-67cd-4d22-bead-53f80aa38e8c@googlegroups.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Sender: <cbli...@256bit.org>

Hi ZyX!

On Fr, 28 Sep 2012, ZyX wrote:

> Ñ ÑƒÐ±Ð±Ð¾Ñ‚Ð°, 29 Ñ ÐµÐ½Ñ‚Ñ Ð±Ñ€Ñ  2012 г., 0:15:33 UTC+4 пользователь Christian Brabandt Ð½Ð°Ð¿Ð¸Ñ Ð°Ð»:
> > >You may replace first “echom† with “setlocal† and see that
> > > option is set for a wrong buffer. Your autocmd must not be used.
> > 
> > You are changing buffers and wiping a buffer. I am not sure what you are 
> > trying to show here.
> Do what I suggested with :setlocal. *It will set options for the buffer that **was not being unloaded***. ****Wrong**** buffer.

Because those options aren't freed correctly. See the patch, I 
submitted.

> And, by the way, you are using b:undo_ftplugin from the *wrong* buffer
> as well. Because “b:† is *current* buffer scope and you must not touch
> buffer that is not being unloaded.

I guess we are not going to agree here. So just one final remark from me 
here, before I'll shut up.

Those buffer-local variables will be freed afterwards. We have not yet 
fully unloaded the old buffer, therefore we can still undo the old 
options.

regards,
Christian