From debbugs-submit-bounces@debbugs.gnu.org Mon Aug 30 14:07:11 2010 Received: (at submit) by debbugs.gnu.org; 30 Aug 2010 18:07:11 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Oq8lD-0006YY-J2 for submit@debbugs.gnu.org; Mon, 30 Aug 2010 14:07:11 -0400 Received: from mx10.gnu.org ([199.232.76.166]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Oq8lB-0006YR-VN for submit@debbugs.gnu.org; Mon, 30 Aug 2010 14:07:10 -0400 Received: from lists.gnu.org ([199.232.76.165]:42015) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Oq8mj-0005xt-PV for submit@debbugs.gnu.org; Mon, 30 Aug 2010 14:08:45 -0400 Received: from [140.186.70.92] (port=40925 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Oq8mi-00066A-D0 for bug-gnu-emacs@gnu.org; Mon, 30 Aug 2010 14:08:45 -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,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,T_DKIM_INVALID autolearn=unavailable version=3.3.1 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Oq8mh-00051i-4z for bug-gnu-emacs@gnu.org; Mon, 30 Aug 2010 14:08:44 -0400 Received: from mail-qw0-f41.google.com ([209.85.216.41]:61317) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Oq8mh-00051Y-2v for bug-gnu-emacs@gnu.org; Mon, 30 Aug 2010 14:08:43 -0400 Received: by qwf7 with SMTP id 7so6748258qwf.0 for ; Mon, 30 Aug 2010 11:08:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:from:date :message-id:subject:to:content-type; bh=7ZniEBBSa0ZyFtNTVf+uqejIcG+8N19JKykH412jWtU=; b=XpN8/85FRwQCJDMOgOKVc1JbUcRCwc9V99MSaN4XuKfm5Ta5lzZpSMFANio0fgDeuD uQD5E1QrZzlzFLolr4lxJQN0atxaZsOv0mIuLJNaZxaDfyCxxnw9ZU0xReYUVGFr8ony /UkO6IeNd8uZQ9SNMCBivZs9NMZ3zK86CTQ5M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; b=kR3UlUXbxUb3Gxnrjr56syCDBXpeP9yotB6+CIwoPAsXFTtiOA9/2O7hBa7gGMVr8n pxgXFSVWedddgIm6/Cyq1LgV7p3HKaFgNbq3ycM29l/1F605ew3EZmJXBMh9NgQvzYQk Ysa2EkRhX6G3IsZct9VSRqulkIw+GXuk0l3Hg= Received: by 10.224.66.216 with SMTP id o24mr3113831qai.296.1283191722570; Mon, 30 Aug 2010 11:08:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.20.139 with HTTP; Mon, 30 Aug 2010 11:08:22 -0700 (PDT) From: Lennart Borgman Date: Mon, 30 Aug 2010 20:08:22 +0200 Message-ID: Subject: Invisible parts and editing - reveal them? To: Emacs Bugs Content-Type: text/plain; charset=UTF-8 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) X-Spam-Score: -4.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: -4.6 (----) In reveal-mode hidden parts gets shown when you found a hit there with isearch. That is very useful. However when you edit such parts they normally do not get visible even if reveal-mode is on. This is a problem for example if you are using viper and do "o" to open a new line below the current line when the lines below are hidden. (I am sure there are other examples with default Emacs commands. Please give examples.) This hits quite often in org-mode. Could we please add some mechanism to show the point when this happen? From debbugs-submit-bounces@debbugs.gnu.org Tue Aug 31 06:12:20 2010 Received: (at 6950) by debbugs.gnu.org; 31 Aug 2010 10:12:20 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OqNpE-0005Wo-0x for submit@debbugs.gnu.org; Tue, 31 Aug 2010 06:12:20 -0400 Received: from pruche.dit.umontreal.ca ([132.204.246.22]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OqNpC-0005Wh-Mz for 6950@debbugs.gnu.org; Tue, 31 Aug 2010 06:12:19 -0400 Received: from ceviche.home (vpn-132-204-232-70.acd.umontreal.ca [132.204.232.70]) by pruche.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id o7VADrGV002203; Tue, 31 Aug 2010 06:13:54 -0400 Received: by ceviche.home (Postfix, from userid 20848) id 65B5A66121; Tue, 31 Aug 2010 12:13:52 +0200 (CEST) From: Stefan Monnier To: Lennart Borgman Subject: Re: bug#6950: Invisible parts and editing - reveal them? In-Reply-To: (Lennart Borgman's message of "Mon, 30 Aug 2010 20:08:22 +0200") Date: Tue, 31 Aug 2010 10:07:43 +0200 Message-ID: References: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV3611=0 X-Spam-Score: -2.0 (--) X-Debbugs-Envelope-To: 6950 Cc: 6950@debbugs.gnu.org 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 (--) > However when you edit such parts they normally do not get visible even > if reveal-mode is on. reveal-mode should unhide the text, assuming that point is within it. > This is a problem for example if you are using viper and do "o" to > open a new line below the current line when the lines below > are hidden. Can you provide a recipe to reproduce the problem? > Could we please add some mechanism to show the point when this happen? That's what reveal-mode does, normally. Stefan From debbugs-submit-bounces@debbugs.gnu.org Wed Sep 01 07:27:33 2010 Received: (at 6950) by debbugs.gnu.org; 1 Sep 2010 11:27:34 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OqlTZ-0000Vv-Kq for submit@debbugs.gnu.org; Wed, 01 Sep 2010 07:27:33 -0400 Received: from mail-qy0-f179.google.com ([209.85.216.179]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OqlTX-0000Vq-7w for 6950@debbugs.gnu.org; Wed, 01 Sep 2010 07:27:31 -0400 Received: by qyk9 with SMTP id 9so7718601qyk.3 for <6950@debbugs.gnu.org>; Wed, 01 Sep 2010 04:29:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type; bh=KUdC+PJ0/D5eFnkxGsHPC0bpLssCu8SK9KOlL8z4Diw=; b=gmwr2CZkaaYD2eCf78qMJ3UJu7v6+IHgDErp92vi4mbCcKjmVxl3WOUIaZASnNv8O1 CX/5nisHsjKfJ6kC9W3QqlaR//Mnrmh286tAqP2ykN59S95w6+Yh9cQ00S//z4+9/3JC hbhmIE+sJilBASLihbXw6H08EN6bpPORLkgTg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=mja8/4KpqjuxZtYNOfG+V++YMZqqzDnsMGyYYJ+PXnfw1QS5eYd++hkEf1/6AbtKKx DY/kl2LrHg0M6u5aYuyU3QCUc3eGkNx+2ZyaOmJVS0tGg1vlfxMabgg/GgVLAwu9RpLG rN+Rl9zYLn4l4ttEN9b5/2ga2xuVgRuiqFOJs= Received: by 10.224.69.17 with SMTP id x17mr4983616qai.283.1283340551304; Wed, 01 Sep 2010 04:29:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.20.139 with HTTP; Wed, 1 Sep 2010 04:28:51 -0700 (PDT) In-Reply-To: References: From: Lennart Borgman Date: Wed, 1 Sep 2010 13:28:51 +0200 Message-ID: Subject: Re: bug#6950: Invisible parts and editing - reveal them? To: Stefan Monnier Content-Type: text/plain; charset=UTF-8 X-Spam-Score: -2.9 (--) X-Debbugs-Envelope-To: 6950 Cc: 6950@debbugs.gnu.org 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.9 (--) On Tue, Aug 31, 2010 at 10:07 AM, Stefan Monnier wrote: >> However when you edit such parts they normally do not get visible even >> if reveal-mode is on. > > reveal-mode should unhide the text, assuming that point is within it. Eh, sorry, you are right. reveal-mode takes care of this. I thought I had it on, but for some reason I had commented it out. I think I got confused by the similar mechanism in isearch that is on by default. That it is on by default seems good. What is the reason reveal-mode is not on by default? (I have a feeling there was some small problem, but I can't remember now.) From debbugs-submit-bounces@debbugs.gnu.org Thu Sep 02 11:48:16 2010 Received: (at 6950-done) by debbugs.gnu.org; 2 Sep 2010 15:48:16 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OrC1P-000542-DY for submit@debbugs.gnu.org; Thu, 02 Sep 2010 11:48:16 -0400 Received: from pruche.dit.umontreal.ca ([132.204.246.22]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Or7VT-0001rn-9q for 6950-done@debbugs.gnu.org; Thu, 02 Sep 2010 06:58:59 -0400 Received: from ceviche.home (vpn-132-204-232-35.acd.umontreal.ca [132.204.232.35]) by pruche.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id o82B0dN3029362; Thu, 2 Sep 2010 07:00:39 -0400 Received: by ceviche.home (Postfix, from userid 20848) id 5C4B5660DF; Thu, 2 Sep 2010 13:00:37 +0200 (CEST) From: Stefan Monnier To: Lennart Borgman Subject: Re: bug#6950: Invisible parts and editing - reveal them? Message-ID: References: Date: Thu, 02 Sep 2010 13:00:37 +0200 In-Reply-To: (Lennart Borgman's message of "Wed, 1 Sep 2010 13:28:51 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV3613=0 X-Spam-Score: -0.8 (/) X-Debbugs-Envelope-To: 6950-done X-Mailman-Approved-At: Thu, 02 Sep 2010 11:48:13 -0400 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 (--) > Eh, sorry, you are right. reveal-mode takes care of this. I thought I > had it on, but for some reason I had commented it out. Good, so I can close the bug. > by default. That it is on by default seems good. What is the reason > reveal-mode is not on by default? (I have a feeling there was some > small problem, but I can't remember now.) I suspect it could take some more work to make it robust enough to be ON by default. But I encourage everyone to (global-reveal-mode 1) in their .emacs and post patches for the problems they encounter. Stefan From unknown Tue Sep 09 00:07:19 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, 01 Oct 2010 11:24:03 +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 Sat Aug 27 17:18:06 2011 Received: (at control) by debbugs.gnu.org; 27 Aug 2011 21:18:06 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QxQGT-0002lH-Ie for submit@debbugs.gnu.org; Sat, 27 Aug 2011 17:18:06 -0400 Received: from mx1.redhat.com ([209.132.183.28]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QxQGN-0002kb-HI; Sat, 27 Aug 2011 17:18:00 -0400 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p7RLF6pD028226 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 27 Aug 2011 17:15:06 -0400 Received: from mx.meyering.net (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id p7RLF5me002282; Sat, 27 Aug 2011 17:15:06 -0400 Received: from rho.meyering.net (localhost.localdomain [127.0.0.1]) by rho.meyering.net (Acme Bit-Twister) with ESMTP id 2EC9A62226; Sat, 27 Aug 2011 23:15:05 +0200 (CEST) From: Jim Meyering To: Matt McCutchen Subject: Re: bug#6960: mv refuses to move a symlink over a hard link to the same file In-Reply-To: <87sk1sin5b.fsf@meyering.net> (Jim Meyering's message of "Thu, 02 Sep 2010 10:07:44 +0200") References: <1283289668.1923.79.camel@mattlaptop2.local> <87sk1sin5b.fsf@meyering.net> Date: Sat, 27 Aug 2011 23:15:04 +0200 Message-ID: <87zkiusgiv.fsf@rho.meyering.net> Lines: 61 MIME-Version: 1.0 Content-Type: text/plain X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25 X-Spam-Score: -10.6 (----------) X-Debbugs-Envelope-To: control Cc: 6960@debbugs.gnu.org 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: -10.6 (----------) tags 6950 + notabug close 6950 thanks Jim Meyering wrote: > Matt McCutchen wrote: > >> If mv is asked to move a symlink over a hard link to the same file, it >> fails with the message, "A and B are the same file". There is no reason >> why it should complain rather than perform the move. > > Actually, there is a very good reason. See below. > >> Example: > ... >> $ touch New_York >> $ ln New_York localtime >> $ ln -s New_York localtime.new >> $ ls -l >> total 0 >> -rw------- 2 matt matt 0 2010-08-31 17:10 New_York >> -rw------- 2 matt matt 0 2010-08-31 17:10 localtime >> lrwxrwxrwx 1 matt matt 8 2010-08-31 17:11 localtime.new -> New_York >> $ ~/coreutils/coreutils.usr/bin/mv localtime.new localtime >> /home/matt/coreutils/coreutils.usr/bin/mv: `localtime.new' and >> localtime' are the same file > > Here, your regular file, New_York, happens to be empty. > That is a special, degenerate case. > If you lose this file, via use of mv, you lose nothing at all. > Well, in general, you might lose convenient access to the destination inode, > if it had two or more links. > But what if it contained a copy of some important document? > > > It is a problem of perception. > The user sees two files, A and B. > The naive user sees that they have the same contents, > but does not notice they are symlinked. May not even > know what a symlink is... > Our user decides to get rid of the duplicate. > > The lucky naive user moves the real file onto the symlink (say "mv A B") > and that succeeds. If however, s/he uses the other argument ordering > ("mv B A") and moves the symlink onto the real file, some versions > of "mv" would leave our poor user with no copy of the original file. > This is called "data loss" ;-) The user did nothing wrong, yet ended > up destroying what may have been important data. That is why GNU mv > deliberately refuses to perform the offending operation. > > One may argue that there is no data loss when the destination link count > is 2 or more, but once the destination has been unlinked, it may be very > challenging to locate another copy. > > This is not a bug in GNU mv. > It is a deliberate feature. > > Personally, I prefer the semantics of 'mv -f --backup=numbered' > so use a shell alias. There was no further discussion, so I've closed this.