From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: [RFC]: replace-region-contents Date: Sun, 03 Feb 2019 12:05:57 -0500 Message-ID: References: <871s4rqk7u.fsf@gnu.org> <835zu0x3pu.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="91645"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: emacs-devel@gnu.org, tsdh@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Feb 03 18:07:09 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gqLEb-000NjS-1N for ged-emacs-devel@m.gmane.org; Sun, 03 Feb 2019 18:07:09 +0100 Original-Received: from localhost ([127.0.0.1]:58332 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gqLEZ-0002Fi-BV for ged-emacs-devel@m.gmane.org; Sun, 03 Feb 2019 12:07:07 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:40973) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gqLDW-0002Co-HK for emacs-devel@gnu.org; Sun, 03 Feb 2019 12:06:03 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gqLDV-0007kT-PI for emacs-devel@gnu.org; Sun, 03 Feb 2019 12:06:02 -0500 Original-Received: from pruche.dit.umontreal.ca ([132.204.246.22]:34328) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gqLDU-0007fg-A8; Sun, 03 Feb 2019 12:06:00 -0500 Original-Received: from pastel.home (lechon.iro.umontreal.ca [132.204.27.242]) by pruche.dit.umontreal.ca (8.14.7/8.14.1) with ESMTP id x13H5vEq015286; Sun, 3 Feb 2019 12:05:58 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id C48616ABCC; Sun, 3 Feb 2019 12:05:57 -0500 (EST) In-Reply-To: <835zu0x3pu.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 03 Feb 2019 17:59:41 +0200") X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 2 Rules triggered EDT_SA_DN_PASS=0, RV6474=0 X-NAI-Spam-Version: 2.3.0.9418 : core <6474> : inlines <7010> : streams <1811981> : uri <2790206> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 132.204.246.22 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:232935 Archived-At: >> PS: I wish replace-buffer-contents interpreted a string as the text to >> use as replacement rather than as a buffer name > You'd need to insert the string into a buffer anyway, before you could > run the code, so might as well do that in Lisp. I was only talking about the API, not the implementation. If I had to implement the feature, I'd likely rename replace-buffer-contents to internal--replace-buffer-contents and do the string->buffer conversion in an Elisp wrapper, simply as a convenience to the user. `replace-buffer-contents` is basically a fancy replacement for delete-region + insert and `insert` accepts a string as argument, so it's very natural to also accept a string as argument. > (I find text processing based on strings a bad idea in Emacs, btw. Agreed. In the case of replace-buffer-contents, I think we could have an equally efficient code that accepts a string instead of a buffer. But it'd definitely be inconvenient to write code that works both ways. > Buffers are much more convenient and efficient.) I find strings standing for buffers to be ugly and a source of bugs (because buffer names can change), so even if we don't accept strings as I suggested above, I'd prefer that we signal an error when we receive a string rather than silently looking for a buffer that has the same name. Stefan