From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Richard Stallman Newsgroups: gmane.emacs.devel Subject: Re: Multiple major modes Date: Sun, 01 Jul 2007 16:40:12 -0400 Message-ID: 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> Reply-To: rms@gnu.org NNTP-Posting-Host: lo.gmane.org Content-Type: text/plain; charset=ISO-8859-15 X-Trace: sea.gmane.org 1183322622 7069 80.91.229.12 (1 Jul 2007 20:43:42 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 1 Jul 2007 20:43:42 +0000 (UTC) Cc: jasonr@gnu.org, lennart.borgman@gmail.com, sdl.web@gmail.com, monnier@iro.umontreal.ca, emacs-devel@gnu.org To: "Eric M. Ludlam" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jul 01 22:43:40 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 1I56Gb-0002dr-Dq for ged-emacs-devel@m.gmane.org; Sun, 01 Jul 2007 22:43:33 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1I56Gb-0005gJ-2M for ged-emacs-devel@m.gmane.org; Sun, 01 Jul 2007 16:43:33 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1I56DQ-0006vH-T2 for emacs-devel@gnu.org; Sun, 01 Jul 2007 16:40:17 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1I56DN-0006q4-Li for emacs-devel@gnu.org; Sun, 01 Jul 2007 16:40:13 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1I56DN-0006pq-0g for emacs-devel@gnu.org; Sun, 01 Jul 2007 16:40:13 -0400 Original-Received: from fencepost.gnu.org ([140.186.70.10]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1I56DM-0005Iz-LJ for emacs-devel@gnu.org; Sun, 01 Jul 2007 16:40:12 -0400 Original-Received: from rms by fencepost.gnu.org with local (Exim 4.60) (envelope-from ) id 1I56DM-0006bO-6a; Sun, 01 Jul 2007 16:40:12 -0400 In-reply-to: <200706251404.l5PE4dgc011720@projectile.siege-engine.com> (eric@siege-engine.com) X-detected-kernel: Linux 2.6, seldom 2.4 (older, 4) 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:74147 Archived-At: 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? 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? 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? 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? 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. 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. I agree, that would be good to do.