Re: track-exclude some nick

[J.P.]

Danilo Alves <daniloalves@riseup.net> writes:

> Thanks for the answer and proposed patch, but unfortunately I couldn't
> make it work.
>
> First I would like to point out that I'm not some experienced Emacs
> user, so I'll describe what I did to apply and try the patch on Debian
> stable, hoping that I didn't messed up.

No worries. You may well be better acquainted with many areas of Emacs
than I. In the likeliest scenario, there's nothing you could have done
because it was something shoddy on my end. But let's take a look.

> I created a `lisp/erc' directory in my `~/.emacs.d' and copied the
> contents of `/usr/share/emacs/27.1/lisp/erc/' there.
>
> Gunzipped `erc-track.el.gz' and applied the patch.

Did you remember to remove lisp/erc/erc-track.elc?

> Started emacs with:
>
> emacs -L ~/.emacs.d/lisp/erc/
>
> But "some-bot" was still triggering notifications.

For good measure, can you

  (require 'erc-track)
  (cl-assert (fboundp 'erc-track--exclude-nick-p))

after startup but before connecting? If that passes but the option still
fails, can you

  (trace-function-background #'erc-track--exclude-type-p)
  (trace-function-background #'erc-track--exclude-nick-p)
  (trace-function-background #'erc-track--modified-channels)
  (erc-toggle-debug-irc-protocol)

before connecting; and after the session ends, upload the contents of

  #<buffer *trace-output*>
  #<buffer *erc-protocol*>

somewhere (perhaps redacting passwords and such first)? (Yeah, sorry,
this stage is kind of a hassle; but in the future I'd like to get a
partially automated solution going.) And BTW, feel free to PM me a link
or drop one in #erc if you're not comfortable doing so on this list.

> Can't say much about ERC's role in rejuvenating the Emacs userbase, but
> I feel that getting involved with ERC to a point of submitting a patch
> is more easy. I don't have much practice reading source code, but I'm
> willing to improve that.

Fantastic! Please take over this patch if you're feeling up to it (and
can get it working).

>> So yeah, looking ahead, would it not make sense to seek out some
>> standard means of telling ERC about the context in which some option
>> should apply? Perhaps this is best solved with a mini expression
>> language, like the one Corwin's been championing. Or maybe something
>> dumber is worth considering as well...
>
> I'm curious, what mini expression language?

Sorry for talking past you a bit with this stuff and basically trying to
parlay your interest into a larger discussion. (That was rather rude.)
Here's some missing background...

The "mini expression language" is from a smarter/more flexible version
of `erc-hide-list' [1] currently being worked on (?) that allows for
specifying options specific to channels (and maybe nicks/networks?)
along with operators indicating how to merge them with global defaults.
(At least that was my flawed impression.)

And, unless I'm misremembering, the author of that package also
informally suggested that a similar approach could be applied to all of
ERC to address the age-old problem of reconciling defaults with user-
configured values. What I'm not clear on is to what extent this idea
also tackled resolving issues of scope (i.e., context naivete or global
vs. session-specific options), which is what I'm mainly interested in.

I should stress here that my "alternative" wasn't well fleshed out and
may not even be an alternative at all but rather something that could
live in tandem. Either way, there's plenty of room for further shedding
on this, but that should probably happen in a dedicated thread. Thanks.

[1] https://git.sr.ht/~mplscorwin/erc-hide-line