On Sat 09 Apr 2022 at 15:52, Eduardo Ochs <[email protected]> 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.
