From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: MON KEY Newsgroups: gmane.emacs.devel Subject: Proposal: `buffer-offer-save' be made a permanent-local Date: Sun, 13 Jun 2010 20:17:38 -0400 Message-ID: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: dough.gmane.org 1276474675 12048 80.91.229.12 (14 Jun 2010 00:17:55 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 14 Jun 2010 00:17:55 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jun 14 02:17:53 2010 connect(): No such file or directory 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.69) (envelope-from ) id 1ONxNA-0007r9-Mv for ged-emacs-devel@m.gmane.org; Mon, 14 Jun 2010 02:17:53 +0200 Original-Received: from localhost ([127.0.0.1]:58696 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ONxNA-00072W-39 for ged-emacs-devel@m.gmane.org; Sun, 13 Jun 2010 20:17:52 -0400 Original-Received: from [140.186.70.92] (port=34788 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ONxN1-00071V-RY for emacs-devel@gnu.org; Sun, 13 Jun 2010 20:17:45 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1ONxMz-0001YB-Tv for emacs-devel@gnu.org; Sun, 13 Jun 2010 20:17:43 -0400 Original-Received: from mail-yx0-f169.google.com ([209.85.213.169]:53715) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1ONxMz-0001Y0-Q5 for emacs-devel@gnu.org; Sun, 13 Jun 2010 20:17:41 -0400 Original-Received: by yxf34 with SMTP id 34so528403yxf.0 for ; Sun, 13 Jun 2010 17:17:39 -0700 (PDT) Original-Received: by 10.151.88.29 with SMTP id q29mr5848016ybl.300.1276474659482; Sun, 13 Jun 2010 17:17:39 -0700 (PDT) Original-Received: by 10.151.10.5 with HTTP; Sun, 13 Jun 2010 17:17:38 -0700 (PDT) X-Google-Sender-Auth: VApo8lwFLlTZF0CwhCFUwi5ejTQ X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) 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:125883 Archived-At: Proposal: `buffer-offer-save' be made a permanent-local. Recently there was a proposal on bug-gnu-emacs to have `buffer-offer-save' be made a permanent-local e.g. "bug#6241: Please make buffer-offer-save permanent local" in which Stefan expressed some willingness to endorse the change: ,---- | { ... } it's easier to circumvent an annoying permanent-local than | it is to fake one. I.e. if a var is permanent-local and you need it | to be killed by kill-all-local-variables, you can do something like: | | (add-hook 'change-major-mode-hook | (lambda () (kill-local-variable 'foobar))) | | whereas if it is not permanent-local and you need it to survive a | change of major-mode, you have to jump through a few more hoops (a | change-major-mode-hook to stash the variable's content somewhere, | plus an after-change-major-mode-hook to reset it after the fact, | plus additional code to handle the case when | after-change-major-mode-hook is not run, ...). | | So, now that the question of "should it ideally be permanent-local?" | is resolved, the remaining question is: "what would be the impact of | such a change", which requires examining all uses of the variable | and assessing the effect of the change for each case. `---- http://lists.gnu.org/archive/html/bug-gnu-emacs/2010-05/msg00730.html I requested that this decision be discussed/proposed to emacs-devel b/c it struck me as both a potentially breaking change and one that isn't needed. To date, this discussion hasn't happened. So, what do others here think? Is this proposed changed needed, desirable, welcome? IIUC Stefan's rationale for consideration of making `buffer-offer-save' permanent-local is that it would ease the burden placed on major-modes (and their authors) to set/check for the presence of `buffer-offer-save' by making the value a permanent property of every Emacs buffer not yet visiting a file such that a major-mode/feature would now be able to set `buffer-offer-save' as a `buffer-local-value' and thereafter rely on the value persisting across multiple subsequent invocations of the `kill-all-local-variables'->`change-major-mode-hook' call chain. Consideration of following exchange which transpired between RMS and Stefan on emacs-devel circa 2003-06-01 as thread: "Re: kill-buffer-hook permanent-local" has caused me some doubt as to whether the current proposed change is TRT and is in keeping with the rationale for other similar such changes in the past: ,---- | Stefan Monnier: | >> Shouldn't kill-buffer-hook be permanent-local ? | | RMS: | > I think it is OK to make this change. | > If a certain major mode wants to set up a hook value | > that should not remain if you change the mode, it could | > use change-major-mode-hook to remove that hook. `---- http://lists.gnu.org/archive/html/emacs-devel/2003-06/msg00066.html My impression is that `kill-all-local-variables' is generally relied upon to restore/reset a buffer to a more or less default state and then evaluates `change-major-mode-hook' to begin the process of introducing/enabling the variables and behaviors which are peculiar/relevant on entrance to a particular major-mode e.g.: (describe-variable 'change-major-mode-hook) ,---- | Normal hook run before changing the major mode of a buffer. The | function `kill-all-local-variables' runs this before doing anything | else. `---- What I don't understand is, why if `kill-buffer-hook' is permanent-local (which it now is), and calls to `kill-all-local-variables' automatically evaluate `change-major-mode-hook' do we now also need to have `buffer-offer-save' be made permanent-local? IIUC, RMS seems to be saying above that his caveat for allowing `kill-buffer-hook' as a permanent-local was _because_ it could be removed/altered/overridden by subsequent calls to `change-major-mode-hook'. In contrast, the currently proposed change to have `buffer-offer-save' become permanent-local is essentially an attempt to circumvent the same exceptional behavior which RMS seems to suggest convinced him that it was reasonable to allow `kill-buffer-hook' as a permanent-local. As currently proposed this new permanent-local will mean that major-modes will now have to explicitly check for the `buffer-local-value' of `buffer-offer-save' whereas up until now major-mode authors could assume it to be nil being that it was automatically zapped by `kill-all-local-variables' before the any further major-mode changes occurred. IME most buffers rarely require more than three distinct major-modes to reasonably edit the text within context. So, I personally don't understand what problem the proposed change solves. It doesn't seem like that big a deal for a particular major-mode to check for the value of variable if it is necessary for it to do so in order to reasonably satisfy user expectations. To the extent that the change is needed/wanted/desirable, why can't a mode-local `buffer-offer-save' be added to the `kill-buffer-hook' instead to accomplish the same goal of making `buffer-offer-save' permanent-local without having to add an additional atomic and effectively immutable global to every buffer's list of `buffer-local-variables'? Does the proposed change offer the right level of granularity for a variable which globally affects the effective state of buffer savedness? Should `buffer-offer-save' be allowed to become a permanent-local property of a buffer it may indeed solve what is at present a relatively minor and esoteric issue affecting a few developers of certain major-modes whose features require programatically enabling/disabling the mode multiple times during the life of a buffer to accomplish complicated presentation tasks. My concern, is that though the issue doesn't currently seem to adversely affect the development of most major-modes this doesn't mean that if/once buffer-offer-save is made permanent-local it won't be bound more often via the `change-major-mode-hook' in the wild by third party code. Should this occur it may well violate many user expectations placing a burden on the _user_ to find and remove any inadvertent binding of this global property hidden away in a dedicated package function/macro. Right now this isn't a problem for users because the buffer-offer-save property is typically bound/removed with each call to `kill-all-local-variables'->`change-major-mode-hook' on a mode-change. One argument which has been made for making `buffer-offer-save' permanent-local is that this value reflects aspects of a buffers textual content whereas the current situation treats it as part of a buffer's major-mode context. IOW Currently it is left to the buffer's major-mode (context) to determine on each mode-change whether an unsaved buffer in that mode should require that Emacs always offer to save the buffer on exit. However, if I should change from `emacs-lisp-mode' to `scheme-mode' the the text/chars the buffer contains (content) don't necessarily change, the decision of whether Emacs will offer to save the buffer is now decided by the `scheme-mode' context. I like the current behavior, I find it intuitive, and generally for a given buffer I know how Emacs will respond according to what the mode-line displays about the state of a given buffers major-mode. I'm comfortable knowing that when I'm in comint-mode buffer I'm gonna get an entirely different set of behaviors than when I'm in `org-mode'. I am adverse to making buffer-offer-save permanent-local because: - It treats the users choice of major-modes (context) as 2nd class; - Elevates buffer characters to vi modal status; - Abstracts and/or removes a user interface for controlling/monitoring a fundamental bit of Emacs behavior (buffer savedness); - May violate user notions of whether or not a buffer is treated by default as optionally expendable or inherently immutable. IMHO Emacs is better served moving _away_ from permanent-locals and other sorts of heavy-handed globals with an implicit reliance on dynamic-scoping and instead seek to find/incorporate first-class lexical-scoping solutions which can better accommodate both the user and package developers. Related Background: http://lists.gnu.org/archive/html/emacs-devel/2003-06/msg00025.html http://lists.gnu.org/archive/html/emacs-devel/2007-12/msg00169.html http://article.gmane.org/gmane.emacs.devel/82069 http://lists.gnu.org/archive/html/emacs-devel/2009-06/msg00364.html -- /s_P\