Re: eepitch with prefixes

[Tomas Hlavaty]

On Sat 09 Apr 2022 at 15:52, Eduardo Ochs <eduardoochs@gmail.com> wrote:
> I'm not sure if I read your e-mails correctly, but you seem to be
> suggesting that there are users who would like to use
> `eepitch-preprocess-line',

Ideally, I would not use eepitch-preprocess-line at all.

I would set eepitch-preprocess-regexp where necessary
(for example as a local-variable or in eepitch bullet line)
and everything should "just work".

Or in an ideal world, I would not have to worry even about
eepitch-preprocess-regexp and eev would "just work".  Obviously, this
case might be problematic, but the above case is not.

> but for whom the step of putting a block of
> four lines like this one
>
>   ;; See: (find-eepitch-intro "3.3. `eepitch-preprocess-line'")
>   (setq eepitch-preprocess-regexp "")
>   (defun eepitch-preprocess-line (line)
>     (replace-regexp-in-string eepitch-preprocess-regexp "" line))
>
> in their ".emacs"es is too hard.

It is not "hard", it unnecessarily complicates the user interface.

> Well, if I had to interact with a user like that I would say something
> like: `eepitch-preprocess-line' is a feature that should only be used
> by people who know how `defun' works... so please read the first six
> sections of this tutorial when you have time:
>
>   (find-elisp-intro)
>   http://angg.twu.net/eev-intros/find-elisp-intro.html

That would just tell the user that you are unwilling to understand the
issue at hand.

So I would not put it that way.

Defaults are important.

As the author of the code, you have it in your head already.  Your users
don't and now you force them to write their own code and figure out that
part of your code to interface with.  It is simple for you, but
unnecessarily complex for others.  And all that for a case which could
be trivial both for you and your users.

The less time users spend on issue like this, the more time they'll have
to explore parts of eev that actually bring value to their lives.
eepitch-preprocess-line is internal implementation detail.

> Anyway: I like `eepitch-preprocess-line' very much,

Me too.

I am just trying to say that it would be more convenient if the default
covered the regexp use-case instead of being identity.

> but I think that
> `eepitch-preprocess-regexp' 1) could be made into a function, 2) could
> have a shorter name. What do you think of this?
>
>   ;; See: (find-elnode "Creating Buffer-Local")
>   ;;      (find-elnode "Creating Buffer-Local" "defvar-local")
>   ;;      (find-hvariable 'eepitch-pl-re)
>   (defvar-local eepitch-pl-re nil)
>   (defvar       eepitch-pl-re-mail-reader-mode "^  ")
>
>   (defun eepitch-pl-re ()
>     (or eepitch-pl-re
>         (and (eq major-mode 'hlavaty-mail-reader-mode)
>              eepitch-pl-re-mail-reader-mode)
>         ""))
>
>   ;; See: (find-eepitch-intro "3.3. `eepitch-preprocess-line'")
>   (defun eepitch-preprocess-line (line)
>     (replace-regexp-in-string (eepitch-pl-re) "" line))
>
>   ;; TODO: Use `eepitch-pl-flash-re'. See:
>   ;;   http://angg.twu.net/elisp/eepitch-pl-tools.el.html
>   ;;   http://angg.twu.net/elisp/eepitch-pl-tools.el
>   ;; (find-anggwget-elisp "elisp/eepitch-pl-tools.el")
>   ;; (find-eevgrep "grep --color=auto -nH --null -e flash *.el")
>
> I haven't tested it. I would be great if you could play with it for
> some days, modify it to make it more convenient to use, and then
> discuss your ideas...

A few points:

1) To keep it simple, eepitch-regexp should be "^[:blank:]*[•]\\(.*\\)"
   by default.

2) By local-variable I do not mean
   (find-elnode "Creating Buffer-Local" "defvar-local")
   but I mean
   (info "(emacs) Specifying File Variables")
   Sorry for the confusion.

3) Here is a suggestion on how to conveniently factor such user
   configurable code (lets call it "pluggable or"):

   (defun pluggable-or (list args)
     (let (z)
       (while (and list (not (setq z (apply (pop list) args)))))
       z))

   (defvar eepitch-preprocess-functions (list 'identity))
   (defun eepitch-preprocess-line (line)
     (pluggable-or eepitch-preprocess-functions (list line)))

   (defvar eepitch-preprocess-regexp nil)
   (defun eepitch-preprocess-regexp (line)
     (when eepitch-preprocess-regexp
       (replace-regexp-in-string eepitch-preprocess-regexp "" line)))
   (add-to-list 'eepitch-preprocess-functions 'eepitch-preprocess-regexp)

   (defun hlavaty-eepitch-preprocess-line1 (line)
     (when (eq major-mode 'hlavaty-mail-reader-mode)
       (replace-regexp-in-string something "" line)))
   (add-to-list 'eepitch-preprocess-functions 'hlavaty-eepitch-preprocess-line1)

   (defun hlavaty-eepitch-preprocess-line2 (line)
     (when something-else ...))
   (add-to-list 'eepitch-preprocess-functions 'hlavaty-eepitch-preprocess-line2)

   The above code is not tested but should give you a good idea.

> (*): there are some things in eepitch that I would like to change, but
> I don't want to break existing code, so I would do that by
> implementing an "eepitch2" in which the code is factored differently
> and special behaviors are easier to set up...

yeah, that is always a major concern

that's why it is a good strategy to try to keep the user interface
simple and separate the internals when possible.  Once people start
depending on internals, it reduces the flexibility for changing them.