Re: Too fine design granularity leads to numerous macro/function/command existed in Emacs.

[Emanuel Berg via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org>]

Arthur Miller wrote:

> Not to mention, that writing lisp is almost like writing
> pseudo-algorithm. If you reflect over the names chosen in
> that function, you can almost see that it was codded on the
> go, as I was thinking of it. Compare that to pipes and names
> like tr and cut and what not in your original shell
> solution. So it is a kind of simplicity, in my eyes, to use
> just one language, and I guess also a bit of personal
> preferance of course.

As for development time, if that's the right word, it must be
much, much faster using the shell, which is mostly about
combining well known tools often with options and pattern that
return over and over - it is very, very fast.

Compare - this takes as long to do, as it takes to type it:

#! /bin/zsh
longest-line () {
    local f=$1
    awk '{ print length($0) " " $0; }' $f | sort -n | tail -1
}

with this - now, I had a function that worked along similar
lines (ha) so for that reason, it wasn't that slow to write
compared to the shell, without that, I don't know, depends on
the current state/shape :)

;;; -*- lexical-binding: t -*-

(defun sort-lines-length (beg end)
  (interactive (if (use-region-p)
                   (list (region-beginning) (region-end))
                 (list (point-min) (point-max)) ))
  (save-excursion
    (save-restriction
      (narrow-to-region beg end)
      (goto-char (point-min))
      (sort-subr nil
                 #'forward-line
                 #'end-of-line
                 nil nil
                 (lambda (a b) (> (- (cdr a) (car a))
                                  (- (cdr b) (car b)) ))))))
(defalias 'sll #'sort-lines-length)

https://dataswamp.org/~incal/conf/.zsh/text
https://dataswamp.org/~incal/emacs-init/sort-incal.el

-- 
underground experts united
https://dataswamp.org/~incal