From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Reuben Thomas Newsgroups: gmane.emacs.bugs Subject: bug#18716: Patch for this bug Date: Wed, 9 Nov 2016 22:00:22 +0000 Message-ID: References: <8761fm903w.fsf@sc3d.org> <83a8d9hh62.fsf@gnu.org> <83lgwsfntd.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=94eb2c0ecc5e3768340540e5626a X-Trace: blaine.gmane.org 1478729034 2126 195.159.176.226 (9 Nov 2016 22:03:54 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 9 Nov 2016 22:03:54 +0000 (UTC) Cc: 18716@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Nov 09 23:03:50 2016 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1c4axt-0006Ke-11 for geb-bug-gnu-emacs@m.gmane.org; Wed, 09 Nov 2016 23:03:29 +0100 Original-Received: from localhost ([::1]:42642 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c4axw-0006tU-3p for geb-bug-gnu-emacs@m.gmane.org; Wed, 09 Nov 2016 17:03:32 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36459) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c4avb-0005Gh-Mm for bug-gnu-emacs@gnu.org; Wed, 09 Nov 2016 17:01:09 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c4avX-0007Cc-ET for bug-gnu-emacs@gnu.org; Wed, 09 Nov 2016 17:01:07 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:35949) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1c4avW-0007CO-Rm for bug-gnu-emacs@gnu.org; Wed, 09 Nov 2016 17:01:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1c4avW-00062f-HH for bug-gnu-emacs@gnu.org; Wed, 09 Nov 2016 17:01:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Reuben Thomas Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 09 Nov 2016 22:01:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 18716 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 18716-submit@debbugs.gnu.org id=B18716.147872883223184 (code B ref 18716); Wed, 09 Nov 2016 22:01:02 +0000 Original-Received: (at 18716) by debbugs.gnu.org; 9 Nov 2016 22:00:32 +0000 Original-Received: from localhost ([127.0.0.1]:51348 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1c4av2-00061r-8M for submit@debbugs.gnu.org; Wed, 09 Nov 2016 17:00:32 -0500 Original-Received: from mail-lf0-f54.google.com ([209.85.215.54]:35426) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1c4auz-00061d-AW for 18716@debbugs.gnu.org; Wed, 09 Nov 2016 17:00:29 -0500 Original-Received: by mail-lf0-f54.google.com with SMTP id b14so175024018lfg.2 for <18716@debbugs.gnu.org>; Wed, 09 Nov 2016 14:00:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sc3d.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Y2Ae0W9HXlj8CpyUTR3pWk++EWtvmF39/Ap20PH/WFc=; b=GNb3T5XPGBs9nklf0Y1VWLzR4mb70rS9pGhpRkQ/QMLPqWv71I8Lt/vjhU+gjo2d5T SJjVDOo1FX3ou+gVrkdU/c445fMPsJVwgjc1RbtsBwIsrw8fgblzgGnoaH4B/uniYuIf rL5ExcctfZYxukqt+qNMMEOw3tpOzs5BVixpU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Y2Ae0W9HXlj8CpyUTR3pWk++EWtvmF39/Ap20PH/WFc=; b=RUiPeP49PtZwSFn9c1SrHVtr41OgOAd3PgLEsi/TLmYGXXGl9ScYMr+OnuDl4b9CcH V5ba1iNuICA1PvO9+r0fF7WXAcy5Un7PqymEg1fmCS+0cRetrqRUKRwR7AD+HKEfieV/ lo6DXWBd3RZSruFJv2rGj8pwApTXYG8njRR7qy8+V5Unrzg87ZQlKe8z0W5HXnU/3Iop R+vXqy5gkL4v4NrJbrw0fbiUigWzVEaekSPyXjXRGxdUzjOyJxjA3FBqKRjotECPwNh/ +4nXEYk+xBvu2Hjn/k7i6VOFdD2mUtE5+5ntrWa3ndHMl8ejpjzCJeHKtJKCCbSsWUAQ iqBw== X-Gm-Message-State: ABUngvekfzjIbZ0juIhDTcQSWT/p0hq/ZGAQPQr6rfFvN56RJduv0SfekCI/H8vqMFd8CZe2AAnMNodsaquNhBn2 X-Received: by 10.25.234.145 with SMTP id y17mr989245lfi.25.1478728823030; Wed, 09 Nov 2016 14:00:23 -0800 (PST) Original-Received: by 10.25.212.211 with HTTP; Wed, 9 Nov 2016 14:00:22 -0800 (PST) In-Reply-To: <83lgwsfntd.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.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" Xref: news.gmane.org gmane.emacs.bugs:125531 Archived-At: --94eb2c0ecc5e3768340540e5626a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 9 November 2016 at 19:36, Eli Zaretskii wrote: > > From: Reuben Thomas > > Date: Tue, 8 Nov 2016 22:16:45 +0000 > > Cc: 18716@debbugs.gnu.org > > > > I don't understand what happened to the comment about *.JPG files on > > case-sensitive filesystems, > > > > I took it into account. My experience is that on a case-insensitive > system (e.g. a GNU system), one finds > > occasional files like this, typically copied from other systems or > extracted from archives. These are not a > > problem for dired-omit-mode. For visiting such files, treating > auto-mode-alist and similar case-insensitively is > > no problem. > > Sorry, I don't understand what you mean by "these are not a problem". > With your change, *.JPG files will no longer be treated like *.jpg on > Posix systems. Won't people who want *.JPG hidden complain? IOW, > isn't this change backward-incompatible? > =E2=80=8BI'm confused. I have not changed the behaviour of visiting files. = When I said "treating auto-mode-alist and similar case-insensitively is not a problem", I meant that it is OK that auto-mode-alist is applied case-insensitively. When we talk about *.JPG files, we are not talking about dired-omit-mode, because ".jpg" is not a suffix that would (normally) be omitted.=E2=80=8B What I was trying to explain is that unexpected case-insensitivity in auto-mode-alist is not a problem, because the user immediately sees the effects. On the other hand, in dired-omit-mode it is a problem, because the user might not see the effects (the effects are to hide things). I double-checked, and the code I changed, dired-mark-unmarked-files, is only called by dired-omit. However, it can also be called interactively, so I have certainly changed the interactive behavior. I could add a parameter to dired-mark-unmarked-files, case-fold-p, defaulting to nil, which would be set by its current callers. But I think you are saying that this change to the behavior of dired-omit-mode, which I have suggested does not need a new preference, should indeed have a new preference, so I can add that too. I think, though, that it should default to `t', i.e. dired-omit-mode behaving case-sensitively by default. If you'd say what you consider acceptable, I'll implement it. > > + (case-fold-search (memq system-type '(windows-nt cygwin)))= ) > > The list should include ms-dos as well. > =E2=80=8BOK, I will add a patch for files.el, since I got the list from the= re, where it is used for the same purpose.=E2=80=8B Or perhaps there should be = a global variable defined in files.el containing the list? > * lisp/dired-x.el (Commentary): Remove USAGE section explaining how to > > use dired-x from .emacs. It is now fully customizable. > > * lisp/dired-x.el (dired-guess-shell-alist-user): Remove explanation of > > how to set this custom variable in .emacs. It should be customized. > > Why remove these comments? The existence of Custom doesn't preclude > people from customizations in plain Lisp. > The documentation is a maintenance burden (since it is hand-written and duplicate), few people will read it anyway, and further it is redundant, since it can be customized in plain Lisp in the same way as any other defcustom. (I presume you're not implying that we should add documentation to every Lisp source file to show how to customize each defcustom?) Further, the documentation as it is implies that these variables *should* be customized in plain Lisp, since (unlike most cases), there is explicit documentation about it. --=20 http://rrt.sc3d.org --94eb2c0ecc5e3768340540e5626a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On = 9 November 2016 at 19:36, Eli Zaretskii <eliz@gnu.org> wrote:
=
> From: Reuben Thomas <rrt@sc3d.org>
> Date: Tue, 8 Nov 2016 22:16:45 +0000
> Cc: 18716@debbugs.gnu.org=
>
>=C2=A0 I don't understand what happened to the comment about *.JPG = files on
>=C2=A0 case-sensitive filesystems,
>
> I took it into account. My experience is that on a case-insensitive sy= stem (e.g. a GNU system), one finds
> occasional files like this, typically copied from other systems or ext= racted from archives. These are not a
> problem for dired-omit-mode. For visiting such files, treating auto-mo= de-alist and similar case-insensitively is
> no problem.

Sorry, I don't understand what you mean by "these are not a= problem".
With your change, *.JPG files will no longer be treated like *.jpg on
Posix systems.=C2=A0 Won't people who want *.JPG hidden complain?=C2=A0= IOW,
isn't this change backward-incompatible?

=E2=80=8BI'= ;m confused. I have not changed the behaviour of visiting files. When I sai= d "treating auto-mode-alist and similar case-insensitively is not a pr= oblem", I meant that it is OK that auto-mode-alist is applied case-ins= ensitively.
When we talk = about *.JPG files, we are not talking about dired-omit-mode, because "= .jpg" is not a suffix that would (normally) be omitted.=E2=80=8B
=

What I was trying to explain i= s that unexpected case-insensitivity in auto-mode-alist is not a problem, b= ecause the user immediately sees the effects. On the other hand, in dired-o= mit-mode it is a problem, because the user might not see the effects (the e= ffects are to hide things).

I double-checked, and the code I changed, dired-mark-unmarked-files, is = only called by dired-omit. However, it can also be called interactively, so= I have certainly changed the interactive behavior.

I could add a parameter to dired-mark-unmarked-f= iles, case-fold-p, defaulting to nil, which would be set by its current cal= lers. But I think you are saying that this change to the behavior of dired-= omit-mode, which I have suggested does not need a new preference, should in= deed have a new preference, so I can add that too. I think, though, that it= should default to `t', i.e. dired-omit-mode behaving case-sensitively = by default.
If you'd = say what you consider acceptable, I'll implement it.
=C2=A0
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (case-f= old-search (memq system-type '(windows-nt cygwin))))

The list should include ms-dos as well.

=E2=80=8BOK, I will= add a patch for files.el, since I got the list from there, where it is use= d for the same purpose.=E2=80=8B Or perhaps there should be a global variab= le defined in files.el containing the list?

> * lisp/dired-x.el (Commentary): Remove USAGE= section explaining how to
> use dired-x from .emacs.=C2=A0 It is now fully customizable.
> * lisp/dired-x.el (dired-guess-shell-alist-user): Remove explanat= ion of
> how to set this custom variable in .emacs.=C2=A0 It should be customiz= ed.

Why remove these comments?=C2=A0 The existence of Custom doesn't preclu= de
people from customizations in plain Lisp.

The do= cumentation is a maintenance burden (since it is hand-written and duplicate= ), few people will read it anyway, and further it is redundant, since it ca= n be customized in plain Lisp in the same way as any other defcustom. (I pr= esume you're not implying that we should add documentation to every Lis= p source file to show how to customize each defcustom?) Further, the docume= ntation as it is implies that these variables *should* be customized in pla= in Lisp, since (unlike most cases), there is explicit documentation about i= t.

--
http://rrt.sc3d.org=
--94eb2c0ecc5e3768340540e5626a--