From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier 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 22:41:22 -0400 Message-ID: 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 1394419337 17065 80.91.229.3 (10 Mar 2014 02:42:17 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 10 Mar 2014 02:42:17 +0000 (UTC) Cc: 16904@debbugs.gnu.org To: Dima Kogan Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Mar 10 03:42:25 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 1WMqAa-0002Rg-RF for geb-bug-gnu-emacs@m.gmane.org; Mon, 10 Mar 2014 03:42:25 +0100 Original-Received: from localhost ([::1]:46445 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WMqAa-0005OY-Gi for geb-bug-gnu-emacs@m.gmane.org; Sun, 09 Mar 2014 22:42:24 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58743) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WMqAP-0005OL-TL for bug-gnu-emacs@gnu.org; Sun, 09 Mar 2014 22:42:21 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WMqAE-00014j-5W for bug-gnu-emacs@gnu.org; Sun, 09 Mar 2014 22:42:13 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:57370) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WMqAE-00014c-1u for bug-gnu-emacs@gnu.org; Sun, 09 Mar 2014 22:42:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1WMqAD-0000dW-SF for bug-gnu-emacs@gnu.org; Sun, 09 Mar 2014 22:42:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 10 Mar 2014 02:42:01 +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.13944192872392 (code B ref 16904); Mon, 10 Mar 2014 02:42:01 +0000 Original-Received: (at 16904) by debbugs.gnu.org; 10 Mar 2014 02:41:27 +0000 Original-Received: from localhost ([127.0.0.1]:58552 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WMq9e-0000cV-JO for submit@debbugs.gnu.org; Sun, 09 Mar 2014 22:41:27 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:25818) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WMq9b-0000cN-J6 for 16904@debbugs.gnu.org; Sun, 09 Mar 2014 22:41:23 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EABK/CFFMCppy/2dsb2JhbABEvw4Xc4IeAQEEAVYjBQsLNBIUGA0kiB4GwS2RCgOkeoFegxM X-IPAS-Result: Av4EABK/CFFMCppy/2dsb2JhbABEvw4Xc4IeAQEEAVYjBQsLNBIUGA0kiB4GwS2RCgOkeoFegxM X-IronPort-AV: E=Sophos;i="4.84,565,1355115600"; d="scan'208";a="50957747" Original-Received: from 76-10-154-114.dsl.teksavvy.com (HELO ceviche.home) ([76.10.154.114]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 09 Mar 2014 22:41:23 -0400 Original-Received: by ceviche.home (Postfix, from userid 20848) id D6EC1660A5; Sun, 9 Mar 2014 22:41:22 -0400 (EDT) In-Reply-To: <87eh2d4eeq.fsf@secretsauce.net> (Dima Kogan's message of "Fri, 07 Mar 2014 18:23:09 -0800") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) 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:86700 Archived-At: [ Replying to the bug only is fine, thanks. CC-ing me is fine as well. Even sending me an extra copy like you did is fine. I'm easy to please. ] > I wasn't aware that use of indirect buffers is frowned-upon. It's not exactly frowned-upon, but it suffers from many problems/bugs some of which are basically impossible to fix. Part of the problem is that this is a rarely used feature, so it's not well tested, and the other part is that it works at a very low level and hence often lacks higher-level info about is intended. > I usually use it to simultaneously look at different places in the same > file. Most of the time this is some long source code thing. It's nice to > have separate kill rings, mark rings, narrowing, etc. 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. Not sure what you mean by separate kill rings, since kill-ring is a global variable. 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'? > 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. 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. Stefan