[Top][All Lists]

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

bug#29533: [CLOSED] Re: bug#29533: Fwd: [Feature Request] ERC: let erc-j

From: address@hidden
Subject: bug#29533: [CLOSED] Re: bug#29533: Fwd: [Feature Request] ERC: let erc-join-channel support to select channels from history or a defined list
Date: Mon, 3 Aug 2020 21:47:45 +0800

Hi, Lars, thanks for reviewing my patch. I almost forgot what my patch did since
I send it a long time ago. I read my old email and idea. And I have an
conclusion that this patch seems not very useful for most users. So I give up
merging this patch into ERC. I'm so sorry for my impulsive decision that wasted your time.

[stardiviner]           <Hack this world!>      GPG key ID: 47C32433
IRC(freeenode): stardiviner                     Twitter:  @numbchild
Key fingerprint = 9BAA 92BC CDDD B9EF 3B36  CB99 B8C4 B8E5 47C3 2433
Blog: http://stardiviner.github.io/

On Mon, Aug 3, 2020 at 4:52 PM Lars Ingebrigtsen <larsi@gnus.org> wrote:
stardiviner <numbchild@gmail.com> writes:

> No need to be announced in etc/NEWS. It's still original keybinding. And not a
> big difference.

It needs a NEWS entry (it's a new user-level variable), and it needs
documentation in the erc manual.

But I don't really understand the patch.

> * lisp/erc/erc.el (erc-mode-map): Add an option to store your frequently
> joined channels. And replace original `erc-join-channel' with
> `erc-join-channel-select'.


> +(defcustom erc-join-channels-alist nil
> +  "Alist of channels to select when you join channels.
> +
> +Every element in the alist has the form (SERVER . CHANNELS).
> +SERVER is a regexp matching the server, and channels is the
> +list of channels to join.
> +
> +If the channel(s) require channel keys for joining, the passwords
> +are found via auth-source.  For instance, if you use ~/.authinfo
> +as your auth-source backend, then put something like the
> +following in that file:
> +
> +machine irc.example.net login \"#fsf\" password sEcReT

I'm not sure why this is documented here -- this is what erc does in
general, isn't it?

> +Customize this variable to set the value for your first connect.
> +Once you are connected and join and part channels, this alist
> +keeps track of what channels you are on, and will join them
> +again when you get disconnected.

Did you miss including this bit in the patch?  There's no logic for
keeping the variable up-to-date in the code you sent, neither for
re-joining after a disconnect.

> +(setq erc-join-channels-alist '(("*.freenode.net" "#emacs" "#org-mode")))
> +

Debugging left behind?

> +(defun erc-join-channel-select ()
> +  "Select a channel to join from alist of channels to."
> +  (interactive)
> +  (erc-join-channel
> +   (completing-read
> +    "Select a channel: "
> +    (cdr (assoc
> +          (completing-read "Select a server: "
> +                           (mapcar 'car erc-join-channels-alist))
> +          erc-join-channels-alist)))))

Should the server default to the current one?  And this code should go
into the `interactive' part, since you're prompting the user.

Also, the original erc-join-channel has this logic:

(defun erc-join-channel (channel &optional key)
  "Join CHANNEL.

If `point' is at the beginning of a channel name, use that as default."
    (let ((chnl (if (looking-at "\\([&#+!][^ \n]+\\)") (match-string 1) ""))
          (table (when (erc-server-buffer-live-p)
                   (set-buffer (process-buffer erc-server-process))
      (completing-read "Join channel: " table nil nil nil nil chnl))

Which should looks very useful, and should be replicated in the new
command.  Also:

    (when (or current-prefix-arg erc-prompt-for-channel-key)
      (read-from-minibuffer "Channel key (RET for none): " nil))))

should also be replicated, and at that point, perhaps the
erc-join-channel-select command isn't that useful -- perhaps
erc-join-channel should instead just be amended to add the channels from
-alist to the table the user is prompted for.

(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

reply via email to

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