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

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

[Garreau, Alexandre]

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!).

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 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

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').

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.

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

[Eric Abrahamsen]

"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

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

[Garreau, Alexandre]

On 2018/10/28 at 19:16, Eric Abrahamsen wrote:
> "Garreau, Alexandre" <galex-713@galex-713.eu> writes:
>> 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.

I’m pretty sure el-search can be used so that to quickly check how is
it: I checked in all gnus, and the symbol `gnus-simplify-subject' is
only used in `message-reply'.  So unless you do strange stuff with
symbol names twiddling or other complex stuff (I believe you are
confident enough in not abusing such things in gnus) so to get it
without naming it, it is okay. ^^

> If I were you I would report two separate bugs, so that the first had
> a better chance of being accepted.

These are separate problems anyway.

>> 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.

Ah indeed, a dolist will do then:

#+BEGIN_SRC emacs-lisp
  (defun message-simplify-subject (subject &optional functions)
    "Return simplified SUBJECT"
    (dolist (fun (or functions message-simplify-subject-functions) subject)
      (setq subject (funcall fun subject))))
#+END_SRC

>> 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.

“there” where? sorry I don’t understand the relationship with the
preceding quoted text.

>> 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.

So should I have bugreported from the beginning?  Btw, do Gnus bugs
belong to bug-gnu-emacs mailing-list too? or is there something separate
about Gnus there too?  I’m sometimes confused about how much tight is
Gnus to Emacs.

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

[Eric Abrahamsen]

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

> On 2018/10/28 at 19:16, Eric Abrahamsen wrote:
>> "Garreau, Alexandre" <galex-713@galex-713.eu> writes:
>>> 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.
>
> I’m pretty sure el-search can be used so that to quickly check how is
> it: I checked in all gnus, and the symbol `gnus-simplify-subject' is
> only used in `message-reply'.  So unless you do strange stuff with
> symbol names twiddling or other complex stuff (I believe you are
> confident enough in not abusing such things in gnus) so to get it
> without naming it, it is okay. ^^

I'm convinced!

>> If I were you I would report two separate bugs, so that the first had
>> a better chance of being accepted.
>
> These are separate problems anyway.

Right.


[...]

>>> 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.
>
> “there” where? sorry I don’t understand the relationship with the
> preceding quoted text.

Sorry, that wasn't clear -- I just meant that `message-simplify-subject'
currently does a few extra checks (that
`message-subject-trailing-was-query' and `gnus-list-identifiers' are
non-nil), but that the first check is already redundant, and the second
can be made redundant by your earlier suggestion.

>>> 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.
>
> So should I have bugreported from the beginning? Btw, do Gnus bugs
> belong to bug-gnu-emacs mailing-list too? or is there something separate
> about Gnus there too? I’m sometimes confused about how much tight is
> Gnus to Emacs.

This sort of very specific suggestion could have gone in a bug report to
begin with, yes, though it doesn't matter too much. Gnus bugs are
reported along with Emacs bugs. You can also use `gnus-bug' to do the
report, in which case the bug will also be reported in the "Gnus
package", and you can see them here:

https://debbugs.gnu.org/cgi/pkgreport.cgi?package=gnus

But tbh I don't know if that's the right thing to do, since Gnus isn't
its own package anymore. It used to be, but is no longer, hence the
confusion.

Eric

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

[Garreau, Alexandre]

On 2018/10/29 at 10:17, Eric Abrahamsen wrote:
> "Garreau, Alexandre" <galex-713@galex-713.eu> writes:
>> On 2018/10/28 at 19:16, Eric Abrahamsen wrote:
>>> If I were you I would report two separate bugs, so that the first had
>>> a better chance of being accepted.
>>
>> These are separate problems anyway.
>
> Right.

Okay then:

>>> I would file a couple of bug reports.

As I still didn’t see them arrive on bug-gnu-emacs, I guess you didn’t
yet (if this was what you were suggesting): I was going to ask “may I
then?” but as this might cause unnecessary additional delay, I’m going
to try right now.

I wished I knew to make patches (git illiteracy doesn’t help).

>> So should I have bugreported from the beginning? Btw, do Gnus bugs
>> belong to bug-gnu-emacs mailing-list too? or is there something separate
>> about Gnus there too? I’m sometimes confused about how much tight is
>> Gnus to Emacs.
>
> This sort of very specific suggestion could have gone in a bug report to
> begin with, yes, though it doesn't matter too much. Gnus bugs are
> reported along with Emacs bugs. You can also use `gnus-bug' to do the
> report,

Coincidentally, today while searching with el-search around emacs’
source, I was looking at /usr/share/emacs/25.1/etc/ and did re-read
gnus-tut.txt, and found `gnus-bug' mentioned there.

> in which case the bug will also be reported in the "Gnus package", and
> you can see them here:
>
> https://debbugs.gnu.org/cgi/pkgreport.cgi?package=gnus

> But tbh I don't know if that's the right thing to do, since Gnus isn't
> its own package anymore. It used to be, but is no longer, hence the
> confusion.

Because it is now part of emacs?  Yet it is, like org (except unlike
org, it isn’t duplicated into elpa (maybe because it is older and not
supporting older emacsen?)), afaik, a subpackage of emacs (does
debbugs.gnu can understand this notion maybe?  that everything being
tagged gnus should be considered as emacs?  maybe the same could be done
with org? would allow more fine-grained filtering), with different
(officious) maintainers, different mailing-lists, and such.

`gnus-bug' bug? [Was: Re: message-simplify-subject too coupled with reply (and not extensible)]

[Garreau, Alexandre]

On 2018-10-29 at 10:17, Eric Abrahamsen wrote:
> This sort of very specific suggestion could have gone in a bug report to
> begin with, yes, though it doesn't matter too much. Gnus bugs are
> reported along with Emacs bugs. You can also use `gnus-bug' to do the
> report, in which case the bug will also be reported in the "Gnus
> package", and you can see them here:
>
> https://debbugs.gnu.org/cgi/pkgreport.cgi?package=gnus
>
> But tbh I don't know if that's the right thing to do, since Gnus isn't
> its own package anymore. It used to be, but is no longer, hence the
> confusion.

I mistakenly thought it would tag everything “gnus” as “emacs” too, as
all “gnus” bug here are also tagged “emacs”: how were most of those
reported?

On 1995-02-24 at 12:40, ding wrote:
> If you want to report a bug, please type `M-x gnus-bug'.  This will
> give me a precise overview of your Gnus and Emacs version numbers,
> along with a look at all Gnus variables you have changed.

You were unfortunately right: `gnus-bug' doesn’t tag as “emacs” (maybe I
should have added “, emacs” to “X-Debbugs-Package”?), doesn’t send on
`bug-gnu-emacs' (adding it to To maybe? maybe it would have tagged it as
“emacs”? but would modifying “X-Debbugs-Package” do something in this
reguard?), and doesn’t include all the extra informations that
`report-emacs-bug' reports, it doesn’t even include “all Gnus variable
[I] have changed” (which would be a pretty handy feature (thought
exceptionally not in the current situation), since how Gnus is dependent
of this and how many things each user might change), as
org-submit-bug-report or TeX-submit-bug-report do.

To me, that seems a bug in `gnus-bug': why doesn’t it do everything of
that?

More importantly: when have the feature of specifying gnus variables
removed?

Is it possible to tag it afterwards as “emacs” so it’s seen and better
archived?

Re: `gnus-bug' bug? [

[Eric Abrahamsen]

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

> On 2018-10-29 at 10:17, Eric Abrahamsen wrote:
>> This sort of very specific suggestion could have gone in a bug report to
>> begin with, yes, though it doesn't matter too much. Gnus bugs are
>> reported along with Emacs bugs. You can also use `gnus-bug' to do the
>> report, in which case the bug will also be reported in the "Gnus
>> package", and you can see them here:
>>
>> https://debbugs.gnu.org/cgi/pkgreport.cgi?package=gnus
>>
>> But tbh I don't know if that's the right thing to do, since Gnus isn't
>> its own package anymore. It used to be, but is no longer, hence the
>> confusion.
>
> I mistakenly thought it would tag everything “gnus” as “emacs” too, as
> all “gnus” bug here are also tagged “emacs”: how were most of those
> reported?

Hmm, when I run `gnus-bug', it automatically adds this header to the
outgoing message:

X-Debbugs-Package: emacs,gnus 

Which correctly tags the bug report with both headers. It looks like
this was added in last year, if you're not using a recent Emacs, maybe
that's not happening?

> On 1995-02-24 at 12:40, ding wrote:
>> If you want to report a bug, please type `M-x gnus-bug'.  This will
>> give me a precise overview of your Gnus and Emacs version numbers,
>> along with a look at all Gnus variables you have changed.

Where did you find this?! It might have behaved this way in 1995, but it
certainly doesn't now, and I don't know when the changed-Gnus-variables
thing was removed.

Anyway, the correct debbugs packages are set for me here...

Re: `gnus-bug' bug?

[Garreau, Alexandre]

On 2018-10-31 at 20:49, Michael Albinus wrote:
> Noam Postavsky <npostavs@gmail.com> writes:
>>> So first, dear GNU debbugs people, would it be currently possible
>>> for “gnus” bugs to be automatically tagged “emacs”?  would it be
>>> hard to hack debbugs to do so (so to deal with such “subpackages”)?
>>> Or should “gnus” package be removed?
>>
>> I think the "gnus" package should be removed. It was discussed a bit
>> on Bug#20670 (not otherwise related):
>>
>> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=20670#17
>
> I'm not sure. "gnus" is used as second package beside "emacs", so it is
> simple to filter for gnus bugs in debbugs. A gnus bug report, at least
> when calling "M-x gnus-bug", adds the header "X-Debbugs-Package: emacs,gnus",
> which sounds OK to me. This was changed by Lars on Feb 7 2017, so I
> guess all Emacs versions since 26.1 behave so.

So they’re not obsolete anymore? Cool, for the same reasons mentioned
here!

I’m directing this mail to Lars to ask him how’s that evolving in the
end, if `gnus-bug' is going to be kept and possibly improved (again?)
upon.

I mean, `org-mode' is not even (yet?) a debbugs package per se, and yet
have (too) its own mailing-list (though it’s GNU) and its own
`org-submit-bug-report', too… except `org-submit-bug-report' submit also
changed variables list, for debugging purpose, while `gnus-bug'… but
then, for it to be perfect maybe once more:

On 2018/10/30 at 14h33, Eric Abrahamsen wrote:
> "Garreau, Alexandre" <galex-713@galex-713.eu> writes:
>> On 2018-10-29 at 10:17, Eric Abrahamsen wrote:
>>> This sort of very specific suggestion could have gone in a bug report to
>>> begin with, yes, though it doesn't matter too much. Gnus bugs are
>>> reported along with Emacs bugs. You can also use `gnus-bug' to do the
>>> report, in which case the bug will also be reported in the "Gnus
>>> package", and you can see them here:
>>>
>>> https://debbugs.gnu.org/cgi/pkgreport.cgi?package=gnus
>>>
>>> But tbh I don't know if that's the right thing to do, since Gnus isn't
>>> its own package anymore. It used to be, but is no longer, hence the
>>> confusion.
>>
>> I mistakenly thought it would tag everything “gnus” as “emacs” too, as
>> all “gnus” bug here are also tagged “emacs”: how were most of those
>> reported?
>
> Hmm, when I run `gnus-bug', it automatically adds this header to the
> outgoing message:
>
> X-Debbugs-Package: emacs,gnus 
>
> Which correctly tags the bug report with both headers. It looks like
> this was added in last year,

So everybody agrees as I heard this twice.

> if you're not using a recent Emacs, maybe that's not happening?

Yes.

>> On 1995-02-24 at 12:40, ding wrote:
>>> If you want to report a bug, please type `M-x gnus-bug'.  This will
>>> give me a precise overview of your Gnus and Emacs version numbers,
>>> along with a look at all Gnus variables you have changed.
>
> Where did you find this?! It might have behaved this way in 1995, but it
> certainly doesn't now, and I don't know when the changed-Gnus-variables
> thing was removed.

So why doesn’t it do that anymore?  This is the only one detail that
makes `gnus-bug' looks as not totally superior and more specific than
`report-emacs-bug'.

Two successive patches about the same function [Was: Re: message-simplify-subject too coupled with reply (and not extensible)]

[Garreau, Alexandre]

On 2018-10-28 at 19:16, Eric Abrahamsen wrote:
> 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’ve a question about patches: a patch mention the original version, as
long as its context, so if I end trying to submit a patch for the same
function, the second will either base on the version patched by the
first, either be based on original function before first patch, and then
won’t it have problem applying after first has been applied?

In our case, the second patch is about simplifying, improving and
factorizing `gnus-simplify-subject', and arrives after the one stripping
the “concat "Re: "”, but still having it in the version of the function
it patches.

Or maybe should I report without a patch tentative? on another hand,
with what I did it’s not that long, and I suppose at worse it’s possible
to ignore the (then incorrect (or rather outdated?)) patch…

Re: Two successive patches about the same function [

[Eric Abrahamsen]

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

> On 2018-10-28 at 19:16, Eric Abrahamsen wrote:
>> 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’ve a question about patches: a patch mention the original version, as
> long as its context, so if I end trying to submit a patch for the same
> function, the second will either base on the version patched by the
> first, either be based on original function before first patch, and then
> won’t it have problem applying after first has been applied?
>
> In our case, the second patch is about simplifying, improving and
> factorizing `gnus-simplify-subject', and arrives after the one stripping
> the “concat "Re: "”, but still having it in the version of the function
> it patches.
>
> Or maybe should I report without a patch tentative? on another hand,
> with what I did it’s not that long, and I suppose at worse it’s possible
> to ignore the (then incorrect (or rather outdated?)) patch…

Yes, because both patches touch the same bit of code, one will have to
explicitly come before the other. I would definitely submit patches with
your bug reports, and simply mention in the second report that it's
meant to be applied after the first.