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: Mon, 25 Jun 2007 10:04:39 -0400 Message-ID: <200706251404.l5PE4dgc011720@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> NNTP-Posting-Host: lo.gmane.org X-Trace: sea.gmane.org 1182780299 25380 80.91.229.12 (25 Jun 2007 14:04:59 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 25 Jun 2007 14:04:59 +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 Mon Jun 25 16:04:57 2007 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 1I2pBY-0002W4-SD for ged-emacs-devel@m.gmane.org; Mon, 25 Jun 2007 16:04:57 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1I2pBY-0004jX-Fr for ged-emacs-devel@m.gmane.org; Mon, 25 Jun 2007 10:04:56 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1I2pBU-0004j4-SC for emacs-devel@gnu.org; Mon, 25 Jun 2007 10:04:52 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1I2pBU-0004ij-3d for emacs-devel@gnu.org; Mon, 25 Jun 2007 10:04:52 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1I2pBU-0004ig-0W for emacs-devel@gnu.org; Mon, 25 Jun 2007 10:04:52 -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 1I2pBR-0001LX-LY; Mon, 25 Jun 2007 10:04:49 -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 l5PE4dYE011724; Mon, 25 Jun 2007 10:04:39 -0400 Original-Received: (from zappo@localhost) by projectile.siege-engine.com (8.12.8/8.12.8/Submit) id l5PE4dgc011720; Mon, 25 Jun 2007 10:04:39 -0400 In-reply-to: (message from Richard Stallman on Sun, 24 Jun 2007 10:41:18 -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:73820 Archived-At: Hi, >>> Richard Stallman seems to think that: > Define all your variables with `defvar-mode-local'. > If changing a default value, use `setq-mode-local' > >Does this mean we would have to go thru all of Emacs and put in >such definitions for all the variables that major modes can change? First, I'd like to be clear that I did not concoct the mode-local program so that I could write a cheap multi-major-mode type program. For semantic, which is a parser-generator, and has many minor modes, it allows someone to write mode-specific code and variable values in a way that is declarative, instead of in a giant hook function. It makes it very easy to write a tool (like semantic) that can work in many major modes, and where the differences between major modes is very small. Another advantage is that it allows each mode to add documentation specific to its needs. As for adopting it for all modes, I expect it is optional. It would replace the big block in most mode functions that create and set buffer-local values for tools that are not specific to that major-mode. >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. 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. >Would it make sense for `defvar' itself to do whatever you want >`defvar-mode-local' to do? That could simplify things greatly, though I haven't though too hard on this idea. > For a program, use `define-overload' to specify a function that > can have a mode specific override. Supply a default body for modes > that accept the default. > >Since multiple major modes work (in different buffers) without this >feature, why would we need to add this feature merely to support >multiple major modes in one buffer? The function overload mechanism is also a feature I use in semantic. Most features that work in multiple major modes today provide a variable where you can put a symbol that is a function that would then provide some mode-specific functionality. My semantic tool has hundreds of these functions, so I abstracted the concept up so that the implementations could be declarative, instead of programmatic. It also makes it easy to make most functions overridable, which helps avoid forcing users to use advice when customizing my tool. As for the multi-major-mode case, if the technique of a variable w/ a symbol in it is used, then you are correct, this already works. > The mode-local system will automatically assign buffer-local values > to mode-local defined variables. > >I don't understand. Does this mean that everything defined with >`defvar-mode-local' gets buffer-local in all buffers? If so, >how is that different from `make-variable-buffer-local'? > >I guess there must be parts of this explanation that are missing. 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. In summary, the mode-local tool is useful (to me at least) because it lets me write more declarative code while setting up values for a major mode. For the multi-major-mode case, it would allow a multi-major-mode tool to operate on predefined lists of variables and it would know the difference between a variable that is specific to that major mode (and thus must be swapped in and out) and a variable that is buffer local for some other reason, such as a minor-mode. 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. I used this technique for semantic's grammar mode which swaps between the grammar syntax, and Emacs Lisp which is the grammar implementation. 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 also don't recommend that David's mode-local implementation be taken as a sole implementation. The real advantage would come if the concepts were built into Emacs and the help system which could then show chains of values (For C-h v) or chains of function doc (for C-h f) based on mode. The readability of my code increased greatly when I transitioned to a more declarative way of setting up deltas to different major-modes. It also made the grammar mode easy to implement, and that's why I suggest it here. Thanks Eric