unofficial mirror of help-gnu-emacs@gnu.org
 help / color / mirror / Atom feed
From: Michael Heerdegen <michael_heerdegen@web.de>
To: help-gnu-emacs@gnu.org
Subject: Re: Making ielm behave like a shell (getting to previous commands using the up-arrow key)
Date: Sat, 19 Dec 2020 03:07:25 +0100	[thread overview]
Message-ID: <87k0teo8f6.fsf@web.de> (raw)
In-Reply-To: X9yQTIpbqBxhK6Mf@protected.rcdrun.com

Jean Louis <bugs@gnu.support> writes:

> For me and in my programming somebody from scheme programming,
> probably in Guile teached me that I should be making smaller functions
> where each function does something and outputs something. And I that
> gave me impression of being very simple. But then in Emacs packages I
> too often find long and incomprehensible functions that do not follow
> the style I have learned before some years.

It's debatable how large defuns should be.  In the Emacs sources, a lot
of them could be split or refactored indeed.  What we have is the result
of a development.  In the repositories, small changes are preferred and
are better traceable with version control systems, and refactoring is an
unrewarding job that even messes git history.  As a consequence, defuns
tend to grow.  I guess that is one side of the phenomenon called "bit
rotting".

The other side is that what one might consider as an ideal size of
defuns (or "factors") in his code might vary with your familiarity and
experience with the language and the project.  Experienced people might
find relatively large units ok that would be not acceptable for somebody
for whom working with that language is not daily business.

Regards,

Michael.




  parent reply	other threads:[~2020-12-19  2:07 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-17  3:02 Making ielm behave like a shell (getting to previous commands using the up-arrow key) steve-humphreys
2020-12-17  3:34 ` Okam
2020-12-17  4:27 ` Michael Heerdegen
2020-12-17  4:44   ` steve-humphreys
2020-12-17  5:02     ` Michael Heerdegen
2020-12-17  5:17       ` steve-humphreys
2020-12-17  9:06         ` Jean Louis
2020-12-17  9:13           ` Jean Louis
2020-12-17 22:29           ` Michael Heerdegen
2020-12-18  5:05             ` Jean Louis
2020-12-18  9:01               ` Michael Heerdegen
2020-12-18 11:19                 ` Jean Louis
2020-12-18 17:14                   ` Drew Adams
2020-12-18 18:36                     ` Jean Louis
2020-12-18 19:11                       ` Drew Adams
2020-12-18 19:53                         ` Jean Louis
2020-12-18 21:15                           ` Drew Adams
2020-12-19  2:07                   ` Michael Heerdegen [this message]
2020-12-19  2:51                     ` Drew Adams
2020-12-18 11:28                 ` Jean Louis
2020-12-19  1:55                   ` Michael Heerdegen
2020-12-19  2:45                     ` Drew Adams
2020-12-19  1:57               ` Michael Heerdegen
2020-12-17  8:22   ` Joost Kremers
2020-12-18 10:20     ` Philip K.

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=87k0teo8f6.fsf@web.de \
    --to=michael_heerdegen@web.de \
    --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).