From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Stephen Leake Newsgroups: gmane.emacs.devel Subject: flet vs cl-flet vs compilation-start Date: Wed, 01 Feb 2017 17:33:28 -0600 Message-ID: <86mve51o6v.fsf@stephe-leake.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1485992058 31801 195.159.176.226 (1 Feb 2017 23:34:18 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 1 Feb 2017 23:34:18 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.91 (windows-nt) To: emacs-devel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Feb 02 00:34:13 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cZ4Pj-0007zg-Gb for ged-emacs-devel@m.gmane.org; Thu, 02 Feb 2017 00:34:11 +0100 Original-Received: from localhost ([::1]:53504 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cZ4Pp-00076P-0Y for ged-emacs-devel@m.gmane.org; Wed, 01 Feb 2017 18:34:17 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44826) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cZ4PB-00076H-Kj for emacs-devel@gnu.org; Wed, 01 Feb 2017 18:33:38 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cZ4P7-00045r-NF for emacs-devel@gnu.org; Wed, 01 Feb 2017 18:33:37 -0500 Original-Received: from smtp137.dfw.emailsrvr.com ([67.192.241.137]:37565) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1cZ4P7-00045O-JA for emacs-devel@gnu.org; Wed, 01 Feb 2017 18:33:33 -0500 Original-Received: from smtp18.relay.dfw1a.emailsrvr.com (localhost [127.0.0.1]) by smtp18.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id 6F90EC00DA for ; Wed, 1 Feb 2017 18:33:31 -0500 (EST) X-Auth-ID: board-president@tomahawk-creek-hoa.com Original-Received: by smtp18.relay.dfw1a.emailsrvr.com (Authenticated sender: board-president-AT-tomahawk-creek-hoa.com) with ESMTPSA id 4AD84C00AB for ; Wed, 1 Feb 2017 18:33:31 -0500 (EST) X-Sender-Id: board-president@tomahawk-creek-hoa.com Original-Received: from Takver4 (76-218-37-33.lightspeed.kscymo.sbcglobal.net [76.218.37.33]) (using TLSv1.2 with cipher AES128-GCM-SHA256) by 0.0.0.0:587 (trex/5.7.12); Wed, 01 Feb 2017 18:33:31 -0500 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-Received-From: 67.192.241.137 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:211853 Archived-At: I'm using compilation-mode to show results from running an external program; it produces output that looks like compilation errors (it's actually cross-reference info). Some users would like to preserve output from several calls to the external program. compilation-start does not provide an option for this; it calls (erase-buffer) unconditionally. So someone suggested this hack: (require 'cl) (flet ((erase-buffer nil (goto-char (point-max)))) (compilation-start ... )) That works, but produces byte-compiler warnings about cl and flet. So I tried: (require 'cl-lib) (cl-flet ((erase-buffer nil (goto-char (point-max)))) (compilation-start ... )) This does _not_ work. Apparently in the "flet" case, the local definition of 'erase-buffer' overrides the global one, but in the 'cl-flet' case it does not. I'm running emacs-25 compiled from the branch with mingw64. This is consistent with the doc strings: cl-flet says: Make local function definitions. flet says: Make temporary overriding function definitions. and goes on to say "use cl-flet". Perhaps the doc string of flet should be improved to point out that cl-flet does not produce _overriding_ function definitions, and suggest workarounds. I could try applying and removing advice on erase-buffer, but a simpler workaround is to copy the buffer content into a local string var, then paste it back. Is there any support for introducing a parameter to compilation-start that says "don't erase the buffer"? -- -- Stephe