Re: ELisp - Making a list from a function returning a number

[Emanuel Berg]

Jean Louis wrote:

> No, quite contrary. LISP allows for any paradigm of
> programming. Linear programming, etc. It does not matter.
> I see no problem there like you see it.

Yes, I'm talking Elisp conventions then...

> Many of my command line tools in Common Lisp only load other
> programs and invoke one let. There are conventions, but
> first LISP programs was not written in any of our
> today's conventions.

Yes, I'm talking the present then...

>> 2. remove blank lines and commented out lines
>
> For one's own understanding this may help. Step by step.
> Learning goes on gradient.

When one posts here, and for one's own karma, it is better to
make it as good as possible, even (especially) when it
doesn't work.

>> 3. don't use comments that do not add any information (e.g.,
>>    "body of let" - but that is already plain and true, by
>>    definition)
>
> That is what you know on a different gradient. Even more comments
> would be required on beginning gradient and this in all programming
> languages. Advanced programmers need no comments, they read the
> code.

One should comment what is unusual, counterintuitive or needs
further explanation. For example something that looks wrong,
but is right. Advanced programmers do this all the time I was
about to say, but luckily this doesn't happen all the time :)

In Elisp one can also add little helpers that can be
evaluated, e.g.

;; (setq latex-mode-hook nil)
(defun latex-mode-hook-f ()
  (set-latex-keys)
  (auto-fill-mode)
  (abbrev-mode)
  (lines) )
(add-hook 'latex-mode-hook #'latex-mode-hook-f)

One can also use comments as headers, this works especially
well since they get another color with font lock, namely the
font-lock-comment-face and
font-lock-comment-delimiter-face faces.

For example:

(let ((the-map gnus-group-mode-map))
  (disable-super-global-keys  the-map)
  (set-close-key              the-map)
  (set-vertical-keys          the-map)
  
  ;; show
  (define-key the-map "f"     #'gnus-group-list-few-groups-sort)
  (define-key the-map "l"     #'gnus-group-list-all-groups-sort)
  
  ;; goto
  (define-key the-map "m"     #'gnus-group-show-mails)
  (define-key the-map "s"     #'gnus-group-show-sent)
  
  ;; group
  (define-key the-map "3"     #'gnus-group-unsubscribe-current-group)
  (define-key the-map "\C-k"  nil) ; disable `gnus-group-kill-group'
  (define-key the-map "A"     #'gnus-group-make-group)
  (define-key the-map "a"     #'gnus-group-post-news-to-group-at-point)
  
  ;; servers
  (define-key the-map "o"     #'gnus-server-open-all-servers)
  (define-key the-map "S"     #'gnus-group-enter-server-mode)
  
  ;; misc
  (define-key the-map "\M-0"  #'gnus-undo)
  (define-key the-map "g"     #'gnus-group-get-new-news-verbose)
  (define-key the-map "u"     #'gnus-score-load-files)
  )

So the use of comments should be put to use sensibly by
beginner and advanced programmers alike...

>> 4. use the normal indentation space for Elisp, in
>>    `elisp-mode' two spaces
>
> It may be hard to understand for new Elisp programmer what
> you mean here. I do not use nothing, I use elisp-mode and
> I press TAB or M-q to indent everything in a region. I would
> not even know how it should be indented if I would not be
> using emacs lisp mode.

OK, well two spaces is the standard and yes auto indentation
is very useful.

>> 5. again, don't use `setq' in function bodies when there is
>>    no need, you already have the vars in let*, do all
>>    computation there (add more vars if necessary, for
>>    clarity, even)
>
> Especially in a list within `let' form there is no problem
> in using `setq'. In that above example I can fully
> understand that way of doing things as it gives clearer
> picture on what is happening.

Yes, there is a problem with `setq' in functions and that is
it will silently create a global variable if one makes a typo,
also it makes the code more unclear, also often it isn't even
needed since one can just as easily do all the computation
using `let'. On is using let anyway so why don't do it
there anyway?

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal