From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Christopher Schmidt Newsgroups: gmane.emacs.bugs Subject: bug#6799: 24.0.50; Please add dired-details.el to Emacs [patch] Date: Mon, 11 Feb 2013 16:08:42 +0000 (GMT) Message-ID: <87k3qeestt@ch.ristopher.com> 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 1360599004 13536 80.91.229.3 (11 Feb 2013 16:10:04 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 11 Feb 2013 16:10:04 +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 17:10:22 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 1U4vxV-0001oO-Er for geb-bug-gnu-emacs@m.gmane.org; Mon, 11 Feb 2013 17:10:21 +0100 Original-Received: from localhost ([::1]:41219 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U4vxB-0005HJ-VA for geb-bug-gnu-emacs@m.gmane.org; Mon, 11 Feb 2013 11:10:01 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:46085) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U4vx2-0004zX-37 for bug-gnu-emacs@gnu.org; Mon, 11 Feb 2013 11:09:59 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1U4vwt-0004Vh-Ev for bug-gnu-emacs@gnu.org; Mon, 11 Feb 2013 11:09:52 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:45587) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U4vwt-0004VZ-BF for bug-gnu-emacs@gnu.org; Mon, 11 Feb 2013 11:09:43 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1U4vxC-00056g-Rw for bug-gnu-emacs@gnu.org; Mon, 11 Feb 2013 11:10:03 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Christopher Schmidt Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 11 Feb 2013 16:10: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.136059897219583 (code B ref -1); Mon, 11 Feb 2013 16:10:02 +0000 Original-Received: (at submit) by debbugs.gnu.org; 11 Feb 2013 16:09:32 +0000 Original-Received: from localhost ([127.0.0.1]:51051 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U4vwh-00055n-CO for submit@debbugs.gnu.org; Mon, 11 Feb 2013 11:09:32 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:34586) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U4vwZ-00055a-Tf for submit@debbugs.gnu.org; Mon, 11 Feb 2013 11:09:26 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1U4vw8-0004Kt-Ci for submit@debbugs.gnu.org; Mon, 11 Feb 2013 11:09:02 -0500 Original-Received: from lists.gnu.org ([208.118.235.17]:48545) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U4vw8-0004Kp-9r for submit@debbugs.gnu.org; Mon, 11 Feb 2013 11:08:56 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:45921) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U4vw4-0003pi-5i for bug-gnu-emacs@gnu.org; Mon, 11 Feb 2013 11:08:56 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1U4vvx-0004GT-UF for bug-gnu-emacs@gnu.org; Mon, 11 Feb 2013 11:08:52 -0500 Original-Received: from ristopher.com ([146.185.21.93]:55334 helo=saturn.ch.ristopher.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U4vvx-0004Fu-Jd for bug-gnu-emacs@gnu.org; Mon, 11 Feb 2013 11:08:45 -0500 Original-Received: by saturn.ch.ristopher.com (Postfix, from userid 0) id B502E20AA9; Mon, 11 Feb 2013 16:08:42 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ch.ristopher.com; s=mail; t=1360598922; bh=Brt+5aTDqmABWtIGYuiQ8WJcWgqu32NSIOb2QrOqTIg=; h=From:To:Subject:In-Reply-To:Message-ID:References:MIME-Version: Content-Type:Date; b=UmWhRmpDBmwvABx0EzTblKfHU3Wz4pBZ9jJzE8fdwdQaLWyeX0ZgHSchKOBDByGmJ ITN9DtDVJ0Suq8G53LP4+MEukIb+O8xxQgZObrD8Pvqjz4aFcBVkLOgAmRng8GsbZe xJoAiKth12ZNkRJslIEmGa327YbjDmteV7iEDEDU= In-Reply-To: (Stefan Monnier's message of "Mon, 11 Feb 2013 09:25:40 -0500") Mail-Followup-To: bug-gnu-emacs@gnu.org X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x 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:71060 Archived-At: Stefan Monnier writes: Hi Stefan, thank you very much for your feedback. >> 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. [...] >> 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. Emacs behaves correctly. (forward-line -1) is executed but the point does not move across one visible line. (dired-next-line -1) should skip hidden lines, though. (next-line -1) does the right thing. Unfortunately next-line has some quirks, such as goal-column, next-line-add-newlines, etc. What about using line-move directly? The workaround is less cumbersome. (defun dired-next-line (arg) "Move down lines then position at filename. Optional prefix ARG says how many lines to move; default is one line." (interactive "p") (let ((line-move-visual) (goal-column)) (line-move arg t)) ;; We never want to move point into an invisible line. (while (and (invisible-p (point)) (not (if (and arg (< arg 0)) (bobp) (eobp)))) (forward-char (if (and arg (< arg 0)) -1 1))) (dired-move-to-filename)) >>>> + (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. There is the message "Dired-Hide-Details mode (disabled|enabled)". Is there any reason for locate-filename-indentation to be 4 rather than 2 by default? Dired-hide-details-mode considers everything from the third character to the file name to be a detail. That is dired-hide-details-mode hides these two spaces if enabled. This is either a bug or a feature. I do not know. Other than that, dired-hide-details-mode it is a no-op in locate-mode buffers. >> 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. Could we set the derived-mode-parent property of locate-mode to dired-mode? One way or another, (derived-mode-p 'dired-mode) should return non-nil in locate-mode buffers. >> 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. Ok. >> 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), ... As long as these modes use dired-insert-set-properties in the way it is meant to be there should not be a problem. Christopher