unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: Tak Kunihiro <tkk@misasa.okayama-u.ac.jp>, 16214@debbugs.gnu.org
Cc: Roland McGrath <roland@hack.frob.com>
Subject: bug#16214: Consistency in dired-, occur-, and grep-mode
Date: Sat, 21 Dec 2013 11:23:53 -0800 (PST)	[thread overview]
Message-ID: <4f292d00-c910-4c95-8fb6-1a7c367bb2ff@default> (raw)
In-Reply-To: <20131221.224043.270400015.tkk@misasa.okayama-u.ac.jp>

While there might be room for some minor alignment, in general
it is not good to privilege standardization too highly here, IMO.

There are superficial similarities, and maybe some that are more than
superficial.  But there are also different purposes and use patterns.

These are quite different modes when you look closely and take all
of what each does into account - its raison d'etre: what it is for.
Each should be handled case by case, with an eye to all of its
features and its overall set of use cases.

Dired, in particular, is extremely rich.  Let us not start hobbling
it in the name of standardization.

With that caveat expressed, I have no big objection to what has
been proposed here so far.  (I would prefer that SPC in Dired
remain what it is, but that's about it.)

But I would strongly recommend that we not go overboard with such
an approach - that would be quite misguided IMO.

The main guide for us should be the full set of features - and how
they interact - for each individual mode viewed on its own.

Let's keep in mind the most important rule regarding consistency:

Consistency *within* a given system/application/realm/area/function
is very important.  Consistency *across* different areas is not so
important - essentially only a nice-to-have, permitted when other
things are in fact equal.

Consistency within an area involves/includes also how its parts
fit together.  Individual parts (e.g. key sequences) should not
be considered only on their own - they are parts of a whole/system.

And even in the latter case, when we allow ourselves some added
consistency across areas, we should always keep that *tentative*.
A better idea that comes up later, based on reasons relevant to a
given domain itself, should trump any such cross-domain tentative
harmony we allowed before that better idea.

IOW, internal cohesion/meaning/relevance is in general a much more
important consideration than is external coupling/consistency/convention.





  reply	other threads:[~2013-12-21 19:23 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-21 13:40 bug#16214: Consistency in dired-, occur-, and grep-mode Tak Kunihiro
2013-12-21 19:23 ` Drew Adams [this message]
2013-12-21 20:15 ` Josh
2013-12-21 21:30   ` Juri Linkov
2013-12-22 11:48     ` Tak Kunihiro
2013-12-22 21:44       ` Juri Linkov
2013-12-23 11:34         ` Tak Kunihiro
2013-12-23 21:52           ` Juri Linkov
2013-12-24 23:15             ` Tak Kunihiro
2013-12-25 20:57               ` Juri Linkov
2013-12-28  9:57                 ` Tak Kunihiro
2022-02-10  8:27         ` Lars Ingebrigtsen
2022-02-10  9:26           ` Tak Kunihiro
2022-02-10 11:37             ` Lars Ingebrigtsen
2022-02-11  5:54               ` Tak Kunihiro
2022-02-12  3:57           ` Richard Stallman
2022-02-12  8:16             ` Michael Albinus
2022-02-14  4:13               ` Richard Stallman
2022-02-14  6:52                 ` Michael Albinus
2022-02-15  4:30                   ` Richard Stallman
2022-02-12 19:12           ` Howard Melman
2022-02-12 20:43             ` Howard Melman
2022-02-14  4:14               ` Richard Stallman
2022-02-17 16:28               ` Howard Melman
2022-02-17 17:12                 ` bug#16214: [External] : " Drew Adams
2022-02-20  1:43                 ` Tak Kunihiro
2022-02-20 18:17                   ` Howard Melman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4f292d00-c910-4c95-8fb6-1a7c367bb2ff@default \
    --to=drew.adams@oracle.com \
    --cc=16214@debbugs.gnu.org \
    --cc=roland@hack.frob.com \
    --cc=tkk@misasa.okayama-u.ac.jp \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).