[Top][All Lists]

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

Re: track-exclude some nick

From: J.P.
Subject: Re: track-exclude some nick
Date: Fri, 01 Oct 2021 05:21:27 -0700
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

Danilo Alves <daniloalves@riseup.net> writes:

> Hi!
> How can I track-exclude a specific nick? I wanna see their messages in
> the chat, so `/IGNORE <nick>' is not an option, I just don't want to
> track them. This could be useful to exclude some bots.
> Thanks,
> Danilo.

Among the more obvious approaches is the attached (untried) example.
However, before going this (or any) route, what about pausing first to
reexamine whether broad options like `erc-track-exclude' that affect all
ERC sessions are really adequate for today's IRC user?

The traditional approach for achieving session-specific granularity
seems to be the usual "find hook (or hack) to set buffer-local value,"
which implies reading source code. But this approach may not prove
particularly conducive to rejuvenating the Emacs userbase, to whatever
extent ERC's role as a conduit in that game is anything other than
lofty thinking.

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

By this I mean one or more context-oriented "meta options" allowing
users to specify patterns for session IDs and targets alongside whatever
else, like userhosts or IRC commands, with ERC let-binding their
associated "embedded" options at runtime. According to my deeply flawed
magical thinking, this would allow us to retrofit existing options with
session awareness wholesale. A crude, minimal usage example might be:

  (setq erc-context-matchers
        '((:network "OFTC" :target "#chan" :sender "^some-bot!"
                    (erc-track-exclude-types "JOIN" "PART"))))

Anyway, I think this session-context stuff is worth discussing at some
point, but hopefully not until fundamental issues like sessions
themselves (and as a consequence, buffer naming) are safely in the
rearview. Thanks.

Attachment: 0001-Optionally-exclude-nicks-from-tracking-in-ERC.patch
Description: Text Data

reply via email to

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