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#6799: 24.0.50; Please add dired-details.el to Emacs [patch] Date: Mon, 11 Feb 2013 09:25:40 -0500 Message-ID: References: <9C9137560F644E759AD573BBBD8E59EF@us.oracle.com> <5EA47A0255F8494DB430B52D46876641@us.oracle.com> <65D921448B0644988BE6445A2EF3E021@us.oracle.com> <21FFB8EA85964411A9B790386C5DA3AD@us.oracle.com> <878v8zow44@ch.ristopher.com> <87k3sj6juj@ch.ristopher.com> <87mwxcx149@ch.ristopher.com> <87wqugmcu8@ch.ristopher.com> <87mwvbuus2@ch.ristopher.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1360592815 14663 80.91.229.3 (11 Feb 2013 14:26:55 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 11 Feb 2013 14:26:55 +0000 (UTC) To: 6799@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Feb 11 15:27:16 2013 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 1U4uLf-0002vq-Mo for geb-bug-gnu-emacs@m.gmane.org; Mon, 11 Feb 2013 15:27:11 +0100 Original-Received: from localhost ([::1]:52464 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U4uLM-0002JH-Ci for geb-bug-gnu-emacs@m.gmane.org; Mon, 11 Feb 2013 09:26:52 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:46802) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U4uLH-0002J9-6V for bug-gnu-emacs@gnu.org; Mon, 11 Feb 2013 09:26:50 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1U4uLC-0002jT-QW for bug-gnu-emacs@gnu.org; Mon, 11 Feb 2013 09:26:47 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:44731) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U4uLC-0002jP-NX for bug-gnu-emacs@gnu.org; Mon, 11 Feb 2013 09:26:42 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1U4uLW-0000pY-Nf for bug-gnu-emacs@gnu.org; Mon, 11 Feb 2013 09:27:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 11 Feb 2013 14:27:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 6799 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Original-Received: via spool by submit@debbugs.gnu.org id=B.13605927763140 (code B ref -1); Mon, 11 Feb 2013 14:27:02 +0000 Original-Received: (at submit) by debbugs.gnu.org; 11 Feb 2013 14:26:16 +0000 Original-Received: from localhost ([127.0.0.1]:50195 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U4uKl-0000oa-74 for submit@debbugs.gnu.org; Mon, 11 Feb 2013 09:26:15 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:35306) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U4uKe-0000oP-KY for submit@debbugs.gnu.org; Mon, 11 Feb 2013 09:26:10 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1U4uKI-0002c3-B4 for submit@debbugs.gnu.org; Mon, 11 Feb 2013 09:25:48 -0500 Original-Received: from lists.gnu.org ([208.118.235.17]:33803) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U4uKI-0002bw-6U for submit@debbugs.gnu.org; Mon, 11 Feb 2013 09:25:46 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:46665) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U4uKG-0002H3-Eq for bug-gnu-emacs@gnu.org; Mon, 11 Feb 2013 09:25:46 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1U4uKF-0002bf-0R for bug-gnu-emacs@gnu.org; Mon, 11 Feb 2013 09:25:44 -0500 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.182]:9683) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U4uKE-0002bT-Lg for bug-gnu-emacs@gnu.org; Mon, 11 Feb 2013 09:25:42 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EABK/CFFFpZnt/2dsb2JhbABEvw4Xc4IeAQEEAVYoCws0EhQYDYhCBsEtkQoDiGGcGYFegxU X-IPAS-Result: Av4EABK/CFFFpZnt/2dsb2JhbABEvw4Xc4IeAQEEAVYoCws0EhQYDYhCBsEtkQoDiGGcGYFegxU X-IronPort-AV: E=Sophos;i="4.84,565,1355115600"; d="scan'208";a="963442" Original-Received: from 69-165-153-237.dsl.teksavvy.com (HELO pastel.home) ([69.165.153.237]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 11 Feb 2013 09:25:41 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id AAE7159527; Mon, 11 Feb 2013 09:25:40 -0500 (EST) In-Reply-To: <87mwvbuus2@ch.ristopher.com> (Christopher Schmidt's message of "Mon, 11 Feb 2013 08:19:52 +0000 (GMT)") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.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:71055 Archived-At: > dired-(next|previous)-line use (forward|backward)-line for point > movement. These functions ignore hidden lines and subsequent point > movement by the editing loop does not do the right thing when point > moves backwards over a hidden line. Thanks. Then the code needs a clear comment about it, citing the specific concrete case that it's trying to fix. > (defvar use-case 0) > (with-selected-window > (or (get-buffer-window "*moose*") > (progn > (split-window-below))) > (switch-to-buffer (get-buffer-create "*moose*")) > (erase-buffer) > (insert "Header\n" > (propertize "Hidden\n" 'invisible t) > "Stuff") > (cl-ecase use-case > (0 > (goto-char (point-min)) > (forward-line 1)) > (1 > (goto-char (point-max)) > (forward-line -1)) > (2 > (goto-char (point-min)) > (next-line 1)) > (3 > (goto-char (point-max)) > (next-line -1))) > (prog1 use-case > (setq use-case (% (1+ use-case) 4)))) > Put that in scratch, eval the first form, eval the second form four > times in a row. Use case 1 does not work. The change you cited tries > to work around this problem in dired. I'm not sure what this shows: I get a buffer with two visible lines ("Header" and "Stuff"); case 0 moves point to just before "Stuff" and so does case 1, and both seem right to my understanding of the code you provided. > I do not know whether dired-(next|previous)-line should use > (next|previous)-line with nil-bound line-move-visual. AFAICT > (next|previous)-line do not do the right thing either. >>> + (if (derived-mode-p 'locate-mode) >>> + (setq dired-hide-details-mode nil) >> Could you explain why locate-mode needs such special treatment (here >> and in locate-mode-map)? I'm mostly worried here that maybe some >> other mode might require similar treatment. > The buffer generated by M-x locate RET does not contain any "details" to > hide. dired-hide-details-mode would be a no-op there. A no-op doesn't sound like a bad thing. > Locate buffers are not real dired buffer. locate-mode is an independent > major mode whose keymap derives from dired-mode-map. locate runs > dired-mode-hook despite the current buffer not being derived from > dired-mode. Indeed, it looks messy: it runs dired-mode-hook but not from locate-mode. Of course, part of it is because dired-mode is still not written as a proper mode function (e.g. it requires a `dir' argument), so locate can't use it to derive from it. > I think ignoring locate is better than complaining that > dired-hide-details-mode is enabled in a buffer that is not derived > from dired-mode. If, as you say, dired-details would simply be a no-op in locate, then I think the better option is to simply ignore locate, in the sense of not doing anything special about, rather than write code that tries to actively avoid running dired-details code in locate. > I am not aware of any other mode that behaves that way. I was thinking of virtual-dired (in dired-x), vc-dired (which doesn't exist any more in Emacs, but there might still be similar thingies out there), ... Stefan