From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dima Kogan Newsgroups: gmane.emacs.bugs Subject: bug#16904: 24.3; [PATCH] ff-find-other-file and friends now work with indirect clone buffers Date: Sun, 09 Mar 2014 20:30:58 -0700 Message-ID: <87eh2a3f2l.fsf@secretsauce.net> References: <87txbj5vwi.fsf@secretsauce.net> <87eh2d4eeq.fsf@secretsauce.net> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1394422329 16190 80.91.229.3 (10 Mar 2014 03:32:09 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 10 Mar 2014 03:32:09 +0000 (UTC) To: 16904@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Mar 10 04:32:17 2014 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1WMqwq-0006Eu-WC for geb-bug-gnu-emacs@m.gmane.org; Mon, 10 Mar 2014 04:32:17 +0100 Original-Received: from localhost ([::1]:46547 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WMqwp-0006UR-Vy for geb-bug-gnu-emacs@m.gmane.org; Sun, 09 Mar 2014 23:32:15 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36083) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WMqwi-0006UJ-IP for bug-gnu-emacs@gnu.org; Sun, 09 Mar 2014 23:32:13 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WMqwd-0005Ya-Es for bug-gnu-emacs@gnu.org; Sun, 09 Mar 2014 23:32:08 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:57395) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WMqwc-0005YV-RU for bug-gnu-emacs@gnu.org; Sun, 09 Mar 2014 23:32:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1WMqwc-00026c-63 for bug-gnu-emacs@gnu.org; Sun, 09 Mar 2014 23:32:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Dima Kogan Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 10 Mar 2014 03:32:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 16904 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 16904-submit@debbugs.gnu.org id=B16904.13944222648005 (code B ref 16904); Mon, 10 Mar 2014 03:32:02 +0000 Original-Received: (at 16904) by debbugs.gnu.org; 10 Mar 2014 03:31:04 +0000 Original-Received: from localhost ([127.0.0.1]:58577 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WMqvf-000252-MB for submit@debbugs.gnu.org; Sun, 09 Mar 2014 23:31:04 -0400 Original-Received: from out3-smtp.messagingengine.com ([66.111.4.27]:45893) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WMqvc-00024a-LH for 16904@debbugs.gnu.org; Sun, 09 Mar 2014 23:31:01 -0400 Original-Received: from compute6.internal (compute6.nyi.mail.srv.osa [10.202.2.46]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 2113A20A04 for <16904@debbugs.gnu.org>; Sun, 9 Mar 2014 23:31:00 -0400 (EDT) Original-Received: from frontend2 ([10.202.2.161]) by compute6.internal (MEProxy); Sun, 09 Mar 2014 23:31:00 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=secretsauce.net; h=references:from:to:subject:in-reply-to:date:message-id :mime-version:content-type; s=mesmtp; bh=N3HVPSW6lSHS9ws10VV0H7U ZZkc=; b=lDStb3RzTbOz+48aC6iEPHAsJM3V5SW0hfQmkKaZqOnjoKENusSoNJf ZWNC7JNz1VgeQBR8c4aFLafzE2zOO3XncyX8dYI86v6PbAv5kFZLEaXzH9uyIt0u pAyYfK6Qe4pIWoSi+XmaIsQBNtIpCR6VYZ+Q2ENCV4W57eqIXcag= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=references:from:to:subject:in-reply-to :date:message-id:mime-version:content-type; s=smtpout; bh=N3HVPS W6lSHS9ws10VV0H7UZZkc=; b=MDObKf/Q3/hEiC4hR4TetvSw/YNU7HtoROtFeW k1olc7dChN9++PMkwz/BWrnDqlqobupugsMpj39Rau9IFCX/GRncpK6tkJx1kBv/ Rebn6bGxMjC53o7G4AivAo+6Cpr2kxGTFA9Eob8LlAwnxYt1KS2aq353UrXTDr43 71Vfg= X-Sasl-enc: x1qmUjiCXYT7Te5y0OvtisgprNc9Kzd3ZZlSpWM+z3Aj 1394422259 Original-Received: from shorty.local (unknown [23.243.199.75]) by mail.messagingengine.com (Postfix) with ESMTPA id D47696800E7 for <16904@debbugs.gnu.org>; Sun, 9 Mar 2014 23:30:59 -0400 (EDT) Original-Received: from dima by shorty.local with local (Exim 4.80) (envelope-from ) id 1WMqva-0000h3-8s for 16904@debbugs.gnu.org; Sun, 09 Mar 2014 20:30:58 -0700 User-agent: mu4e 0.9.9.6pre2; emacs 24.3.1 In-reply-to: X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:86705 Archived-At: Stefan Monnier writes: > Multiple narrowing within the same buffer is indeed not supported, but > we could easily add commands to "hide everything but the current region" > which are per-window, where "hide" means "make invisible" rather than > making it completely inaccessible as narrowing does. Is the intent for this to replace narrowing? I think it would be confusing to have two very similar but subtly different mechanisms for doing the same thing. > Not sure what you mean by separate kill rings, since kill-ring is > a global variable. Yes, you're right. Never mind on that one. > As for separate mark-rings, I'm not sure what alternative I can offer. > Maybe we could have some kind of new command `pop-to-nearest-mark'? Maybe. That's brittle, though. The nearest mark COULD be in the other window's section of the buffer, depending on exactly how the split is set up. Here's another way in which an indirect view into a buffer is better than another window: iswitchb (and maybe other C-x b methods too) sorts already-visible windows last. This usually results in way more typing when trying to switch in this way. Here's a concrete example: 1. say you're looking at a buffer 'file' in a window that's taking up the whole frame 2. C-x 3. Now you have two windows. Both show 'file'. 3. C-x b [enter]. We just switched to some other buffer (doesn't matter which) in one of the windows. I'm assuming iswitchb here 4. C-x b [enter]. Same keys as before, entered again. Normally this would switch back to the previously-active buffer, but since this buffer is already visible, it'll default to some other buffer. You'll have to type enough of the buffer name to uniquely identify it, before iswitchb will recognize it. >> The only issues I've encountered have to do with various functions not >> recognizing that those buffers have a backing file. Those are >> ff-find-other-file, vc-diff, etc. I suspect that making >> (buffer-file-name) work for indirect buffers would resolve a lot of >> these, but I don't know enough about the internals to propose that. > > Changing only the buffer-file-name function is too risky: it would make > it behave subtly differently from the buffer-file-name variable, and > since this subtlety only appears with indirect-buffers (remember: > rarely tested), it's a recipe for bugs. Hmmm. You could set the buffer-file-name variable when the indirect buffer is created. I guess I just don't know about (and haven't seen any) fundamental breakage in indirect buffers, so my current instinct is to try to fix it, rather than switch to something else entirely. Most of the issues I've seen are small things, like modules that use (buffer-file-name). > Changing ff-find-other-file and friends to handle this problem is much > safer. The problem with it is that I don't really want to go down that > slope, because there are many other such "minor bugs", depending on your > particular use case, so fixing them leads to adding a lot of support > code spread all over the place, and all this for a half-broken, rarely > used feature. Completely agree. I just don't know enough about the core to be able to submit useful patches there, so this patch did the easy thing. What issues are there with indirect buffers? The default C-x 4 c binding makes an indirect clone, so it's not THAT obscure. dima