unofficial mirror of help-gnu-emacs@gnu.org
 help / color / mirror / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: help-gnu-emacs@gnu.org
Subject: Re: Too fine design granularity leads to numerous macro/function/command existed in Emacs.
Date: Fri, 13 Aug 2021 10:25:30 +0300	[thread overview]
Message-ID: <838s15dcwl.fsf@gnu.org> (raw)
In-Reply-To: <CAGP6PO+1JOANGUJHo3p-EwUGs_vYp4n7doXvWg+p1dvg4=W0KA@mail.gmail.com> (message from Hongyi Zhao on Fri, 13 Aug 2021 15:12:39 +0800)

> From: Hongyi Zhao <hongyi.zhao@gmail.com>
> Date: Fri, 13 Aug 2021 15:12:39 +0800
> 
>  It's well known that Emacs has already implemented numerous
> macro/function/command in its current version. But it seems that this
> is caused by, to a certain degree, the too fine granularity, i.e.,
> there are many functionally similar macro/function/command are
> designed separately, for example, `directory-files' and
> `directory-files-recursively'. The traditional Unix tool, `find', can
> do all the jobs of the above two functions by adjusting its
> `-maxdepth' and `-mindepth' arguments.
> 
> So, I want to know why these macro/function/command in Emacs are
> developed with such a fine granularity.

They aren't.  You provided just one example, and drew far-reaching
conclusions from that single example.  If you want to make such a
general claim, please show more examples of what you consider to be
"fine granularity".

Specifically about the one example you provided: directory-files is a
primitive, written in C, so it provides the basic functionality of
fetching file names from a single directory. The
directory-files-recursively function is written in Lisp, it builds on
that primitive and provides extended functionality.  This paradigm, of
having primitives provide the basics and implement the rest in Lisp on
top of those primitives, is central to Emacs design.



  reply	other threads:[~2021-08-13  7:25 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-13  7:12 Too fine design granularity leads to numerous macro/function/command existed in Emacs Hongyi Zhao
2021-08-13  7:25 ` Eli Zaretskii [this message]
2021-08-14  0:46   ` Hongyi Zhao
2021-08-14  6:18     ` Eli Zaretskii
2021-08-14  6:29       ` Hongyi Zhao
2021-08-14  7:18         ` Eli Zaretskii
2021-08-14  7:25           ` Hongyi Zhao
2021-08-14  7:47             ` Eli Zaretskii
2021-08-13  7:57 ` Emanuel Berg via Users list for the GNU Emacs text editor
2021-08-13  8:34   ` Hongyi Zhao
2021-08-13  8:56     ` Emanuel Berg via Users list for the GNU Emacs text editor
2021-08-13  9:20       ` Emanuel Berg via Users list for the GNU Emacs text editor
2021-08-13  9:26 ` Arthur Miller
2021-08-13 10:11   ` Emanuel Berg via Users list for the GNU Emacs text editor
2021-08-13 13:00     ` [OFF TOPIC] Algorithms (was: Re: Too fine design granularity leads to numerous macro/function/command existed in Emacs.) 2QdxY4RzWzUUiLuE
2021-08-13 13:07       ` Emanuel Berg via Users list for the GNU Emacs text editor
2021-08-13 13:17         ` Yuri Khan
2021-08-13 13:26           ` Emanuel Berg via Users list for the GNU Emacs text editor
2021-08-13 13:48     ` Too fine design granularity leads to numerous macro/function/command existed in Emacs Arthur Miller
2021-08-13 18:21       ` Emanuel Berg via Users list for the GNU Emacs text editor
2021-08-13 20:47         ` Arthur Miller
2021-08-13 23:42           ` Emanuel Berg via Users list for the GNU Emacs text editor
2021-08-14  0:24             ` Hongyi Zhao
2021-08-14  0:42               ` Emanuel Berg via Users list for the GNU Emacs text editor
2021-08-14  1:02                 ` Hongyi Zhao
2021-08-14  2:18                   ` Emanuel Berg via Users list for the GNU Emacs text editor
2021-08-14  1:46             ` Arthur Miller
2021-08-13 23:49         ` Hongyi Zhao
2021-08-13 23:54           ` Emanuel Berg via Users list for the GNU Emacs text editor
2021-08-13 14:15   ` Eli Zaretskii
2021-08-13 14:42     ` Arthur Miller
2021-08-13 15:59       ` Eli Zaretskii
2021-08-13 17:09         ` Arthur Miller
2021-08-13 18:16       ` Emanuel Berg via Users list for the GNU Emacs text editor
2021-08-13 23:40       ` Hongyi Zhao
2021-08-13 23:45         ` Emanuel Berg via Users list for the GNU Emacs text editor
2021-08-13 23:57           ` Emanuel Berg via Users list for the GNU Emacs text editor
2021-08-13 23:47         ` Emanuel Berg via Users list for the GNU Emacs text editor

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=838s15dcwl.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=help-gnu-emacs@gnu.org \
    /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.
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).