eev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: eepitch with prefixes


From: Tomas Hlavaty
Subject: Re: eepitch with prefixes
Date: Sat, 09 Apr 2022 11:36:33 +0200

On Fri 08 Apr 2022 at 22:03, Eduardo Ochs <eduardoochs@gmail.com> wrote:
>   3) variants of `eepitch-preprocess-line' that replace things like
>      "⟦password⟧" by other strings - and that highlight the replaced
>      parts

it is better to keep passwords in a file and do not display them at all,
e.g. ~/.foo.pwd or /etc/secrets/foo and use paths when necessary, or use
a pasword manager like pass and call $(pass foo) where appropriate

sprinkling passwords in plain text is widespread but bad idea

> ...and that is more or less why I prefer to keep this as the default
> definition for `eepitch-preprocess-line' in eepitch.el:
>
>   (defun eepitch-preprocess-line (line) line)

nothing you listed would be prevented or made more difficult if
eepitch-preprocess-line looked like:

(defvar eepitch-preprocess-regexp nil)
(defun eepitch-preprocess-line (line)
  (if eepitch-preprocess-regexp
    (replace-regexp-in-string eepitch-preprocess-regexp "" line)
    line))

> I don't have any idea of how to write an `eepitch-preprocess-line'
> that is "general enough"

the above is general and convenient enough for usual use-cases,
e.g. your gnuplot example

> and right now I prefer to force people who use alternative definitions
> for it to redefine `eepitch-preprocess-line' themselves explicitly...

people can always do that
the above does not prevent that

but why force them for such an interesting, simple and useful use-case?

>> Another issue I am facing is that my email client indents email
>> threads with spaces so I cannot run eepitch blocks directly from
>> emails with the default eepitch config. It would be great if that
>> worked without any custom user configuration.
>
> can both be handled by the idea (2) above... but I think that this

sure

but as the code upstream changes, i need to keep changing my custom
configuration

with reasonable, stable default, i would not have to worry about it



reply via email to

[Prev in Thread] Current Thread [Next in Thread]