From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "T. V. Raman" Newsgroups: gmane.emacs.devel Subject: Re: Multiple major modes Date: Wed, 4 Jul 2007 09:35:10 -0700 Message-ID: <18059.52286.486779.619378@gargle.gargle.HOWL> 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: raman@users.sf.net NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1183566938 23960 80.91.229.12 (4 Jul 2007 16:35:38 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 4 Jul 2007 16:35:38 +0000 (UTC) Cc: lennart.borgman@gmail.com, emacs-devel@gnu.org, monnier@iro.umontreal.ca, eric@siege-engine.com, jasonr@gnu.org, sdl.web@gmail.com To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jul 04 18:35:35 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 1I67pH-0000ao-6k for ged-emacs-devel@m.gmane.org; Wed, 04 Jul 2007 18:35:35 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1I67pG-0003YQ-6r for ged-emacs-devel@m.gmane.org; Wed, 04 Jul 2007 12:35:34 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1I67p8-0003NA-ER for emacs-devel@gnu.org; Wed, 04 Jul 2007 12:35:26 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1I67p6-0003Jb-J2 for emacs-devel@gnu.org; Wed, 04 Jul 2007 12:35:25 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1I67p6-0003JT-DJ for emacs-devel@gnu.org; Wed, 04 Jul 2007 12:35:24 -0400 Original-Received: from alnrmhc12.comcast.net ([206.18.177.52]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1I67p4-0002gu-08; Wed, 04 Jul 2007 12:35:22 -0400 Original-Received: from localhost (c-71-202-191-236.hsd1.ca.comcast.net[71.202.191.236]) by comcast.net (alnrmhc12) with ESMTP id <20070704163510b1200jtlpue>; Wed, 4 Jul 2007 16:35:21 +0000 Original-Received: by localhost (Postfix, from userid 1000) id 82C0812A4145; Wed, 4 Jul 2007 09:35:10 -0700 (PDT) In-Reply-To: X-Mailer: VM alpha-457 under Emacs 22.1.50.1 (i686-pc-linux-gnu) x-attribution: tvr X-detected-kernel: NetCache Data OnTap 5.x 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:74298 Archived-At: For the record, advice does update the function documentation, assuming one documents the advice. >>>>> "Richard" == Richard Stallman writes: Richard> The function overload mechanism is also a Richard> feature I use in semantic. Most features that work Richard> in multiple major modes today provide a variable Richard> where you can put a symbol that is a function that Richard> would then provide some mode-specific functionality. Richard> Richard> My semantic tool has hundreds of these Richard> functions, so I abstracted the concept up so that Richard> the implementations could be declarative, instead of Richard> programmatic. Richard> Richard> I really don't like the idea of function overloads. Richard> This mechanism shares the drawbacks of advice: that Richard> a function doesn't do what its definition says. Richard> Richard> It also makes it easy to make most Richard> functions overridable, which helps avoid forcing Richard> users to use advice when customizing my tool. Richard> Richard> It is easy to replace advising with another similar Richard> mechanism, but it doesn't solve the problem. Richard> Richard> It seems to me that there is no need for this. Richard> Calling a variable with funcall should do the same Richard> job. That way, the call _shows_ that the function Richard> isn't fixed. Richard> Richard> Richard> _______________________________________________ Richard> Emacs-devel mailing list Emacs-devel@gnu.org Richard> http://lists.gnu.org/mailman/listinfo/emacs-devel -- Best Regards, --raman Email: raman@users.sf.net WWW: http://emacspeak.sf.net/raman/ AIM: emacspeak GTalk: tv.raman.tv@gmail.com PGP: http://emacspeak.sf.net/raman/raman-almaden.asc Google: tv+raman IRC: irc://irc.freenode.net/#emacs