Re: Words with spaces highlighted in elisp-mode comments

[Emanuel Berg <incal@dataswamp.org>]

uzibalqa wrote:

> Besides using comment for descriptive purposes, I use it for
> FIX-THIS, IMPROVE-THIS, DEVELOP-THIS, PENDING.
>
> ;; PENDING
> ;;   'OMS GMBL'
> ;;      1st Fail Y Down
> ;;      2nd Fail P Down if P not -2.5 to +2.5 
> ;;   'FF MDM I/O Error'
> ;;      I/O Reset

I think 'this' is an ugly syntax for that purpose, it looks
like the intention is ironic. Fix this as 'soon' as
possible ...

But moreover, I don't think we want to encourage people to
insert those as they make the code ugly - especially if given
a certain face, what would happen is people would develop
"code blindness", instead of seeing the source they would see
a bunch of "programming programmers" directives.

In Elisp, one could denote, say, three initiators to denote
a heading or label

;;; Brilliant Code Below

because that convention already exists in Emacs packages, see

  https://dataswamp.org/~incal/emacs-init/wrap-search.el

only the trailing colon would be optional. (I'm not sure what
they are called as it is, what did you say - overlay? - anyway
if three initiators must be reserved for that and only that
one could say that _four_ initiators denote a heading or label.)

Then a single one would be a comment relating to that
particular line

(cl-incf x) ; I think it can take one more

and two initiators for an arbitrary number of lines below;
also, for general comment use.

It would look like this

;;;; Duncan's code

;; now we are entering murky water
(setq x 1)
(cl-incf x) ; I think it can take one more

You can see how that works with `message-mode' (the angle
brackets) in this screenshot:

  https://dataswamp.org/~incal/figures/emacs/emacsuxusubmarinespetsnaz.png

Those are the `gnus-cite-1' all the way up to `gnus-cite-11'.

We could have that in Elisp as well, either by a similar
enumeration, or by calling the faces something to denote what
their intended usage are.

But then we would hurry to make sure that all the specific
comment faces would initially be unset, and inherit from
a base comment face. That way all comments would still get the
same color, because it is the way I like it anyway, and in the
example above, because of the blank lines not the least, I can
see quite clearly what is intended as a heading and what
isn't. Distinct face would make it even more clear in that
specific sense yes, but in general it would make the code
dizzy and unrestful and too much attention would land on the
comments, that we want to be low-key, instead of the code.

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