From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Jean Louis Newsgroups: gmane.emacs.help Subject: Re: [External] : Supplying DOC string in a `defun' using `defvar' Date: Thu, 3 Jun 2021 12:19:32 +0300 Message-ID: References: <871r9ly7v3.fsf@web.de> <8735tzj34v.fsf@web.de> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="21244"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mutt/2.0.7+183 (3d24855) (2021-05-28) Cc: help-gnu-emacs To: Eduardo Ochs Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Thu Jun 03 11:23:10 2021 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lojZG-0005Ia-QD for geh-help-gnu-emacs@m.gmane-mx.org; Thu, 03 Jun 2021 11:23:10 +0200 Original-Received: from localhost ([::1]:42310 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lojZF-0003qC-MB for geh-help-gnu-emacs@m.gmane-mx.org; Thu, 03 Jun 2021 05:23:09 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:51498) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lojYl-0003oG-2j for help-gnu-emacs@gnu.org; Thu, 03 Jun 2021 05:22:39 -0400 Original-Received: from stw1.rcdrun.com ([217.170.207.13]:48835) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lojYh-0005EG-SF for help-gnu-emacs@gnu.org; Thu, 03 Jun 2021 05:22:38 -0400 Original-Received: from localhost ([::ffff:197.157.0.35]) (AUTH: PLAIN admin, TLS: TLS1.3,256bits,ECDHE_RSA_AES_256_GCM_SHA384) by stw1.rcdrun.com with ESMTPSA id 00000000000AE2D9.0000000060B89F58.00002AD0; Thu, 03 Jun 2021 02:22:32 -0700 Mail-Followup-To: Eduardo Ochs , help-gnu-emacs Content-Disposition: inline In-Reply-To: Received-SPF: pass client-ip=217.170.207.13; envelope-from=bugs@gnu.support; helo=stw1.rcdrun.com X-Spam_score_int: -3 X-Spam_score: -0.4 X-Spam_bar: / X-Spam_report: (-0.4 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_SORBS_WEB=1.5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "help-gnu-emacs" Xref: news.gmane.io gmane.emacs.help:130527 Archived-At: * Eduardo Ochs [2021-06-03 10:24]: > On Thu, 3 Jun 2021 at 03:52, Jean Louis wrote: > > > > And I have a package as RCD Template Interpolation System for Emacs > > https://hyperscope.link/3/7/1/3/3/RCD-Template-Interpolation-System-for-Emacs.html > > > > that is separate package because I keep it dynamically not lexically, > > with intention. It is used in business to personalize emails and > > communication, like yesterday 756 times. There is no lexical bindings > > involved and currently I don't know how would I implement it with > > lexical bindings involved. I hope dynamic bindings will never go. > > > Me too. > > I use - zillions of times a day - a template function that is > intrinsically incompatible with lexical binding - this one: > > http://angg.twu.net/eev-current/eev-template0.el.html > > and I believe that dynamic binding is much easier to understand and to > explain than lexical binding... also, I interact with beginners a lot, > and currently what I say to them is: "learn dynamic binding first, > even though it is being sort of deprecated, and don't try to use > lexical binding until you have at least one week of experience with > Emacs Lisp... after that you'll be able to compare the two and lexical > binding will make much more sense". > > I really hope that people realize the dynamic binding is great as an > educational tool, and that they will keep it available forever, with > all the adequate warnings and caveats - "for the sake of the > secretaries"... see: > > https://www.gnu.org/software/emacs/emacs-paper.html#SEC29 >From same document: https://www.gnu.org/software/emacs/emacs-paper.html#SEC17 It is not necessary for dynamic scope to be the only scope rule provided, just useful for it to be available. (defun foo1 (x) (foo2)) (defun foo2 () (+ x 5)) (foo1 1) ⇒ 6 (foo2) More information from the same document: Formal Parameters Cannot Replace Dynamic Scope Some language designers believe that dynamic binding should be avoided, and explicit argument passing should be used instead. Imagine that function A binds the variable FOO, and calls the function B, which calls the function C, and C uses the value of FOO. Supposedly A should pass the value as an argument to B, which should pass it as an argument to C. This cannot be done in an extensible system, however, because the author of the system cannot know what all the parameters will be. Imagine that the functions A and C are part of a user extension, while B is part of the standard system. The variable FOO does not exist in the standard system; it is part of the extension. To use explicit argument passing would require adding a new argument to B, which means rewriting B and everything that calls B. In the most common case, B is the editor command dispatcher loop, which is called from an awful number of places. What's worse, C must also be passed an additional argument. B doesn't refer to C by name (C did not exist when B was written). It probably finds a pointer to C in the command dispatch table. This means that the same call which sometimes calls C might equally well call any editor command definition. So all the editing commands must be rewritten to accept and ignore the additional argument. By now, none of the original system is left! -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns Sign an open letter in support of Richard M. Stallman https://stallmansupport.org/