From unknown Fri Sep 05 08:41:37 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#8275 <8275@debbugs.gnu.org> To: bug#8275 <8275@debbugs.gnu.org> Subject: Status: 24.0.50; Intro to Emacs Lisp Issue Reply-To: bug#8275 <8275@debbugs.gnu.org> Date: Fri, 05 Sep 2025 15:41:37 +0000 retitle 8275 24.0.50; Intro to Emacs Lisp Issue reassign 8275 emacs submitter 8275 Jason Earl severity 8275 wishlist thanks From debbugs-submit-bounces@debbugs.gnu.org Thu Mar 17 13:36:40 2011 Received: (at submit) by debbugs.gnu.org; 17 Mar 2011 17:36:41 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Q0H7o-00060P-24 for submit@debbugs.gnu.org; Thu, 17 Mar 2011 13:36:40 -0400 Received: from eggs.gnu.org ([140.186.70.92]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Q0H7l-00060C-Q4 for submit@debbugs.gnu.org; Thu, 17 Mar 2011 13:36:38 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Q0H7f-0001do-1f for submit@debbugs.gnu.org; Thu, 17 Mar 2011 13:36:32 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_NONE, RFC_ABUSE_POST, T_RP_MATCHES_RCVD autolearn=unavailable version=3.3.1 Received: from lists.gnu.org ([199.232.76.165]:47504) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Q0H7a-0001cU-4A for submit@debbugs.gnu.org; Thu, 17 Mar 2011 13:36:31 -0400 Received: from [140.186.70.92] (port=54865 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q0H7W-0005kg-CC for bug-gnu-emacs@gnu.org; Thu, 17 Mar 2011 13:36:24 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Q0H7R-0001aZ-Tf for bug-gnu-emacs@gnu.org; Thu, 17 Mar 2011 13:36:20 -0400 Received: from mailout03.yourhostingaccount.com ([65.254.253.25]:47373) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Q0H7R-0001ZX-RP for bug-gnu-emacs@gnu.org; Thu, 17 Mar 2011 13:36:17 -0400 Received: from mailscan19.yourhostingaccount.com ([10.1.15.19] helo=mailscan19.yourhostingaccount.com) by mailout03.yourhostingaccount.com with esmtp (Exim) id 1Q0H7O-0007AB-9m for bug-gnu-emacs@gnu.org; Thu, 17 Mar 2011 13:36:14 -0400 Received: from impout03.yourhostingaccount.com ([10.1.55.3] helo=impout03.yourhostingaccount.com) by mailscan19.yourhostingaccount.com with esmtp (Exim) id 1Q0H7N-0001Tg-S5 for bug-gnu-emacs@gnu.org; Thu, 17 Mar 2011 13:36:13 -0400 Received: from authsmtp08.yourhostingaccount.com ([10.1.18.8]) by impout03.yourhostingaccount.com with NO UCE id LHcD1g0090ASqTN0000000; Thu, 17 Mar 2011 13:36:13 -0400 X-EN-OrigOutIP: 10.1.18.8 X-EN-IMPSID: LHcD1g0090ASqTN0000000 Received: from [67.214.244.122] (helo=c3po) by authsmtp08.yourhostingaccount.com with esmtpa (Exim) id 1Q0H7N-0003yY-E7 for bug-gnu-emacs@gnu.org; Thu, 17 Mar 2011 13:36:13 -0400 From: Jason Earl To: bug-gnu-emacs@gnu.org Subject: 24.0.50; Intro to Emacs Lisp Issue Date: Thu, 17 Mar 2011 11:35:58 -0600 Message-ID: <871v25d4zl.fsf@notengoamigos.org> MIME-Version: 1.0 Content-Type: text/plain X-EN-UserInfo: f8a5a3c49e1c4664ba81facb1022c4a9:67ddfe7aeaee6d1ea5b788d961d42633 X-EN-AuthUser: jearl@notengoamigos.org X-EN-OrigIP: 67.214.244.122 X-EN-OrigHost: unknown X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 199.232.76.165 X-Spam-Score: -5.9 (-----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -5.9 (-----) (info "(eintr) append-to-buffer overview") covers a previous version of append-to-buffer. In GNU Emacs 24.0.50.5 (i686-pc-linux-gnu, GTK+ Version 2.22.0) of 2011-03-14 on c3po Windowing system distributor `The X.Org Foundation', version 11.0.10900000 Important settings: value of $LC_ALL: nil value of $LC_COLLATE: nil value of $LC_CTYPE: nil value of $LC_MESSAGES: nil value of $LC_MONETARY: nil value of $LC_NUMERIC: nil value of $LC_TIME: nil value of $LANG: en_US.utf8 value of $XMODIFIERS: nil locale-coding-system: utf-8-unix default enable-multibyte-characters: t Major mode: Info Minor modes in effect: diff-auto-refine-mode: t yas/global-mode: t shell-dirtrack-mode: t global-semantic-mru-bookmark-mode: t global-semanticdb-minor-mode: t global-semantic-idle-completions-mode: t global-semantic-idle-scheduler-mode: t global-semantic-idle-summary-mode: t global-semantic-decoration-mode: t global-semantic-highlight-func-mode: t global-semantic-stickyfunc-mode: t semantic-mode: t show-paren-mode: t delete-selection-mode: t tooltip-mode: t mouse-wheel-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t line-number-mode: t transient-mark-mode: t Recent input: C-x k C-x o C-x o q C-h i u u u u u i s a v e - e x c u r , u SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC M-x r e b o p o r b e m d o e m Recent messages: uncompressing eintr-3.gz...done uncompressing eintr-2.gz...done uncompressing eintr-3.gz...done uncompressing eintr-3.gz...done uncompressing eintr-3.gz...done uncompressing eintr-1.gz...done Found `save-excursion' in Index. (Only match) [2 times] byte-code: End of buffer [3 times] Added 3 events for today Making completion list... [2 times] Load-path shadows: ~/.emacs.d/lisp/slime/slime hides /home/jearl/quicklisp/dists/quicklisp/software/slime-20110219-cvs/slime ~/.emacs.d/lisp/slime/hyperspec hides /home/jearl/quicklisp/dists/quicklisp/software/slime-20110219-cvs/hyperspec ~/.emacs.d/lisp/slime/slime-autoloads hides /home/jearl/quicklisp/dists/quicklisp/software/slime-20110219-cvs/slime-autoloads /usr/local/share/emacs/site-lisp/emms/tq hides /usr/local/share/emacs/24.0.50/lisp/emacs-lisp/tq Features: (shadow emacsbug jka-compr gnus-uu yenc gnus-html url-cache mm-url shr-color color shr gnus-dup mailalias smtpmail bbdb-gui vc-dispatcher vc-svn tramp-cache tramp-sh tramp tramp-compat tramp-loaddefs multi-isearch qp smiley ansi-color gnus-cite flow-fill gnus-async gnus-bcklg gnus-ml nndraft nnmh utf-7 nnimap utf7 nnfolder bbdb-gnus bbdb-snarf mail-extr bbdb-com rot13 disp-table netrc gnus-agent gnus-srvr gnus-score score-mode nnvirtual gnus-msg gnus-art mm-uu mml2015 epg-config mm-view mml-smime smime dig nntp proto-stream starttls gnus-cache nnir gnus-sum macroexp nnoo gnus-group gnus-undo nnmail mail-source gnus-fun gnus-start gnus-spec gnus-int gnus-range message sendmail rfc822 mml mml-sec mm-decode mm-bodies mm-encode mailabbrev gmm-utils mailheader gnus-win gnus gnus-ems nnheader mail-utils wid-edit calc-menu calc-aent calc calc-loaddefs calc-macs mule-util cal-move tabify org-table newcomment cal-china lunar solar cal-dst holidays hol-loaddefs cal-iso paredit company-files company-oddmuse company-keywords company-dabbrev-code company-dabbrev company-etags company-gtags company-ropemacs company-xcode company-semantic semantic/analyze semantic/sort semantic/scope semantic/analyze/fcn company-eclim company-css company-nxml rng-nxml rng-valid rng-loc rng-uri rng-parse nxml-parse rng-match rng-dt rng-util rng-pttrn nxml-ns nxml-mode nxml-outln nxml-rap nxml-util nxml-glyph nxml-enc xmltok company-elisp help-mode view company auctex-autoloads tex-site info company-autoloads package slime-fancy slime-fontifying-fu slime-package-fu slime-references slime-scratch slime-presentations slime-fuzzy slime-fancy-inspector slime-c-p-c slime-editing-commands slime-autodoc slime-parse slime-repl slime apropos hideshow pp hyperspec slime-autoloads emms-playlist-limit emms-volume emms-volume-amixer emms-i18n emms-history emms-score emms-stream-info emms-metaplaylist-mode emms-bookmarks emms-lastfm-client emms-lastfm-scrobbler emms-cue emms-mode-line-icon emms-browser sort emms-playlist-sort emms-last-played emms-player-xine emms-player-mpd tq emms-playing-time emms-lyrics emms-url hl-line emms-streams emms-tag-editor format-spec emms-mark emms-mode-line emms-cache emms-info-ogginfo emms-info-mp3info emms-playlist-mode emms-player-vlc emms-player-mplayer emms-player-simple emms-source-playlist emms-source-file dired emms-info-libtag emms-info later-do emms-setup emms emms-compat magit diff-mode log-edit pcvs-util add-log yasnippet dropdown-list ess-toolbar ess-mouse mouseme browse-url ess-menu speedbar sb-image dframe ess-swv ess-noweb noweb-font-lock-mode ess-bugs-l essd-els ess-sas-d ess-sas-l ess-sas-a executable shell ess-arc-d ess-vst-d ess-xls-d ess-lsp-l ess-sta-d ess-sta-l cc-vars cc-defs make-regexp ess-sp6-d ess-sp5-d ess-sp3-d ess-r-d ess-r-args ess-s-l ess-inf ess-utils ess-mode noweb-mode ess ess-custom ess-compat ess-site identica-mode edmacro kmacro json url-http tls url-auth mail-parse rfc2231 rfc2047 rfc2045 ietf-drums url-gw url url-proxy url-privacy url-expand url-methods url-history url-cookie url-util url-parse auth-source assoc gnus-util password-cache url-vars mm-util mail-prsvr mailcap longlines parse-time boxquote rect appt diary-lib diary-loaddefs vc-bzr flyspell ispell org-wl org-w3m org-vm org-rmail org-mhe org-mew org-irc org-jsinfo org-infojs org-html org-exp ob-exp org-exp-blocks org-info org-gnus org-docview org-bibtex org-bbdb org-agenda org warnings ob-emacs-lisp ob-tangle ob-ref ob-lob ob-table org-footnote org-src ob-comint ob-keys ob ob-eval org-complete org-list org-faces org-compat org-entities org-macs time-date noutline outline cal-menu calendar cal-loaddefs htmlize cl org-install semantic/mru-bookmark semantic/db-mode semantic/db eieio-base semantic/idle semantic/format ezimage semantic/ctxt semantic/decorate/mode semantic/tag-ls semantic/decorate pulse semantic/util-modes semantic/util semantic semantic/tag semantic/lex semantic/fw eieio byte-opt bytecomp byte-compile mode-local cedet flymake easy-mmode ropemacs pymacs bbdb-autoloads bbdb timezone dbus xml w3m-load quack thingatpt easymenu compile cmuscheme comint regexp-opt ring scheme ledger derived pcomplete esh-arg esh-util jadoea tango-dark-theme sha1 hex-util uniquify advice help-fns advice-preload paren delsel cus-start cus-load tooltip ediff-hook vc-hooks lisp-float-type mwheel x-win x-dnd tool-bar dnd fontset image fringe lisp-mode register page menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock syntax facemenu font-core frame cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean japanese hebrew greek romanian slovak czech european ethiopic indian cyrillic chinese case-table epa-hook jka-cmpr-hook help simple abbrev loaddefs button minibuffer faces cus-face files text-properties overlay md5 base64 format env code-pages mule custom widget hashtable-print-readable backquote make-network-process dbusbind dynamic-setting system-font-setting font-render-setting move-toolbar gtk x-toolkit x multi-tty emacs) From debbugs-submit-bounces@debbugs.gnu.org Sat Mar 19 17:59:03 2011 Received: (at 8275) by debbugs.gnu.org; 19 Mar 2011 21:59:03 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Q14Ao-00016h-AR for submit@debbugs.gnu.org; Sat, 19 Mar 2011 17:59:02 -0400 Received: from vm-emlprdomr-02.its.yale.edu ([130.132.50.143]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Q14An-00016T-5d for 8275@debbugs.gnu.org; Sat, 19 Mar 2011 17:59:01 -0400 Received: from furball ([64.134.40.187]) (authenticated bits=0) by vm-emlprdomr-02.its.yale.edu (8.14.4/8.14.4) with ESMTP id p2JLwsQG024774 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 19 Mar 2011 17:58:55 -0400 Received: by furball (Postfix, from userid 1000) id 43B3E16030E; Sat, 19 Mar 2011 17:58:55 -0400 (EDT) From: Chong Yidong To: "Robert J. Chassell" Subject: Re: bug#8275: 24.0.50; Intro to Emacs Lisp Issue References: <871v25d4zl.fsf@notengoamigos.org> Date: Sat, 19 Mar 2011 17:58:55 -0400 In-Reply-To: <871v25d4zl.fsf@notengoamigos.org> (Jason Earl's message of "Thu, 17 Mar 2011 11:35:58 -0600") Message-ID: <87zkoqwz4w.fsf@stupidchicken.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Scanned-By: MIMEDefang 2.71 on 130.132.50.143 X-Spam-Score: -2.6 (--) X-Debbugs-Envelope-To: 8275 Cc: 8275@debbugs.gnu.org, Jason Earl X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) Hi Bob, Do you want to fix this, or shall I try? The problem is that append-to-buffer now uses let* and with-current-buffer, so this might break the flow of the text. At this point in the book, let* and with-current-buffer are not yet introduced. Jason Earl writes: > (info "(eintr) append-to-buffer overview") covers a previous version of > append-to-buffer. From debbugs-submit-bounces@debbugs.gnu.org Sat Mar 19 21:08:44 2011 Received: (at 8275) by debbugs.gnu.org; 20 Mar 2011 01:08:44 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Q178N-0005Ef-W0 for submit@debbugs.gnu.org; Sat, 19 Mar 2011 21:08:44 -0400 Received: from fencepost.gnu.org ([140.186.70.10]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Q176e-0005Ba-TQ for 8275@debbugs.gnu.org; Sat, 19 Mar 2011 21:06:57 -0400 Received: from bob by fencepost.gnu.org with local (Exim 4.71) (envelope-from ) id 1Q176Y-0001Lh-Ao; Sat, 19 Mar 2011 21:06:50 -0400 Date: Sat, 19 Mar 2011 21:06:50 -0400 Message-Id: In-reply-to: <87zkoqwz4w.fsf@stupidchicken.com> (message from Chong Yidong on Sat, 19 Mar 2011 17:58:55 -0400) To: Chong Yidong Subject: Re: bug#8275: 24.0.50; Intro to Emacs Lisp Issue From: bob@gnu.org (Robert J. Chassell) X-Spam-Score: -6.6 (------) X-Debbugs-Envelope-To: 8275 X-Mailman-Approved-At: Sat, 19 Mar 2011 21:08:42 -0400 Cc: 8275@debbugs.gnu.org, bob@gnu.org, jearl@notengoamigos.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Reply-To: bob@gnu.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.6 (------) Do you want to fix this, or shall I try? The problem is that append-to-buffer now uses let* and with-current-buffer, so this might break the flow of the text. At this point in the book, let* and with-current-buffer are not yet introduced. Jason Earl writes: > (info "(eintr) append-to-buffer overview") covers a previous version of > append-to-buffer. Please try to fix it. I am getting worse and have made many mistakes just in composing this. (I think I found them all.) Please try to fix any in the future, too. -- Robert J. Chassell bob@gnu.org bob@rattlesnake.com http://www.rattlesnake.com http://www.teak.cc From debbugs-submit-bounces@debbugs.gnu.org Sat Mar 19 23:34:57 2011 Received: (at 8275) by debbugs.gnu.org; 20 Mar 2011 03:34:57 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Q19Ps-0008L2-Du for submit@debbugs.gnu.org; Sat, 19 Mar 2011 23:34:56 -0400 Received: from ironport2-out.teksavvy.com ([206.248.154.183] helo=ironport2-out.pppoe.ca) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Q19Pq-0008Kq-2Z for 8275@debbugs.gnu.org; Sat, 19 Mar 2011 23:34:54 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEABgShU1Ld/X5/2dsb2JhbACldHiITbg2hWMElWk X-IronPort-AV: E=Sophos;i="4.63,213,1299474000"; d="scan'208";a="97266527" Received: from 75-119-245-249.dsl.teksavvy.com (HELO pastel.home) ([75.119.245.249]) by ironport2-out.pppoe.ca with ESMTP/TLS/ADH-AES256-SHA; 19 Mar 2011 23:34:48 -0400 Received: by pastel.home (Postfix, from userid 20848) id C0BB45914C; Sat, 19 Mar 2011 23:34:47 -0400 (EDT) From: Stefan Monnier To: Chong Yidong Subject: Re: bug#8275: 24.0.50; Intro to Emacs Lisp Issue Message-ID: References: <871v25d4zl.fsf@notengoamigos.org> <87zkoqwz4w.fsf@stupidchicken.com> Date: Sat, 19 Mar 2011 23:34:47 -0400 In-Reply-To: <87zkoqwz4w.fsf@stupidchicken.com> (Chong Yidong's message of "Sat, 19 Mar 2011 17:58:55 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.0 (--) X-Debbugs-Envelope-To: 8275 Cc: 8275@debbugs.gnu.org, "Robert J. Chassell" , Jason Earl X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.0 (--) > Do you want to fix this, or shall I try? The problem is that > append-to-buffer now uses let* and with-current-buffer, so this might > break the flow of the text. At this point in the book, let* and > with-current-buffer are not yet introduced. Here are some thoughts: - I don't think it's of any importance that the example code be identical to the currently used code. - append-to-buffer might not be the best example since AFAICT copying text from one buffer to another is not a common operation and in most cases this is done via buffer-substring + insert (often with some processing on the string between the two) rather than with insert-buffer-substring which is a rarely used function. - yes, I think the text would benefit from some rethink to try and present with-current-buffer in preference to set-buffer, but it's not a simple fix. Stefan From debbugs-submit-bounces@debbugs.gnu.org Sun Mar 20 17:14:54 2011 Received: (at submit) by debbugs.gnu.org; 20 Mar 2011 21:14:55 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Q1Pxe-0007iO-7q for submit@debbugs.gnu.org; Sun, 20 Mar 2011 17:14:54 -0400 Received: from eggs.gnu.org ([140.186.70.92]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Q1Pxc-0007iB-9p for submit@debbugs.gnu.org; Sun, 20 Mar 2011 17:14:53 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Q1PxW-000200-4G for submit@debbugs.gnu.org; Sun, 20 Mar 2011 17:14:47 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=unavailable version=3.3.1 Received: from lists.gnu.org ([199.232.76.165]:49521) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Q1PxW-0001zu-2A for submit@debbugs.gnu.org; Sun, 20 Mar 2011 17:14:46 -0400 Received: from [140.186.70.92] (port=32916 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q1PxU-0002Bd-Vc for bug-gnu-emacs@gnu.org; Sun, 20 Mar 2011 17:14:45 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Q1PxT-0001zF-Rq for bug-gnu-emacs@gnu.org; Sun, 20 Mar 2011 17:14:44 -0400 Received: from moutng.kundenserver.de ([212.227.126.171]:60859) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Q1PxT-0001y5-Fk for bug-gnu-emacs@gnu.org; Sun, 20 Mar 2011 17:14:43 -0400 Received: from [192.168.178.29] (brln-4d0c3aee.pool.mediaWays.net [77.12.58.238]) by mrelayeu.kundenserver.de (node=mrbap3) with ESMTP (Nemesis) id 0M3SWO-1Pjt6e2zSK-00qxuA; Sun, 20 Mar 2011 22:14:40 +0100 Message-ID: <4D866FA7.3070508@easy-emacs.de> Date: Sun, 20 Mar 2011 22:20:39 +0100 From: =?ISO-8859-15?Q?Andreas_R=F6hler?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; de; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: bug-gnu-emacs@gnu.org Subject: Re: bug#8275: 24.0.50; Intro to Emacs Lisp Issue References: <871v25d4zl.fsf@notengoamigos.org> <87zkoqwz4w.fsf@stupidchicken.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:A8NmO6Ja4jYhwbQLG7zA1rW9XN2WMF/Y0vdkgpJ6OIv PdwJKZ7c9LlN9TsKPtxB0FsfdmANmq6HNHrlXYFv357VveBzx2 443zKwL2CdbVG4jdhP/AFH5k0sgzJ4C+oqPYFI9tC9vEeBVegC nI06vOugyWjotMLL0HnSBrHFHfg0hw4CJfQNoGjUnOIUu0i0k7 DtVdDtTmfwF0QULciu0i2JbtwAfcuouA8kfvVr83u8= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 199.232.76.165 X-Spam-Score: -6.6 (------) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.6 (------) Am 20.03.2011 04:34, schrieb Stefan Monnier: >> Do you want to fix this, or shall I try? The problem is that >> append-to-buffer now uses let* and with-current-buffer, so this might >> break the flow of the text. At this point in the book, let* and >> with-current-buffer are not yet introduced. > > Here are some thoughts: > - I don't think it's of any importance that the example code be > identical to the currently used code. > - append-to-buffer might not be the best example since AFAICT copying > text from one buffer to another is not a common operation and in most > cases this is done via buffer-substring + insert (often with some > processing on the string between the two) rather than with > insert-buffer-substring which is a rarely used function. > - yes, I think the text would benefit from some rethink to try and present > with-current-buffer in preference to set-buffer, but it's not > a simple fix. > > > Stefan > > > > just add: "as GNU Emacs version 19 used it" Cheers Andreas From debbugs-submit-bounces@debbugs.gnu.org Wed Nov 04 07:53:28 2020 Received: (at control) by debbugs.gnu.org; 4 Nov 2020 12:53:28 +0000 Received: from localhost ([127.0.0.1]:47840 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kaII4-0000ju-7Z for submit@debbugs.gnu.org; Wed, 04 Nov 2020 07:53:28 -0500 Received: from mail-ej1-f50.google.com ([209.85.218.50]:41037) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kaII0-0000jf-Fx for control@debbugs.gnu.org; Wed, 04 Nov 2020 07:53:27 -0500 Received: by mail-ej1-f50.google.com with SMTP id cw8so16028552ejb.8 for ; Wed, 04 Nov 2020 04:53:24 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:date:message-id:subject:to; bh=ZvVFkC4q6ISJlra8CkdJ1xe0Et2dUDOPJaMt+i/S3T8=; b=LHhoUnM7WrqYwXcpS5PnfzPpSWr5vvoe9fHhKI7nImKfkSohDdpx3h54zSaQ5iBJTH XZBqc9sojbWNT0oEMOWCG+0xlCkKoJbaBbnmN/ncZgkPMVSYJH9Fo5r8PHoiisaFJVEx Hx0nofPDuGmrlXrl4pxR/c1i9L6KCjpPhnrfwwNuzkuKhZ8ddTtCYVGe28sP2QV9n7py h0/2IEF259GxujQZlvKJTCRs79CbW5lis0RxOU4/7/duewGhSc8NrR2xM30ZVXvHGFB9 SX9ySW89Gg5IY8nI+wpHnJKGNVbGwCnCC6dPxll/OjO6fB1X8hTPlGx13X3Hf2CZ2pYS NYwQ== X-Gm-Message-State: AOAM532G3yOVqLS5kTdSB2/OrM8B6AxoGupuWTaGCbuvTSRVpqyMrWC9 OAbjjG6MDxy7N1uFdPNsalwAXFUpSU71NM+2tUbf5JwW X-Google-Smtp-Source: ABdhPJww90Ytm+fExAotPU5go/zJpm+dO8l0dJIPBD/JQtYY7r5R1eq4ddOJAAzKF5p+tzeIF+g0iUrmY09gW13zuC0= X-Received: by 2002:a17:906:1246:: with SMTP id u6mr24784562eja.432.1604494398335; Wed, 04 Nov 2020 04:53:18 -0800 (PST) Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Wed, 4 Nov 2020 04:53:17 -0800 From: Stefan Kangas MIME-Version: 1.0 Date: Wed, 4 Nov 2020 04:53:17 -0800 Message-ID: Subject: To: control@debbugs.gnu.org Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 2.5 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: severity 8275 wishlist thanks Content analysis details: (2.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.2 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different -0.0 SPF_PASS SPF: sender matches SPF record 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (stefankangas[at]gmail.com) -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [209.85.218.50 listed in list.dnswl.org] 0.0 RCVD_IN_MSPIKE_H3 RBL: Good reputation (+3) [209.85.218.50 listed in wl.mailspike.net] 2.0 BLANK_SUBJECT Subject is present but empty 0.2 FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and EnvelopeFrom freemail headers are different 0.0 RCVD_IN_MSPIKE_WL Mailspike good senders 0.0 UNPARSEABLE_RELAY Informational: message has unparseable relay lines X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.5 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: severity 8275 wishlist thanks Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 RCVD_IN_MSPIKE_H3 RBL: Good reputation (+3) [209.85.218.50 listed in wl.mailspike.net] -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [209.85.218.50 listed in list.dnswl.org] 0.2 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different -0.0 SPF_PASS SPF: sender matches SPF record 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (stefankangas[at]gmail.com) 2.0 BLANK_SUBJECT Subject is present but empty 0.2 FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and EnvelopeFrom freemail headers are different 0.0 RCVD_IN_MSPIKE_WL Mailspike good senders 0.0 UNPARSEABLE_RELAY Informational: message has unparseable relay lines -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list manager severity 8275 wishlist thanks From debbugs-submit-bounces@debbugs.gnu.org Thu Oct 21 15:43:11 2021 Received: (at 8275-done) by debbugs.gnu.org; 21 Oct 2021 19:43:11 +0000 Received: from localhost ([127.0.0.1]:58594 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mddy2-00055m-PN for submit@debbugs.gnu.org; Thu, 21 Oct 2021 15:43:11 -0400 Received: from mail-pj1-f46.google.com ([209.85.216.46]:56034) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mddxs-00054v-MD for 8275-done@debbugs.gnu.org; Thu, 21 Oct 2021 15:43:09 -0400 Received: by mail-pj1-f46.google.com with SMTP id om14so1265150pjb.5 for <8275-done@debbugs.gnu.org>; Thu, 21 Oct 2021 12:43:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:in-reply-to:references:user-agent :mime-version:date:message-id:subject:to:cc; bh=BTeGoPoXrVJDhNXthDLLQibgX3xMWM2Jdl2skyiMYkw=; b=mL6CVPz5mRPfsEe+wQGt7dNOQsHFEK6QtHmNR9FGyxymkK7zBFyM4YdHcGzJiSedQu 2iTij84e0aAGWfenewJSjvgQ3y546LYKGQKW2dHtrab3UEbLGQihRoKAJ/dxtKtLyYRE oT3BH+qvT0oliEERmH46D3MMxPKtovro657JaKtwX8TgTvbiJsUXu9jaLJbNlB+AaJsY qMV9V1Cwqoa2ks5Zzy+DvhnR5od/61/hUSwhDabhOmyhhZB8PQPmX9QIqYgUSqQqpyTn Ee+TLLlgB/3xUKJ0Gsg58RqPGn3lDP7g2wagizrMTrC0eKYnngD883cZhFgUZbvoStYM aWZw== X-Gm-Message-State: AOAM5307j9t9Yjow12qDLN5K4lYbxuL24iNugHq10/Nfjnu/1TsrD4dB 9FxgTT14twxNWg0JY94W6nSd/EAhFqToBW+6NoA= X-Google-Smtp-Source: ABdhPJwzLV+mI9FOFExwXH4U7PZoilSSSwrepk9wLukHZvFYvZlam1GKmgwslbV3S8oR+ezlhhD6j2g5xA4az0O2kD8= X-Received: by 2002:a17:90a:245:: with SMTP id t5mr8753968pje.133.1634845374852; Thu, 21 Oct 2021 12:42:54 -0700 (PDT) Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Thu, 21 Oct 2021 12:42:54 -0700 From: Stefan Kangas In-Reply-To: (Stefan Monnier's message of "Sat, 19 Mar 2011 23:34:47 -0400") References: <871v25d4zl.fsf@notengoamigos.org> <87zkoqwz4w.fsf@stupidchicken.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Date: Thu, 21 Oct 2021 12:42:54 -0700 Message-ID: Subject: Re: bug#8275: 24.0.50; Intro to Emacs Lisp Issue To: Stefan Monnier Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.5 (/) X-Debbugs-Envelope-To: 8275-done Cc: 8275-done@debbugs.gnu.org, Chong Yidong , Jason Earl X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) Stefan Monnier writes: >> Do you want to fix this, or shall I try? The problem is that >> append-to-buffer now uses let* and with-current-buffer, so this might >> break the flow of the text. At this point in the book, let* and >> with-current-buffer are not yet introduced. > > Here are some thoughts: > - I don't think it's of any importance that the example code be > identical to the currently used code. > - append-to-buffer might not be the best example since AFAICT copying > text from one buffer to another is not a common operation and in most > cases this is done via buffer-substring + insert (often with some > processing on the string between the two) rather than with > insert-buffer-substring which is a rarely used function. > - yes, I think the text would benefit from some rethink to try and present > with-current-buffer in preference to set-buffer, but it's not > a simple fix. I've now added the above comments to a comment in the file itself. If anyone intends to review that section, they will find the comment and a pointer to this bug report. From unknown Fri Sep 05 08:41:37 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Fri, 19 Nov 2021 12:24:07 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator From debbugs-submit-bounces@debbugs.gnu.org Sun Dec 12 01:44:47 2021 Received: (at control) by debbugs.gnu.org; 12 Dec 2021 06:44:47 +0000 Received: from localhost ([127.0.0.1]:50529 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mwIbH-00082c-6H for submit@debbugs.gnu.org; Sun, 12 Dec 2021 01:44:47 -0500 Received: from out1.migadu.com ([91.121.223.63]:58898) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mwIbD-00082O-4g for control@debbugs.gnu.org; Sun, 12 Dec 2021 01:44:45 -0500 X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ego.team; s=key1; t=1639291481; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type; bh=/HvqwspBt7Z7ki9gU5Skf/r+ei9d1fOUXmFNrga8w5s=; b=vpFiswLrogcrsRhp0DiVQXpMOes1TgoEiVlbiE1YjASlxZu65MSOWEOooAkQ1XYAIRTQHN VQrT6VSfQCUvjX9JTxv872wvql6sSfCYEpcgTib6UQ1bYAUcw5oaHkoM53Q1p6P9G2bI/L zoisU2iCfXZWhrdca8dxaRbPJHAnYzg= From: Y. E. To: control@debbugs.gnu.org Subject: Unarchive 8275 Date: Sun, 12 Dec 2021 08:44:39 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-Migadu-Flow: FLOW_OUT X-Migadu-Auth-User: yuga@ego.team X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: "Y. E." Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) unarchive 8275 thanks From debbugs-submit-bounces@debbugs.gnu.org Sun Dec 12 01:50:24 2021 Received: (at 8275) by debbugs.gnu.org; 12 Dec 2021 06:50:24 +0000 Received: from localhost ([127.0.0.1]:50535 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mwIgh-0008Dd-PH for submit@debbugs.gnu.org; Sun, 12 Dec 2021 01:50:24 -0500 Received: from out2.migadu.com ([188.165.223.204]:31110) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mwIge-0008DH-Up for 8275@debbugs.gnu.org; Sun, 12 Dec 2021 01:50:22 -0500 X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ego.team; s=key1; t=1639291818; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to; bh=B/hh0gCi9cgOSgXGitzFZLP2oW0iJ53bEN/ys4Exuq8=; b=qFDmIvp+TiT6rKFEO9JCcKrX5yLj6y8G9RNtJ+UynPvwdzUxb9ID29Nbg/wsMoIwoNXPNL Itot1y0fEQzJU1uL63yoxnwUp1rJANJIyqIQr8j2YphNZa38Pv46fCjJn7GpteeYtlLqFb FKmA2W1bjKUwP2Ay0gsR8i0EJY5Gib4= From: Y. E. To: Stefan Kangas Subject: [PATCH] Re: bug#8275: 24.0.50; Intro to Emacs Lisp Issue In-Reply-To: (message from Stefan Kangas on Thu, 21 Oct 2021 12:42:54 -0700) Date: Sun, 12 Dec 2021 08:50:16 +0200 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Migadu-Flow: FLOW_OUT X-Migadu-Auth-User: yuga@ego.team X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 8275 Cc: 8275@debbugs.gnu.org, cyd@stupidchicken.com, monnier@iro.umontreal.ca, jearl@notengoamigos.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: "Y. E." Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --=-=-= Content-Type: text/plain >>> Do you want to fix this, or shall I try? The problem is that >>> append-to-buffer now uses let* and with-current-buffer, so this might >>> break the flow of the text. At this point in the book, let* and >>> with-current-buffer are not yet introduced. The current version of the 'append-to-buffer' section: - Provides explanations based on the 'append-to-buffer' function definition from GNU Emacs 22, which uses 'let*' but not 'with-current-buffer'. - Already introduces 'let*'. The suggested patch improves the flow of the text by re-organizing it to correspond better the structure of the 'append-to-buffer' function and providing more details about the 'let*' expression in it. >> Here are some thoughts: >> - I don't think it's of any importance that the example code be >> identical to the currently used code. I also tend to think it should be fine to stick to some Emacs' version (22 in this case) of the code, at least at this stage. >> - append-to-buffer might not be the best example since AFAICT copying >> text from one buffer to another is not a common operation and in most >> cases this is done via buffer-substring + insert (often with some >> processing on the string between the two) rather than with >> insert-buffer-substring which is a rarely used function. >> - yes, I think the text would benefit from some rethink to try and present >> with-current-buffer in preference to set-buffer, but it's not >> a simple fix. The suggested patch concentrates on cleanups rather than rewrites, because this may be a sufficient change (at this stage, again) and an easier one to accomplish. > I've now added the above comments to a comment in the file itself. If > anyone intends to review that section, they will find the comment and a > pointer to this bug report. The patch removes the mentioned comment since the suggested changes cover fixing (or "wontfixing") the entries of the comment. A pointer to this bug report was added to the suggested commit message. --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=0001-Cleanup-append-to-buffer-section-in-ELisp-Intro.patch Content-Description: Cleanup append-to-buffer section in ELisp Intro >From 5c9495b5db9ecf168333d589260601948e26bfd8 Mon Sep 17 00:00:00 2001 From: YugaEgo Date: Fri, 10 Dec 2021 23:29:51 +0200 Subject: [PATCH] Cleanup append-to-buffer section in ELisp Intro * doc/lispintro/emacs-lisp-intro.texi (append-to-buffer, Buffer Related Review, fwd-para let): Finalize shifting focus of the 'let*' introduction to the 'append-to-buffer' section. Improve wording, fix typos, remove redundant comments (Bug#8275). --- doc/lispintro/emacs-lisp-intro.texi | 147 ++++++++++------------------ 1 file changed, 49 insertions(+), 98 deletions(-) diff --git a/doc/lispintro/emacs-lisp-intro.texi b/doc/lispintro/emacs-lisp-intro.texi index 9f1f10e8d6..737749c625 100644 --- a/doc/lispintro/emacs-lisp-intro.texi +++ b/doc/lispintro/emacs-lisp-intro.texi @@ -4896,25 +4896,6 @@ Body of mark-whole-buffer is set at the end of the buffer. The whole buffer is, therefore, the region. -@c FIXME: the definition of append-to-buffer has been changed (in -@c 2010-03-30). -@c In Bug#8275, Stefan Monner writes: -@c >> Do you want to fix this, or shall I try? The problem is that -@c >> append-to-buffer now uses let* and with-current-buffer, so this might -@c >> break the flow of the text. At this point in the book, let* and -@c >> with-current-buffer are not yet introduced. -@c > -@c > Here are some thoughts: -@c > - I don't think it's of any importance that the example code be -@c > identical to the currently used code. -@c > - append-to-buffer might not be the best example since AFAICT copying -@c > text from one buffer to another is not a common operation and in most -@c > cases this is done via buffer-substring + insert (often with some -@c > processing on the string between the two) rather than with -@c > insert-buffer-substring which is a rarely used function. -@c > - yes, I think the text would benefit from some rethink to try and present -@c > with-current-buffer in preference to set-buffer, but it's not -@c > a simple fix. @node append-to-buffer @section The Definition of @code{append-to-buffer} @findex append-to-buffer @@ -4949,7 +4930,7 @@ append-to-buffer overview to, and the region that will be copied. @need 1250 -Here is the complete text of the function: +Here is the complete text of the function in GNU Emacs 22: @smallexample @group @@ -5017,7 +4998,9 @@ append interactive Since the @code{append-to-buffer} function will be used interactively, the function must have an @code{interactive} expression. (For a review of @code{interactive}, see @ref{Interactive, , Making a -Function Interactive}.) The expression reads as follows: +Function Interactive}.) + +The expression reads as follows: @smallexample @group @@ -5046,7 +5029,7 @@ append interactive The first argument to @code{other-buffer}, the exception, is yet another function, @code{current-buffer}. That is not going to be -returned. The second argument is the symbol for true, @code{t}. that +returned. The second argument is the symbol for true: @code{t}, that tells @code{other-buffer} that it may show visible buffers (except in this case, it will not show the current buffer, which makes sense). @@ -5082,33 +5065,6 @@ append interactive @node append-to-buffer body @subsection The Body of @code{append-to-buffer} -@ignore -in GNU Emacs 22 in /usr/local/src/emacs/lisp/simple.el - -(defun append-to-buffer (buffer start end) - "Append to specified buffer the text of the region. -It is inserted into that buffer before its point. - -When calling from a program, give three arguments: -BUFFER (or buffer name), START and END. -START and END specify the portion of the current buffer to be copied." - (interactive - (list (read-buffer "Append to buffer: " (other-buffer (current-buffer) t)) - (region-beginning) (region-end))) - (let ((oldbuf (current-buffer))) - (save-excursion - (let* ((append-to (get-buffer-create buffer)) - (windows (get-buffer-window-list append-to t t)) - point) - (set-buffer append-to) - (setq point (point)) - (barf-if-buffer-read-only) - (insert-buffer-substring oldbuf start end) - (dolist (window windows) - (when (= (window-point window) point) - (set-window-point window (point)))))))) -@end ignore - The body of the @code{append-to-buffer} function begins with @code{let}. As we have seen before (@pxref{let, , @code{let}}), the purpose of a @@ -5127,7 +5083,7 @@ append-to-buffer body "@var{documentation}@dots{}" (interactive @dots{}) (let ((@var{variable} @var{value})) - @var{body}@dots{}) + @var{body}@dots{})) @end group @end smallexample @@ -5247,19 +5203,40 @@ append save-excursion @need 1200 @noindent +@anchor{let* introduced} +@cindex @code{let*} expression +@findex let* In this function, the body of the @code{save-excursion} contains only one expression, the @code{let*} expression. You know about a -@code{let} function. The @code{let*} function is different. It has a -@samp{*} in its name. It enables Emacs to set each variable in its -varlist in sequence, one after another. +@code{let} function. The @code{let*} function is different. It +enables Emacs to set each variable in its varlist in sequence, one +after another; such that variables in the latter part of the varlist +can make use of the values to which Emacs set variables earlier in the +varlist. -Its critical feature is that variables later in the varlist can make -use of the values to which Emacs set variables earlier in the varlist. -@xref{fwd-para let, , The @code{let*} expression}. +Looking at the @code{let*} expression in @code{append-to-buffer}: -We will skip functions like @code{let*} and focus on two: the -@code{set-buffer} function and the @code{insert-buffer-substring} -function. +@smallexample +@group +(let* ((append-to (get-buffer-create buffer)) + (windows (get-buffer-window-list append-to t t)) + point) + BODY...) +@end group +@end smallexample + +@noindent +we see that @code{append-to} is bound to the value returned by the +@w{@code{(get-buffer-create buffer)}}. On the next line, +@code{append-to} is used as an argument to +@code{get-buffer-window-list}; this would not be possible with the +@code{let} expression. Note that @code{point} is automatically bound +to @code{nil}, the same way as it would be done in the @code{let} +statement. + +Now let's focus on the functions @code{set-buffer} and +@code{insert-buffer-substring} in the body of the @code{let*} +expression. @need 1250 In the old days, the @code{set-buffer} expression was simply @@ -5277,27 +5254,8 @@ append save-excursion @end smallexample @noindent -@code{append-to} is bound to @code{(get-buffer-create buffer)} earlier -on in the @code{let*} expression. That extra binding would not be -necessary except for that @code{append-to} is used later in the -varlist as an argument to @code{get-buffer-window-list}. - -@ignore -in GNU Emacs 22 - - (let ((oldbuf (current-buffer))) - (save-excursion - (let* ((append-to (get-buffer-create buffer)) - (windows (get-buffer-window-list append-to t t)) - point) - (set-buffer append-to) - (setq point (point)) - (barf-if-buffer-read-only) - (insert-buffer-substring oldbuf start end) - (dolist (window windows) - (when (= (window-point window) point) - (set-window-point window (point)))))))) -@end ignore +This is because @code{append-to} was bound to @code{(get-buffer-create +buffer)} earlier on in the @code{let*} expression. The @code{append-to-buffer} function definition inserts text from the buffer in which you are currently to a named buffer. It happens that @@ -5394,6 +5352,12 @@ Buffer Related Review @item mark-whole-buffer Mark the whole buffer as a region. Normally bound to @kbd{C-x h}. +@item let* +Declare a list of variables and give them an initial value; then +evaluate the rest of the expressions in the body of @code{let*}. The +values of the variables can be used to bind ensuing variables in the +list. + @item set-buffer Switch the attention of Emacs to another buffer, but do not change the window being displayed. Used when the program rather than a human is @@ -12896,25 +12860,12 @@ forward-paragraph in brief @node fwd-para let @unnumberedsubsec The @code{let*} expression -The next line of the @code{forward-paragraph} function begins a -@code{let*} expression. This is different from @code{let}. The -symbol is @code{let*} not @code{let}. - @findex let* -The @code{let*} special form is like @code{let} except that Emacs sets -each variable in sequence, one after another, and variables in the -latter part of the varlist can make use of the values to which Emacs -set variables in the earlier part of the varlist. - -@ignore -( refappend save-excursion, , code save-excursion in code append-to-buffer .) -@end ignore - -(@ref{append save-excursion, , @code{save-excursion} in @code{append-to-buffer}}.) - -In the @code{let*} expression in this function, Emacs binds a total of -seven variables: @code{opoint}, @code{fill-prefix-regexp}, -@code{parstart}, @code{parsep}, @code{sp-parstart}, @code{start}, and +The next line of the @code{forward-paragraph} function begins a +@code{let*} expression (@pxref{let* introduced,,@code{let*} +introduced}), in which Emacs binds a total of seven variables: +@code{opoint}, @code{fill-prefix-regexp}, @code{parstart}, +@code{parsep}, @code{sp-parstart}, @code{start}, and @code{found-start}. The variable @code{parsep} appears twice, first, to remove instances -- 2.34.1 --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Sun Dec 12 03:14:36 2021 Received: (at 8275) by debbugs.gnu.org; 12 Dec 2021 08:14:36 +0000 Received: from localhost ([127.0.0.1]:50605 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mwK0B-0004Eu-FZ for submit@debbugs.gnu.org; Sun, 12 Dec 2021 03:14:35 -0500 Received: from eggs.gnu.org ([209.51.188.92]:43094) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mwK09-0004Ej-To for 8275@debbugs.gnu.org; Sun, 12 Dec 2021 03:14:34 -0500 Received: from [2001:470:142:3::e] (port=53792 helo=fencepost.gnu.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mwK03-0001aa-Ot; Sun, 12 Dec 2021 03:14:27 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=4ED61o1qQhfblDiPnoXKmXNFr1JHy2VNTnxlyYcE4zg=; b=dUH/hlGSD/RQ 8v0AGEaQ+qNohC+vy8Rb3KajKZZZ0WNlbb98dXW5eUfrbnF8GP1kqstlIpVe6JZObky1amRyZ6qeV 8ou2wRBWjnCBlzcYjkQsJhqzgsGniLD22uAnycWMBo1piDLgPmnScpBgA2dQb6W07ByixuByOZR5O 4MV0peiUuLu/6l8ZTjlqklHDTht7WZMg+Z+HmyKcnxtV70+neorIiSyNvVCRvKNBzArtGLvD0LeVB ILT96PKGK8Gud3PFRW+NdGv8JKjbKFPyuoQQC9kupIkefQuvZmwSkysDZTGAZ/bk4yitFOG3pDdRS qN1ZqOAbnKcxrrVc4UR9Iw==; Received: from [87.69.77.57] (port=3957 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mwK03-0007kk-Hq; Sun, 12 Dec 2021 03:14:27 -0500 Date: Sun, 12 Dec 2021 10:14:18 +0200 Message-Id: <83czm2p7dx.fsf@gnu.org> From: Eli Zaretskii To: "Y. E." In-Reply-To: (bug-gnu-emacs@gnu.org) Subject: Re: bug#8275: [PATCH] Re: bug#8275: 24.0.50; Intro to Emacs Lisp Issue References: <871v25d4zl.fsf@notengoamigos.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 8275 Cc: 8275@debbugs.gnu.org, cyd@stupidchicken.com, stefan@marxist.se, monnier@iro.umontreal.ca, jearl@notengoamigos.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: 8275@debbugs.gnu.org, cyd@stupidchicken.com, monnier@iro.umontreal.ca, > jearl@notengoamigos.org > Date: Sun, 12 Dec 2021 08:50:16 +0200 > From: Y. E. via "Bug reports for GNU Emacs, > the Swiss army knife of text editors" > > The suggested patch concentrates on cleanups rather than rewrites, > because this may be a sufficient change (at this stage, again) and an > easier one to accomplish. > > > I've now added the above comments to a comment in the file itself. If > > anyone intends to review that section, they will find the comment and a > > pointer to this bug report. > > The patch removes the mentioned comment since the suggested changes > cover fixing (or "wontfixing") the entries of the comment. A pointer to > this bug report was added to the suggested commit message. Thanks, please see some comments below. > -Here is the complete text of the function: > +Here is the complete text of the function in GNU Emacs 22: Instead of alluding to a past version of Emacs, how about saying something more vague, like "a variant of the function", or "a possible implementation of the function"? The goal of this manual is not to show actual code used by Emacs, it's to teach programming in Emacs Lisp. So whether this is, or was, an actual implementation is immaterial from the didactic POV. > -returned. The second argument is the symbol for true, @code{t}. that > +returned. The second argument is the symbol for true: @code{t}, that I think the correct fix here is to capitalize "That" (and add a space), so that it's the next separate sentence. > +@anchor{let* introduced} > +@cindex @code{let*} expression > +@findex let* It isn't useful to have several index entries that begin with the same text and point to the same place. This manual has just one index, where all the index entries are placed together. So I suggest removing one of these two index entries. > In this function, the body of the @code{save-excursion} contains only > one expression, the @code{let*} expression. You know about a > -@code{let} function. The @code{let*} function is different. It has a > -@samp{*} in its name. It enables Emacs to set each variable in its > -varlist in sequence, one after another. > +@code{let} function. The @code{let*} function is different. It > +enables Emacs to set each variable in its varlist in sequence, one > +after another; such that variables in the latter part of the varlist > +can make use of the values to which Emacs set variables earlier in the > +varlist. > > -Its critical feature is that variables later in the varlist can make > -use of the values to which Emacs set variables earlier in the varlist. > -@xref{fwd-para let, , The @code{let*} expression}. I don't understand the rationale for this change. It looks like simple rewording of the original, with different partition into sentences. I see nothing wrong with the original text, so why did you need to change it? > -We will skip functions like @code{let*} and focus on two: the > -@code{set-buffer} function and the @code{insert-buffer-substring} > -function. > +@smallexample > +@group > +(let* ((append-to (get-buffer-create buffer)) > + (windows (get-buffer-window-list append-to t t)) > + point) > + BODY...) > +@end group > +@end smallexample > + > +@noindent > +we see that @code{append-to} is bound to the value returned by the > +@w{@code{(get-buffer-create buffer)}}. On the next line, > +@code{append-to} is used as an argument to > +@code{get-buffer-window-list}; this would not be possible with the > +@code{let} expression. Note that @code{point} is automatically bound > +to @code{nil}, the same way as it would be done in the @code{let} > +statement. > + > +Now let's focus on the functions @code{set-buffer} and > +@code{insert-buffer-substring} in the body of the @code{let*} > +expression. So, unlike the original author, you consider it important to explain the let* part here? Why is that? > @@ -5394,6 +5352,12 @@ Buffer Related Review > @item mark-whole-buffer > Mark the whole buffer as a region. Normally bound to @kbd{C-x h}. > > +@item let* > +Declare a list of variables and give them an initial value; then > +evaluate the rest of the expressions in the body of @code{let*}. The > +values of the variables can be used to bind ensuing variables in the > +list. > + > @item set-buffer > Switch the attention of Emacs to another buffer, but do not change the > window being displayed. Used when the program rather than a human is > @@ -12896,25 +12860,12 @@ forward-paragraph in brief > @node fwd-para let > @unnumberedsubsec The @code{let*} expression > > -The next line of the @code{forward-paragraph} function begins a > -@code{let*} expression. This is different from @code{let}. The > -symbol is @code{let*} not @code{let}. > - > @findex let* > -The @code{let*} special form is like @code{let} except that Emacs sets > -each variable in sequence, one after another, and variables in the > -latter part of the varlist can make use of the values to which Emacs > -set variables in the earlier part of the varlist. > - > -@ignore > -( refappend save-excursion, , code save-excursion in code append-to-buffer .) > -@end ignore > - > -(@ref{append save-excursion, , @code{save-excursion} in @code{append-to-buffer}}.) > - > -In the @code{let*} expression in this function, Emacs binds a total of > -seven variables: @code{opoint}, @code{fill-prefix-regexp}, > -@code{parstart}, @code{parsep}, @code{sp-parstart}, @code{start}, and > +The next line of the @code{forward-paragraph} function begins a > +@code{let*} expression (@pxref{let* introduced,,@code{let*} > +introduced}), in which Emacs binds a total of seven variables: > +@code{opoint}, @code{fill-prefix-regexp}, @code{parstart}, > +@code{parsep}, @code{sp-parstart}, @code{start}, and > @code{found-start}. This seems to move the description of let* to an earlier part of the manual. Once again, I ask: what's the rationale for the change in the order? From debbugs-submit-bounces@debbugs.gnu.org Tue Dec 14 07:52:59 2021 Received: (at 8275) by debbugs.gnu.org; 14 Dec 2021 12:52:59 +0000 Received: from localhost ([127.0.0.1]:57785 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mx7Ig-0001Yw-JN for submit@debbugs.gnu.org; Tue, 14 Dec 2021 07:52:59 -0500 Received: from out2.migadu.com ([188.165.223.204]:26543) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mx7Id-0001Yl-1Y for 8275@debbugs.gnu.org; Tue, 14 Dec 2021 07:52:57 -0500 X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ego.team; s=key1; t=1639486373; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to; bh=QygtidfIYLWdUvBgkPlBjC64rEupd7RNBiVNDX2QPzg=; b=YzKGG4fNW2gKVvXyLum8VNWn+f4JLk/HA+jE16vMKoNDhVby40G7WDBeU6d3gsj8rBGzKm LXDcsZQ1M+7JmFrMd/Rylszfm0ueXI2Kc+noLiiFXRsPDn4W5Ttsmbed+xhoxti3Jfo4Y+ hmyvN7/mT0UxSp4P8Z6n2T1Oj4g/8wg= From: Y. E. To: Eli Zaretskii Subject: Re: bug#8275: [PATCH] Re: bug#8275: 24.0.50; Intro to Emacs Lisp Issue In-Reply-To: <83czm2p7dx.fsf@gnu.org> (message from Eli Zaretskii on Sun, 12 Dec 2021 10:14:18 +0200) Date: Tue, 14 Dec 2021 14:52:51 +0200 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Migadu-Flow: FLOW_OUT X-Migadu-Auth-User: yuga@ego.team X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 8275 Cc: 8275@debbugs.gnu.org, cyd@stupidchicken.com, stefan@marxist.se, monnier@iro.umontreal.ca, yet@ego.team, jearl@notengoamigos.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: "Y. E." Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --=-=-= Content-Type: text/plain Eli Zaretskii writes: >> -Here is the complete text of the function: >> +Here is the complete text of the function in GNU Emacs 22: > > Instead of alluding to a past version of Emacs, how about saying > something more vague, like "a variant of the function", or "a possible > implementation of the function"? Done. Note that the style of the patch was based on the existing texts. Should I create a bug report (maybe with a patch) asking to replace other 'In GNU Emacs 22' phrases used in the same context? ________________ > The goal of this manual is not to > show actual code used by Emacs, it's to teach programming in Emacs > Lisp. If this is true, then the manual has to be re-written very deeply. Currently, the manual promises (and often does) to show actual code usage. Citing `(eintr) On Reading this Text': > Much of this introduction is dedicated to walkthroughs or guided > tours of code used in GNU Emacs. These tours are designed for two > purposes: first, to give you familiarity with real, working code (code > you use every day); and, second, to give you familiarity with the way > Emacs works. [I personally prefer what the manual promises (mostly does) now.] ________________ >> -returned. The second argument is the symbol for true, @code{t}. that >> +returned. The second argument is the symbol for true: @code{t}, that > > I think the correct fix here is to capitalize "That" (and add a > space), so that it's the next separate sentence. Done. ________________ >> +@anchor{let* introduced} >> +@cindex @code{let*} expression >> +@findex let* > > It isn't useful to have several index entries that begin with the same > text and point to the same place. This manual has just one index, > where all the index entries are placed together. So I suggest > removing one of these two index entries. Thanks, removed. ________________ > This seems to move the description of let* to an earlier part of the > manual. The description of 'let*' is *already* in the earlier part of the manual. (The patch is based on the current version.) > Once again, I ask: what's the rationale for the change in the > order? The following is the order of the occurrences of 'let*' in the manual: 1. 'let*' is defined in `(eintr) append-to-buffer overview', 2. Then it's mentioned in the code and text of the `(eintr) kill-append function', 3. Then it's mentioned in the intro text of `(eintr) forward-paragraph', 4. Then it's defined for the second time in `(eintr) fwd-para let', using the same words and phrases as in the 1st occurrence. Therefore, it seems to be more comprehensible for a reader to be introduced to 'let*' (in a more clear manner than it is now) on the 1st of the listed occurrences, rather than on the 4th. Anyway, if there's a strong opinion 'let*' has to be introduced in `(eintr) fwd-para let' and not earlier, then I'd suggest scratching out the mentions of 'let*' from all the earlier parts altogether (or limit them to a bare minimum and reference to the definition). I'm fine with either (or any other) as long as the text of the manual reads smoothly and doesn't contain unnecessary duplications. --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=0001-Cleanup-append-to-buffer-section-in-ELisp-Intro.patch Content-Description: Cleanup append-to-buffer section in ELisp Intro >From e1c2f3d92ae7a82ba98b7849647bb3940afa0e8c Mon Sep 17 00:00:00 2001 From: YugaEgo Date: Fri, 10 Dec 2021 23:29:51 +0200 Subject: [PATCH] Cleanup append-to-buffer section in ELisp Intro * doc/lispintro/emacs-lisp-intro.texi (append-to-buffer, Buffer Related Review, fwd-para let): Finalize shifting focus of the 'let*' introduction to the 'append-to-buffer' section. Improve wording, fix typos, remove redundant comments (Bug#8275). --- doc/lispintro/emacs-lisp-intro.texi | 147 ++++++++++------------------ 1 file changed, 49 insertions(+), 98 deletions(-) diff --git a/doc/lispintro/emacs-lisp-intro.texi b/doc/lispintro/emacs-lisp-intro.texi index 9f1f10e8d6..43f1c2ddd5 100644 --- a/doc/lispintro/emacs-lisp-intro.texi +++ b/doc/lispintro/emacs-lisp-intro.texi @@ -4896,25 +4896,6 @@ Body of mark-whole-buffer is set at the end of the buffer. The whole buffer is, therefore, the region. -@c FIXME: the definition of append-to-buffer has been changed (in -@c 2010-03-30). -@c In Bug#8275, Stefan Monner writes: -@c >> Do you want to fix this, or shall I try? The problem is that -@c >> append-to-buffer now uses let* and with-current-buffer, so this might -@c >> break the flow of the text. At this point in the book, let* and -@c >> with-current-buffer are not yet introduced. -@c > -@c > Here are some thoughts: -@c > - I don't think it's of any importance that the example code be -@c > identical to the currently used code. -@c > - append-to-buffer might not be the best example since AFAICT copying -@c > text from one buffer to another is not a common operation and in most -@c > cases this is done via buffer-substring + insert (often with some -@c > processing on the string between the two) rather than with -@c > insert-buffer-substring which is a rarely used function. -@c > - yes, I think the text would benefit from some rethink to try and present -@c > with-current-buffer in preference to set-buffer, but it's not -@c > a simple fix. @node append-to-buffer @section The Definition of @code{append-to-buffer} @findex append-to-buffer @@ -4949,8 +4930,9 @@ append-to-buffer overview to, and the region that will be copied. @need 1250 -Here is the complete text of the function: +Here is a possible implementation of the function: +@c GNU Emacs 22 @smallexample @group (defun append-to-buffer (buffer start end) @@ -5017,7 +4999,9 @@ append interactive Since the @code{append-to-buffer} function will be used interactively, the function must have an @code{interactive} expression. (For a review of @code{interactive}, see @ref{Interactive, , Making a -Function Interactive}.) The expression reads as follows: +Function Interactive}.) + +The expression reads as follows: @smallexample @group @@ -5046,7 +5030,7 @@ append interactive The first argument to @code{other-buffer}, the exception, is yet another function, @code{current-buffer}. That is not going to be -returned. The second argument is the symbol for true, @code{t}. that +returned. The second argument is the symbol for true, @code{t}. That tells @code{other-buffer} that it may show visible buffers (except in this case, it will not show the current buffer, which makes sense). @@ -5082,33 +5066,6 @@ append interactive @node append-to-buffer body @subsection The Body of @code{append-to-buffer} -@ignore -in GNU Emacs 22 in /usr/local/src/emacs/lisp/simple.el - -(defun append-to-buffer (buffer start end) - "Append to specified buffer the text of the region. -It is inserted into that buffer before its point. - -When calling from a program, give three arguments: -BUFFER (or buffer name), START and END. -START and END specify the portion of the current buffer to be copied." - (interactive - (list (read-buffer "Append to buffer: " (other-buffer (current-buffer) t)) - (region-beginning) (region-end))) - (let ((oldbuf (current-buffer))) - (save-excursion - (let* ((append-to (get-buffer-create buffer)) - (windows (get-buffer-window-list append-to t t)) - point) - (set-buffer append-to) - (setq point (point)) - (barf-if-buffer-read-only) - (insert-buffer-substring oldbuf start end) - (dolist (window windows) - (when (= (window-point window) point) - (set-window-point window (point)))))))) -@end ignore - The body of the @code{append-to-buffer} function begins with @code{let}. As we have seen before (@pxref{let, , @code{let}}), the purpose of a @@ -5127,7 +5084,7 @@ append-to-buffer body "@var{documentation}@dots{}" (interactive @dots{}) (let ((@var{variable} @var{value})) - @var{body}@dots{}) + @var{body}@dots{})) @end group @end smallexample @@ -5247,19 +5204,39 @@ append save-excursion @need 1200 @noindent +@anchor{let* introduced} +@findex let* In this function, the body of the @code{save-excursion} contains only one expression, the @code{let*} expression. You know about a -@code{let} function. The @code{let*} function is different. It has a -@samp{*} in its name. It enables Emacs to set each variable in its -varlist in sequence, one after another. +@code{let} function. The @code{let*} function is different. It +enables Emacs to set each variable in its varlist in sequence, one +after another; such that variables in the latter part of the varlist +can make use of the values to which Emacs set variables earlier in the +varlist. -Its critical feature is that variables later in the varlist can make -use of the values to which Emacs set variables earlier in the varlist. -@xref{fwd-para let, , The @code{let*} expression}. +Looking at the @code{let*} expression in @code{append-to-buffer}: -We will skip functions like @code{let*} and focus on two: the -@code{set-buffer} function and the @code{insert-buffer-substring} -function. +@smallexample +@group +(let* ((append-to (get-buffer-create buffer)) + (windows (get-buffer-window-list append-to t t)) + point) + BODY...) +@end group +@end smallexample + +@noindent +we see that @code{append-to} is bound to the value returned by the +@w{@code{(get-buffer-create buffer)}}. On the next line, +@code{append-to} is used as an argument to +@code{get-buffer-window-list}; this would not be possible with the +@code{let} expression. Note that @code{point} is automatically bound +to @code{nil}, the same way as it would be done in the @code{let} +statement. + +Now let's focus on the functions @code{set-buffer} and +@code{insert-buffer-substring} in the body of the @code{let*} +expression. @need 1250 In the old days, the @code{set-buffer} expression was simply @@ -5277,27 +5254,8 @@ append save-excursion @end smallexample @noindent -@code{append-to} is bound to @code{(get-buffer-create buffer)} earlier -on in the @code{let*} expression. That extra binding would not be -necessary except for that @code{append-to} is used later in the -varlist as an argument to @code{get-buffer-window-list}. - -@ignore -in GNU Emacs 22 - - (let ((oldbuf (current-buffer))) - (save-excursion - (let* ((append-to (get-buffer-create buffer)) - (windows (get-buffer-window-list append-to t t)) - point) - (set-buffer append-to) - (setq point (point)) - (barf-if-buffer-read-only) - (insert-buffer-substring oldbuf start end) - (dolist (window windows) - (when (= (window-point window) point) - (set-window-point window (point)))))))) -@end ignore +This is because @code{append-to} was bound to @code{(get-buffer-create +buffer)} earlier on in the @code{let*} expression. The @code{append-to-buffer} function definition inserts text from the buffer in which you are currently to a named buffer. It happens that @@ -5394,6 +5352,12 @@ Buffer Related Review @item mark-whole-buffer Mark the whole buffer as a region. Normally bound to @kbd{C-x h}. +@item let* +Declare a list of variables and give them an initial value; then +evaluate the rest of the expressions in the body of @code{let*}. The +values of the variables can be used to bind ensuing variables in the +list. + @item set-buffer Switch the attention of Emacs to another buffer, but do not change the window being displayed. Used when the program rather than a human is @@ -12896,25 +12860,12 @@ forward-paragraph in brief @node fwd-para let @unnumberedsubsec The @code{let*} expression -The next line of the @code{forward-paragraph} function begins a -@code{let*} expression. This is different from @code{let}. The -symbol is @code{let*} not @code{let}. - @findex let* -The @code{let*} special form is like @code{let} except that Emacs sets -each variable in sequence, one after another, and variables in the -latter part of the varlist can make use of the values to which Emacs -set variables in the earlier part of the varlist. - -@ignore -( refappend save-excursion, , code save-excursion in code append-to-buffer .) -@end ignore - -(@ref{append save-excursion, , @code{save-excursion} in @code{append-to-buffer}}.) - -In the @code{let*} expression in this function, Emacs binds a total of -seven variables: @code{opoint}, @code{fill-prefix-regexp}, -@code{parstart}, @code{parsep}, @code{sp-parstart}, @code{start}, and +The next line of the @code{forward-paragraph} function begins a +@code{let*} expression (@pxref{let* introduced,,@code{let*} +introduced}), in which Emacs binds a total of seven variables: +@code{opoint}, @code{fill-prefix-regexp}, @code{parstart}, +@code{parsep}, @code{sp-parstart}, @code{start}, and @code{found-start}. The variable @code{parsep} appears twice, first, to remove instances -- 2.34.1 --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Wed Dec 15 23:38:50 2021 Received: (at 8275) by debbugs.gnu.org; 16 Dec 2021 04:38:51 +0000 Received: from localhost ([127.0.0.1]:34208 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mxiXa-00037a-CV for submit@debbugs.gnu.org; Wed, 15 Dec 2021 23:38:50 -0500 Received: from eggs.gnu.org ([209.51.188.92]:45892) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mxiXY-00037M-Hd for 8275@debbugs.gnu.org; Wed, 15 Dec 2021 23:38:49 -0500 Received: from [2001:470:142:3::e] (port=48170 helo=fencepost.gnu.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mxiXS-00051g-I1; Wed, 15 Dec 2021 23:38:42 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=Date:References:Subject:In-Reply-To:To:From: mime-version; bh=ZQz1101HONwSWpxyRNIl9iAqGQ/Z8FcDrm4+kn+F8+A=; b=RnEqKsYZZIsL 7QKkikhPc4yjk3QFVmMpxa6kIctBRt8WLvXnciJoxTA4Se+8kKSiI6hSqUcFgcPFApL2GXGY918mp 7BjGikDVJ6e4SZEpoNoGHrmB/rkXPN+P/NQByYDDmLTi5AaDbq3yH1QTPt/BGgrSMWstpWdBnNcAW we153KWR/NatfOd1iG6r481cwq88mScH1qvPzxMtLVJXIJssx7GqYPZUv2mo4G77OhJ+pvZeA42pw gW9EzkYZfXXHUfRrxdGDd535mW2jrW4DColEolUS8oHBYWfgjCfMZjRIzklDuaNledYByTk6G1Fa2 bl/yrQvvHge5ohLtgrW/jQ==; Received: from rms by fencepost.gnu.org with local (Exim 4.90_1) (envelope-from ) id 1mxiXS-0002Px-LM; Wed, 15 Dec 2021 23:38:42 -0500 Content-Type: text/plain; charset=Utf-8 From: Richard Stallman To: "Y. E." In-Reply-To: (bug-gnu-emacs@gnu.org) Subject: Re: bug#8275: [PATCH] Re: bug#8275: 24.0.50; Intro to Emacs Lisp Issue References: <871v25d4zl.fsf@notengoamigos.org> Message-Id: Date: Wed, 15 Dec 2021 23:38:42 -0500 X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 8275 Cc: 8275@debbugs.gnu.org, cyd@stupidchicken.com, stefan@marxist.se, jearl@notengoamigos.org, monnier@iro.umontreal.ca, eliz@gnu.org, yet@ego.team X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: rms@gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) [[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > > The goal of this manual is not to > > show actual code used by Emacs, it's to teach programming in Emacs > > Lisp. That is basically true, but perhaps a little too strongly put. Teaching programming in Emacs Lisp is the primary goal. > Currently, the manual promises (and often does) to show actual code > usage. Citing `(eintr) On Reading this Text': That is also true. That is another nice thing that the manual does "along the way." It is fine to say "this is the code of function foo in Emacs 22", in case years later someone reads that text when Emacs 32 is current, so perse will understand why this example does not show the current Emacs code. Would it be better to update the manual to use the Emacs 32 code as an example? Maybe. The advantage is, that it will show the code of the current Emacs. The disadvantages are, (1) updating the explanation is work, and needs a good writer, (2) the newer code may be longer and more complex, so that it will be more work to understand, and thus not as good for the manual's primary goal, (3) the newer code might be changed so much that it is no longer an example of the feature to be illustrated. When that last happens, it is possible to find and use a different piece of code in Emacs. But that's even more work. Maybe the best choice is to keep the Emacs 22 code as the example. This partly depends on whether a good writer is available. We don't have anyone now who writes as well as Bob Chassell. If you want to aim to develop your skills, by all means do -- but that calls for getting lots of careful feedback from thoughtful readers willing to spend time critiquing your writing. Almost nobody gets to be that good without doihg lots of writing and getting lots if critiques. On manuals I've written, I have generally got dozens of people to read them carefully to report small points that were not entirely clear. Sometimes I would ask what makes a certain piece of text unclear, and discuss possible improvements. >From each critique I addressed, I learned. If you take this path, you'll keep getting gradually better at writing. But the path is long. -- Dr Richard Stallman (https://stallman.org) Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) From debbugs-submit-bounces@debbugs.gnu.org Sat Dec 18 09:28:05 2021 Received: (at 8275-done) by debbugs.gnu.org; 18 Dec 2021 14:28:05 +0000 Received: from localhost ([127.0.0.1]:41544 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1myagq-0000cM-B9 for submit@debbugs.gnu.org; Sat, 18 Dec 2021 09:28:05 -0500 Received: from eggs.gnu.org ([209.51.188.92]:37616) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1myagn-0000c9-Rp for 8275-done@debbugs.gnu.org; Sat, 18 Dec 2021 09:27:58 -0500 Received: from [2001:470:142:3::e] (port=52654 helo=fencepost.gnu.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1myagh-0002Ng-Qk; Sat, 18 Dec 2021 09:27:51 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=IDHNpBu/FjqaLpeYahpqzdAaNxhK6jMEhrKAvjkLy74=; b=PUpfB1VTxrWj LmVJMkdEzg/wAS0ELigsb9cUkQT76TR5kkWLxOYWonFCArkCm3EgcwXO1U8qjNLEujxnQQymimqqY p8CtMuGQxziqS/HhxbePv/Cs4ibusMO9iO2KRIEHrZsIhMGiBmrpz4QiuL5X8yVqNX3f6uE4DEgpH ywM9+v7745KSPBOLiz4VUWooZCh5vp5U3S+3xDNXHZQenjii/TFZVGu9v4lw1O2Xe4Qgth4WuU0Vb TUi96q9QfmZihNwkUOyPwDrJjDCeUDHfN7oC1BY5G9/rsuLLHQ5veXoCV2Npz9RlpW0HjtSeoO20b V/e429wDUIJs6Sl5uzQzAA==; Received: from [87.69.77.57] (port=4938 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1myagh-0006r7-Io; Sat, 18 Dec 2021 09:27:51 -0500 Date: Sat, 18 Dec 2021 16:27:40 +0200 Message-Id: <83zgoy9eeb.fsf@gnu.org> From: Eli Zaretskii To: Y. E. In-Reply-To: (message from Y. E. on Tue, 14 Dec 2021 14:52:51 +0200) Subject: Re: bug#8275: [PATCH] Re: bug#8275: 24.0.50; Intro to Emacs Lisp Issue References: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 8275-done Cc: 8275-done@debbugs.gnu.org, cyd@stupidchicken.com, stefan@marxist.se, monnier@iro.umontreal.ca, jearl@notengoamigos.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > From: Y. E. > Cc: yet@ego.team, stefan@marxist.se, 8275@debbugs.gnu.org, > cyd@stupidchicken.com, > monnier@iro.umontreal.ca, jearl@notengoamigos.org > Date: Tue, 14 Dec 2021 14:52:51 +0200 > > Eli Zaretskii writes: > >> -Here is the complete text of the function: > >> +Here is the complete text of the function in GNU Emacs 22: > > > > Instead of alluding to a past version of Emacs, how about saying > > something more vague, like "a variant of the function", or "a possible > > implementation of the function"? > > Done. > > Note that the style of the patch was based on the existing texts. Should > I create a bug report (maybe with a patch) asking to replace other 'In > GNU Emacs 22' phrases used in the same context? > > ________________ > > > The goal of this manual is not to > > show actual code used by Emacs, it's to teach programming in Emacs > > Lisp. > If this is true, then the manual has to be re-written very deeply. > Currently, the manual promises (and often does) to show actual code > usage. Citing `(eintr) On Reading this Text': > > > Much of this introduction is dedicated to walkthroughs or guided > > tours of code used in GNU Emacs. These tours are designed for two > > purposes: first, to give you familiarity with real, working code (code > > you use every day); and, second, to give you familiarity with the way > > Emacs works. > > [I personally prefer what the manual promises (mostly does) now.] > > ________________ > > >> -returned. The second argument is the symbol for true, @code{t}. that > >> +returned. The second argument is the symbol for true: @code{t}, that > > > > I think the correct fix here is to capitalize "That" (and add a > > space), so that it's the next separate sentence. > > Done. > > ________________ > > > >> +@anchor{let* introduced} > >> +@cindex @code{let*} expression > >> +@findex let* > > > > It isn't useful to have several index entries that begin with the same > > text and point to the same place. This manual has just one index, > > where all the index entries are placed together. So I suggest > > removing one of these two index entries. > > Thanks, removed. > > ________________ > > > This seems to move the description of let* to an earlier part of the > > manual. > The description of 'let*' is *already* in the earlier part of the > manual. (The patch is based on the current version.) > > > Once again, I ask: what's the rationale for the change in the > > order? > > The following is the order of the occurrences of 'let*' in the manual: > > 1. 'let*' is defined in `(eintr) append-to-buffer overview', > > 2. Then it's mentioned in the code and text of the `(eintr) kill-append > function', > > 3. Then it's mentioned in the intro text of `(eintr) forward-paragraph', > > 4. Then it's defined for the second time in `(eintr) fwd-para let', > using the same words and phrases as in the 1st occurrence. > > Therefore, it seems to be more comprehensible for a reader to be > introduced to 'let*' (in a more clear manner than it is now) on the 1st > of the listed occurrences, rather than on the 4th. > > > Anyway, if there's a strong opinion 'let*' has to be introduced in > `(eintr) fwd-para let' and not earlier, then I'd suggest scratching out > the mentions of 'let*' from all the earlier parts altogether (or limit > them to a bare minimum and reference to the definition). > > I'm fine with either (or any other) as long as the text of the manual > reads smoothly and doesn't contain unnecessary duplications. Thanks, I installed this on the master branch, and I'm closing this bug. From unknown Fri Sep 05 08:41:37 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Sun, 16 Jan 2022 12:24:08 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator