Re: message-simplify-subject too coupled with reply (and not extensible)

[Eric Abrahamsen <eric@ericabrahamsen.net>]

"Garreau, Alexandre" <galex-713@galex-713.eu> writes:

> After having discovered `message-strip-subject-trailing-was', I searched
> for how it was used and if there were similar functions, and there were,
> all in `message-simplify-subject-functions', quite interesting one.
>
> One critic is, their standard caller, `message-simplify-subject', work
> only for the 4 default functions (stopping users from adding their own
> custom functions in addition or replacement of the default ones (for
> instance I’d like a function to remove the inner “was”s but not the
> outer one)), instead of recursively applying them all to the said
> subject (after all their have the same call semantics: one argument: the
> subject!).

Yup, there's quite a few odd places like this in Gnus, where the user is
given a custom option, but then Gnus only accepts certain values within
that option -- apart from being able to remove values from it, the
ability to customize becomes less meaningful. In this case, I don't see
why people shouldn't be able to put any function they like in there.

> But the main problem is, as this function call manually each of these
> four functions, in the special case of `message-strip-subject-re', it
> removes excedentary “Re:”… and add a new one!  so in the end,
> `message-reply' doesn’t do that: that fills terribly wrong.
> `message-reply' should add a “Re:” (that’s the least expectable from it,
> it’s confusing it is not it that does it), and
> `message-simplify-subject' should do what its name says, so that to be
> really useful: simplify subject, not prepare it for another different
> function (namely, `message-reply')!

I'm less certain about this. It's one of those cases where probably no
one remembers why it is the way it is, and no one wants to touch it
because who knows how things might suddenly break. If I were you I would
report two separate bugs, so that the first had a better chance of being
accepted.

> I wanted to see this function used in `org-email-link-description', but
> it’s impossible because of this oddity (otherwise the message could be
> falsely seen as a reply while it isn’t one).  If it was possible, the
> subject cited in org links could be *semantically* shorter (rather than
> blindly arbitrarily cut in the middle), and benefit from user
> customizations and extensions.
>
> May I propose the following implementation:
>
> #+BEGIN_SRC emacs-lisp
>   (defun message-simplify-subject (subject &optional functions)
> "Return simplified SUBJECT"
>     (let ((functions (or functions message-simplify-subject-functions)))
>       (if functions
>           (let ((fun (car functions))
>                 (other-funs (cdr functions)))
>             (message-simplify-subject (funcall fun subject) other-funs))
>         subject)))
> #+END_SRC

That looks fine, though you just don't see a whole lot of recursion used
in the Emacs codebase. This is the sort of thing I like the `seq'
functions for:

(seq-reduce (lambda (subject fun)
	      (funcall fun subject))
	    message-simplify-subject-functions subject)

Or just a simple dolist and setq.

> Then, `message-reply' should replace “(message-simplify-subject
> subject)” with “(concat "Re: " (message-simplify-subject subject))”, and
> also, `message-strip-list-identifiers should get a “unless (equal
> gnus-list-identifiers "")” around the body of its outer `let' (not
> mandatory, but otherwise `message-strip-list-identifiers' might remove a
> “Re:”, what `message-strip-subject-re' should do, even if it wasn’t
> asked by the user by being put in `message-simplify-subject-functions').

And `message-strip-subject-trailing-was' already checks
`message-subject-trailing-was-query', so the extra check there is
redundant, which would mean `message-simplify-subject' really could just
be a simple reduction function.

> May I also suggest, for consistency, to rename
> `message-strip-list-identifiers' to
> `message-strip-subject-list-identifiers'.  I guess it isn’t used
> elsewhere than in message.el.
>
> It is also shorter, in total.

I would file a couple of bug reports.

Eric