From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Eric M. Ludlam" Newsgroups: gmane.emacs.devel Subject: Re[2]: Multiple major modes Date: Wed, 4 Jul 2007 22:29:04 -0400 Message-ID: <200707050229.l652T4LR023273@projectile.siege-engine.com> References: <466E7A93.3050705@gmail.com> <466E81AA.3030202@gnu.org> <466E9822.2050508@gmail.com> <466EAB9D.9020408@gnu.org> <466EEA71.2070700@gmail.com> <200706122014.l5CKEKV1021902@projectile.siege-engine.com> <200706190209.l5J29Csr010302@projectile.siege-engine.com> <200706251404.l5PE4dgc011720@projectile.siege-engine.com> NNTP-Posting-Host: lo.gmane.org X-Trace: sea.gmane.org 1183602561 22430 80.91.229.12 (5 Jul 2007 02:29:21 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 5 Jul 2007 02:29:21 +0000 (UTC) Cc: jasonr@gnu.org, lennart.borgman@gmail.com, sdl.web@gmail.com, monnier@iro.umontreal.ca, emacs-devel@gnu.org To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jul 05 04:29:18 2007 connect(): Connection refused 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 1I6H5n-0002sg-IL for ged-emacs-devel@m.gmane.org; Thu, 05 Jul 2007 04:29:15 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1I6H5m-0000uC-U3 for ged-emacs-devel@m.gmane.org; Wed, 04 Jul 2007 22:29:14 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1I6H5k-0000u7-DR for emacs-devel@gnu.org; Wed, 04 Jul 2007 22:29:12 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1I6H5j-0000tv-TH for emacs-devel@gnu.org; Wed, 04 Jul 2007 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 1I6H5j-0000ts-No for emacs-devel@gnu.org; Wed, 04 Jul 2007 22:29:11 -0400 Original-Received: from static-71-184-83-10.bstnma.fios.verizon.net ([71.184.83.10] helo=projectile.siege-engine.com) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1I6H5e-0005e4-7m; Wed, 04 Jul 2007 22:29:06 -0400 Original-Received: from projectile.siege-engine.com (localhost.localdomain [127.0.0.1]) by projectile.siege-engine.com (8.12.8/8.12.8) with ESMTP id l652T4YE023277; Wed, 4 Jul 2007 22:29:04 -0400 Original-Received: (from zappo@localhost) by projectile.siege-engine.com (8.12.8/8.12.8/Submit) id l652T4LR023273; Wed, 4 Jul 2007 22:29:04 -0400 In-reply-to: (message from Richard Stallman on Sun, 01 Jul 2007 16:40:12 -0400) X-detected-kernel: Linux 2.4-2.6 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:74329 Archived-At: >>> Richard Stallman seems to think that: >Please forgive my delay in studying your message and responding. > > >Currently, the idea is that major modes can make any global variable > >buffer-local. Are you suggesting we divide all variables into two > >classes, those that can be and those that can't be? If so, what is > >the benefit of that? > > There would be two classes. > >I don't entirely follow. Two classes of what? Two classes of variables? > >If so, could you describe each of the two classes? Sorry for being vague. There would be "buffer-local variables", and "mode-local variables". I was distinguishing those two from "global variables". In reading the "Elisp" manual to check my phrases, I see there are also "frame-local variables", and many other ways to bind variables, so I am just wrong in saying there are only two classes of variables. > There would be values that are specific > to the major mode, and variables that are local to just some buffer. > The buffer local value would trump the mode-specific value, and any > mode-specific value would trump the global value. > >That part makes sense to me; but can't we make all kinds of bindings >possible for every variable? Correct. When trying to resolve the value of some symbol, mode-local values would fit into the current scheme of determining the value in some way, and I am suggesting that buffer local values would be used before mode-local values. > The mode-local feature I wrote (with a lot of help from David Ponce) > works in all versions of Emacs commonly used today. It does this work > by modifying the buffer-local values for different major-modes. It > provides the concept of what a mode-local variable might be. Ideally > it would not operate this way, and instead have built-in support for > real mode-local values and method tables. > >That makes sense. We could implement mode-local bindings at the low >level if that is what we want. > >What should their semantics be? If you have a variable defined: (defvar my-var nil) and then set a mode-local value for a mojor mode: ;; programmatic (setq-mode-local 'c-mode my-var t) ;; or declarative (defvar-mode-local c-mode my-var t "Description about C value") ;; or a constant for that mode, if `defconst' was used instead of `defvar'. (defconst-mode-local c-mode my-var t "Description here...") then all buffers in c-mode would get the new value of my-var. If any of those buffers have a buffer-local version of my-var, then that value would be used instead. I'm not sure about frame-local variables. If a c-mode buffer switched to fundamental-mode, then the value of my-var would go back to nil, (the default value). > A side effect is that > you could have minor modes that operate across both major modes in a > single buffer, and that minor mode won't get tromped. > >How would this work? A minor mode which works in an HTML buffer with embedded php in it could use `mode-local-symbol-value' to get the value of some HTML variable when inside a PHP block for, perhaps, fill-column, or other variable even though the effective major mode is PHP. Basically, any code could be written to be aware of the combination of two modes for a specific case, and have access to both sets of mode-local variable bindings, regardless of cursor position. > It is obvious that if a mode-local type tool or syntax were adopted > into Emacs, that it would be a big effort to transition everything to > it. > >I hope we can design the mechanism to avoid the need for pervasive >changes in the code of major modes. Perhaps we would need to change >some of the current calls to make-local-variable to call some new >primitive, make-mode-variable, instead. But even that would be a pain >if every major mode HAD to do it. I think it can be completely optional. Whichever multiple major-mode tool that is chosen could take advantage of mode-local variables, and major modes would adopt the use of them because of performance and usage enhancement. If a multi-major-mode tool knows a particular major-mode doesn't use buffer-local variables, then it would not need to run the major-mode function (which could call `kill-all-local-variables') for every section switch and lots of work needed to save and restore buffer-local values that may or may not be mode-specific would be saved. I like providing the mode-local values in a declarative way outside of the mode function. It provides a place to add documentation and talk about the change. That alone, I think, is worthwhile. Eric -- Eric Ludlam: zappo@gnu.org, eric@siege-engine.com Home: http://www.ludlam.net Siege: www.siege-engine.com Emacs: http://cedet.sourceforge.net GNU: www.gnu.org