Re: bug#69597: 29.2; ERC 5.6-git: Add a new customizable variable controlling how Erc displays spoilers

>I typically remove all the lisp/erc/*.elc files

Thanks, this is what I missed. Deleting all *.elc files solves the
warning issue.

>So I adjusted the message to conform to this requirement. If the
>attached changes look all right to you, then I'll install them (or
>something similar) in the coming days.

Much appreciated. Didn't notice/expect a client-side hook running when
committing.

That said, I'd like to +1 the changeset and confirm that the proposed
changes apply cleanly, and yield the desired result. I tested inputs
of the form ^CX,X<text>^C on a temporary private channel – spoilers
are formatted and revealed as intended, and no regressions were
observed. Very nice. Would be a neat addition/fix for the next Erc
release.

Cheers,
FM

Am Sa., 9. März 2024 um 05:43 Uhr schrieb J.P. <[email protected]>:
>
> Fadi Moukayed <[email protected]> writes:
>
> > The only issue I noticed after applying the patches, is that the
> > following warning is emitted on the *Messages* buffer – (Note that I
> > have native compilation enabled):
> >
> >> ⛔ Warning (comp): erc-button.el:532:4: Warning: the function
> >> ‘erc--restore-important-text-props’ is not known to be defined.
> >
> > I assume this is a compilation order issue? Note that this only
> > happens with a clean ELN cache (The following Emacs loads are fine),
> > so not sure how significant it is.
>
> Hm, unless I messed something up (definitely possible), that shouldn't
> happen . For ERC, I typically remove all the lisp/erc/*.elc files after
> every change and before rerunning Make, regardless of whether native
> comp is enabled (though removing native-lisp/30.0.50-deadbeef/*.eln
> isn't usually necessary, AFAICT). Sometimes, though, I also have to
> remove lisp/loaddefs.* and others. In case you weren't aware, there are
> recipes for regenerating various autoloads and Custom business in
> lisp/Makefile, but I usually just delete all stale assets completely.
>
> >>Happy to explain whatever doesn't make sense
> >
> > One question regarding "FIXME use a region instead of point-min/max"
> > in patch #0002, is there a reason why (region-beginning) /
> > (region-end) is indeed not used instead? Just mentioning that because
> > IIRC, point-{min,max} is a range over the entire (narrowed) buffer,
> > including the (buttonized) nick, message text, possible timestamp (if
> > activated) as well. I checked the properties on the whole message line
> > while testing and it doesn't seem to have any negative side-effects,
> > aside from the fact that it operates on more text than it has to – I
> > believe it need only be applied to the message text.
>
> Unfortunately, insertion-hook members lack a means for detecting message
> boundaries unequivocally, although they can obviously keep track of
> their own modifications and make assertions accordingly. So I agree that
> allowing the caller to specify BEG and END in cases where they're
> already known makes sense. For example, if they've already scanned for
> the end of the speaker name to accomplish some other task or happen to
> know the start of the right stamp, it's worth passing that knowledge
> along. But computing a sub-region specially, beforehand, just to call
> this function is likely less efficient (not that you were suggesting
> that). And, of course, accepting BEG/END parameters make it easier to
> protect areas of the exposed buffer from props restoration, if ever
> there's a need.
>
> >> > From 06e008d1de8a85c9e6b9a5a83f5ec5aefeb446c3 Mon Sep 17 00:00:00 2001
> >> > From: "F. Moukayed" <[email protected]>
> >> > Date: Fri, 8 Mar 2024 08:39:03 +0000
> >> > Subject: [PATCH] * lisp/erc/erc-goodies.el: redefine & rework
> >> >  `erc-spoilers-face' to indicate revealed text
>
> This is news to me, but apparently there's a Git hook that complains
> about overlong subject lines. After running git-am(1) to apply your
> latest patch, I saw:
>
>   Line longer than 78 characters in commit message
>   Commit aborted; please see the file CONTRIBUTE
>
> So I adjusted the message to conform to this requirement. If the
> attached changes look all right to you, then I'll install them (or
> something similar) in the coming days.
>
> Thanks,
> J.P.