bug-gnu-emacs
[Top][All Lists]
Advanced

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

bug#51082: [PATCH] erc-prompt: support substitution patterns "%target" a


From: J.P.
Subject: bug#51082: [PATCH] erc-prompt: support substitution patterns "%target" and "%network"
Date: Sat, 09 Oct 2021 01:03:20 -0700
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.60 (gnu/linux)

Amin Bandali <bandali@gnu.org> writes:

> How do you feel about adding those as well?  Maybe something like:
>
>   %m or %modes: channel modes (do we want to support user modes too?)
>   %n or %nick: current nick
>   %N or %network: network name
>   %s or %server: server name/address
>   %t or %target: target
>
> Other ones I'd find useful would be %o, %v, etc., corresponding to the
> 'op' or 'voice' status of the user and so on (see `erc-format-@nick').

This may be my lack of a forebrain talking, but I thought the prompt
only gets updated after sending input.

  (setq erc-prompt (lambda () (format-time-string "[%T.%3N]>")))

IOW, I don't think it's currently driven by response handlers, so it
won't react right away after a nick change or upon receiving a MODE or a
221. The mode line, OTOH, is updated more or less constantly (though
possibly too often). And as far as user modes go, ERC doesn't currently
remember them (AFAIK), a point I rather poorly tried to raise here:

  https://lists.gnu.org/archive/html/emacs-erc/2021-10/msg00012.html

But with Stefan's current changes, none of this really matters (right?)
because target and network are effectively read-only once set (ignoring
a few edge cases).

> Also, for v2 please add an accompanying etc/ERC-NEWS entry for the
> change.

As an aside, one pleasant effect of having our own NEWS file is the
absence of constant merge conflicts on account of etc/NEWS' popularity.
For example, when trying to integrate older #48598 stuff with Olivier's
last services patch (in the months leading up to its installation), I
got annoyed enough by all the repeated manual merging of etc/NEWS that I
ended up replacing his changes to that file with a FIXME/IOU in his
commit message. But I guess the days of resorting to such shenanigans
are over!

>> +(defun erc-prompt--subsitutions (prompt)
>> +  "Make \"%target\" substitutions in PROMPT.
>
> Per (info "(elisp) Coding Conventions") I believe the name may better
> be `erc--prompt-substitutions'?

Fearing similar feedback, I recently mass-renamed my `erc-foo--' stuff
in #48598 to `erc--foo-'. But I was wondering if an exception couldn't
be made for seasoned subprojects like ERC, with its longish primary
library file housing groups of related items sharing longer, more
qualified prefixes (than what's offered by the file/feature). I tried
searching the help list for this a while back but failed to find
anything.

> Why leave "%modes" commented out?  Would using
> `erc-format-channel-modes' not work here?

If we do end up redrawing the prompt more often, which uncommenting this
seems to imply, would it not make sense to also address the occasional
double vision "ERC> ERC>" thing? Just thought I'd mention it in case
anyone already has a patch handy. Otherwise, forget I said anything,
especially if this doesn't ring a bell. We'll just deal with it later,
hopefully after facing down some of ERC's scarier demons.





reply via email to

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