emacs-circe / circe Goto Github PK

I didn't see the ability to add notifications for keywords/nick mentions anywhere. If there is something there and I missed it, could you point me to it? If not, I'd like to take a stab at adding it, but I'm not sure where it would go. Is that something that belongs in tracking.el? This would be my first contribution to an elisp project, so I could use a tiny bit of guidance! 😄 Thanks in advance!

(By the way, I just started using Circe and I think it is really nice. Thank you for it!)

Circe uses mapc a lot. Now that dolist has been in Emacs for a long while, rework most code to use dolist instead of mapc wherever that improves readability.

I wonder if the nick change message can be shortened any, and reviewing circe-display-NICK, two questions occurred to me:

1. Do we really need to show the user's host mask for this type of message?
2. When you change your own nick, why is there one message format for the server buffer, but a different message format for channel buffers?

Discuss :)

retroj mentioned that the modules circe-color-nicksand circe-highlight-all-nicks have very similar functionality and likely should be merged into a single module.

As a bug, in circe-color-nicks the functions to enable/disable the module are written as if lui-pre-output-hook was buffer-local. It isn't.

In circe-nickserv-handler, preferred nick regaining happens after Nickserv identify confirmation. However, the only time you need to regain your registered nick is when you do not have it, and if you do not have it, Nickserv will not prompt you to identify. No identify confirmation, no preferred nick regain.

Just had a weird thing happen. I joined two channels of the same name in two networks. One was then called #foo<2>. So far, so expected. On a reconnect, Circe tried to join #foo<2> instead of #foo there. Needs some investigation on what's happening there - it should join the channel name, not the buffer name.

Emacs nowadays doesn't need a hack with a subprocess anymore. Implementing circe-dcc.el could be a fun exercise.

Commit 509a58c "lui-format: Support formatting options" (2012-10-13) broke Circe's ability to have function formats. Here is an example that worked prior to this patch:

(defun my-circe-format-say (keywords)
  (concat
   "<"
   (format "%-10s" (plist-get keywords 'nick))
   "> "
   (plist-get keywords 'body)))
(setq circe-format-say 'my-circe-format-say
      circe-format-self-say 'my-circe-format-say)

The failure happens as follows:

• circe-display-PRIVMSG calls circe-display with the format symbol 'circe-format-say
• circe-display passes this format symbol on to lui-format
• prior to the patch, lui-format would take (symbol-value format) to get the function, in this case 'my-circe-format-say, which it would then call.
• with the patch, lui-format only tests whether the symbol passed to it is a function, not whether the symbol-value of that symbol is a function. It ends up passing (symbol-value format) to lui-format-internal instead of calling it.

Sometimes, lui can get confused and lose the prompt. Apparently, there is some timing issue somewhere. Ideas on what might be causing this welcome.

When it happens, the following seems to fix it reliably:

M-: (lui-set-prompt circe-prompt-string)

It would be nice to have an interactive command that prompts for a circe command in the minibuffer and executes it. Its purpose would be to protect the user from accidentally sending command text to irc channels due to typos, unwittingly broadcasting sensitive information like passwords and ignore/fool settings to the world. A good name for the command might be circe-send-command and a good key bindings might be C-c /. (Note that that key binding is in a group intended for use by minor modes, but it is not prohibited to bind it in a major mode, and doesn't seem to be used by any common minor modes.)

It would be nice if the netsplit handler would show in the buffer who was cut in the netsplit. Since a netsplit is indicated by a series of QUITs with (*.net *.split) as the quit message over a period of possibly many seconds, the netsplit handler would need a mechanism to collect the names and report them after a delay. When the first quit comes in, it might say something like "netsplit in progress", then 30 seconds later, or however long, it would report the nicks that have disconnected so far, and continue every 30 seconds until an interval has passed with no disconnects.

When using the fool feature, the (recenter -1) call in lui-scroll-to-bottom can be off with recentering the line at the bottom of the buffer. Even manually calling (recenter -1) then will not move the last line to the bottom of the buffer.

I have not been able to figure out when exactly it would happen. If it breaks, it works again as soon as fools are shown, but breaks again when fools are hidden. It's very deterministic once it happens at all. It does not happen all the time when fool messages are hidden. It does not always happen when hidden fool's messages were scrolled into the buffer by hiding other fool messages. And it can solve itself once a number of messages have been added, even if more fool messages are in the window. It never happens when no fool messages are in the window.

I suspect a bad interaction of overlays that hide text and Emacs' recentering code. But no idea. Would love a reliable reproduction.

When circe-server-use-tls is true, circe-reconnect does not honor circe-server-max-reconnect-attempts. It does not attempt to reconnect at all. It would probably be best to attempt to reconnect after a short delay, rather than immediately.

Circe stores channel user information in a hash which is re-initialized on a NAMES response. This is also the canonical way to actually show a user list of a channel. This is somewhat problematic.

While useful to ensure that there is no desynchronization (e.g. after netsplits), Circe probably should NOT reinitialize the nick list on a NAMES list except for the first. Ideally, we keep a list of nicks from a NAMES separately from channel users and just synchronize the lists, i.e. make sure we actually have all nicks covered and have no excessive nicks.

The libraries (lui, tracking, lcs) need separate homepages on the wiki, and the URL in their respective files need adjusting accordingly.

The homepage should give a rough introduction and API documentation.

Emacs provides a new generic framework for completions using completion-at-point-functions. Circe/Lui should use that instead of incomplete.el.

Look at these compile errors and see if we can fix them without a problem:

build/circe.el:3773:1:Warning: the function `open-tls-stream' is not known to be defined.

build/lui.el:718:6:Warning: redraw-modeline' is an obsolete function (as of 24.3); useforce-mode-line-update' instead.

build/lui.el:1126:32:Warning: buffer-substring-filters' is an obsolete variable (as of 24.1); usefilter-buffer-substring-functions' instead.

build/lui.el:1193:1:Warning: the function `help-xref-interned' is not known to be defined.

Circe and the other packages should probably be in melpa, too.

https://github.com/milkypostman/melpa

Need to figure out how to do it exactly for Circe.

Circe uses overlays extensively, for example for time stamps or for identifying fool messages. Especially time stamps require them because that means time stamps are not copied by copy commands.

When Circe buffers grow large (500k+), they gain a lot of overlays. This causes Emacs to slow down. Simply removing the overlays speeds things up again.

Circe should implement time stamps using text properties instead of overlays. We should use filter-buffer-substring-functions to filter out time stamps. This function is new in Emacs 24, though (added 2010-05-02). There is an older way using `buffer-substring-filters' which was added in Emacs 22, but is obsolete now. We probably could use either, depending on which is available

Foolish talk can likely also be implemented using text properties instead of overlays. Would need some experimenting. But if it can, it should be backwards-compatible with Emacs 23.

This should solve most of the speed issues.

The fools list does not apply to actions by fools. That's peculiar, as a fool's actions are just as foolish if not more than what they say.

Also, a fool's actions can cause tracking to happen. This shouldn't happen.

(NB: retroj is working on a generic "apply color/property to line based on nick" interface, maybe this can be integrated?)

Hi! We have snapshot packages of circe in MELPA, but I see that the files here are actually split into 3 packages on Marmalade (circe, lui and tracking) in a way that is only defined in the Makefile.

Our circe package includes *.el, which isn't ideal, and I'd like to split our package up in the same way that you have. However, we have no way of determining the dependencies from your source files, so I'm going to have to remove the circe package from our repository completely.

Alternatively, perhaps you would consider checking in the appropriate *-pkg.el files, which would allow us to adjust our circe package accordingly, and also add MELPA packages for lui and tracking.

Cheers!

-Steve

Tracking shorten currently turns "#emacs" and "#emacs-circe" into "#emacs" and "#emacs-". We would like a better shortener that would turn those strings into "#e" and "#e-c".

el-get already has a Circe recipe, but it's pointing to the old address: https://github.com/dimitri/el-get

Should probably get updated.

Some IRC clients send /FOO directly to the server if they don't know the command. This used to be frowned upon because of spam issues, but some servers even rely on the behavior with their user messages. So we probably should do that, too.

circe-channel-users provides a way to attach information to nicks. The joinpartspam interface should use that, as opposed to implementing it itself.

ispell doesn't like numbers in words. Adding them to `ispell-buffer-session-localwords' is a Bad Idea.

lui should probably use `lui-flyspell-accept-word'.

`circe-channel-killed' does not track channel state, and will always send a PART command to the ircd, usually evoking a "you're not on that channel" error from the ircd.

Lui's scroll-to-bottom function slows down scrolling in Emacs buffers, especially big ones. (thanks to taylanub for finding the source of the problem!)

This is a tricky one. The correct solution would be for Emacs to support this in its own scrolling code.

Compiling lui-logging.el produced the following warning:

lui-logging.el:151:33:Warning: variable assignment to nonvariable `(gethash
    file-name lui-pending-logs)'

The offending line is this:

(push text (gethash file-name lui-pending-logs))

The push' provided by the cl library supports generalized variables, but emacs's builtinpush' does not, and lui-logging.el does not require 'cl
at compile-time. For anybody who had loaded 'cl at runtime, this call
would work correctly, but loading 'cl at runtime is contraindicated by
emacs policy. There is no compelling reason here to use cl instead of
plain elisp, so this line should be rewritten to not use generalized
variables.

The Circe header files reference the GPLv2. Probably should be GPLv3. Everyone can decide that for their own modules, of course.

tracking-mode should add the tracking-mode-line-buffers indicator directly to mode-line-format right before mode-line-modes if tracking-position is before-modes, and to the beginning of mode-line-misc-info if tracking-position is after-modes.

Background: A user had removed the mode-line-modes entry from their mode line, so couldn't see tracking info.

Would be good if we started writing ERT tests for Circe

Yesterday, I saw a strange thing with Circe. A user typed a message that ended with a single underlined comma (^,^). Somehow, the resulting face leaked onto the next lines, including the Circe prompt.

I have not been able to reproduce this.

When you hit C-c C-i to toggle fools, it does not always update immediately, but might wait for a redraw event. This is likely related to buffer-invisibility-spec being updated, but no redraw event being sent, in combination with text properties (overlays seem to have no such problem). Would need some fixing I guess.

Probably some reproduction first.

What exactly do we need to make "a release"? How do releases in Emacs happen these days?

Comments very welcome!

Both extensions hook into the global value of lui-pre-output-hook, which is ok, but then do not make sure they don't cause an error in non-Circe buffers. They should check if the buffer they're in is a Circe buffer, and if not, simply do nothing.

Currently, lui-logging disables the whole logging process when the logging buffer is killed. This is not sensible, as the logging process is global, not buffer-local.

Instead of starting the timer in enable-lui-logging, the lui-logging function itself should start the timer if none is running yet. Then, lui-logging-flush should cancel the timer. This will avoid this perturbation weirdness, too.

Lui's new completion code fails with cycle completion.

The problem is that Circe completes nicks with a space at the end. The completion code in Emacs calls the same completion function (lui-completion-at-point) again to see if it returns the same "begin" marker. If it does not, a new completion cycle is started.

The solution is to have lui-completion-at-point skip backwards over spaces, too, if completions-cycling. Or something.

Test with (setq completion-cycle-threshold t) to always cycle.

NB: There's a way to sort completions, e.g. by last active time. See completion-metadata. We should use that.

With revision 110643, Emacs trunk got a fix to the completion bug that's fixed in circe-fixes.el. That file should get the new Emacs behavior, and also check for the existence of that bugfix before installing itself.

Circe should send out periodical PING messages to the server to test for broken connections. The PONG answer should be ignored.

Flyspell knows flyspell-generic-check-word-preficate and flyspell-mode-predicate which should be used to not check nicks or commands.

Update version tags and release Circe

A number of modern IRC clients implement a paste protection in which the client does not send data entered immediately, but only after a small delay. If a lot of data shows up during that delay – usually due to an accidental paste – the client does not send the data but requires the user to confirm sending it. Care must be taken to not ask the user directly, as the accidental paste will abort the question.

If you assign a foreground color to circe-originator-face, it will be overridden in your own messages by the color of circe-my-message-face. Also affects faces applied via the special-display mechanism. circe-originator-face should have a higher priority than these though, because it is for a more specific part of the message.

Default port for TLS connection should be 6697. Reference: http://blog.freenode.net/2011/02/port-6697-irc-via-tlsssl/

Circe has two types or levels of ignore, namely IGNORE and FOOL. It would be good if this could be unified, and maybe made more powerful at the same time.

But how?

Irssi's ignore feature is quite comprehensive. From http://blog.jorgenschaefer.de/2012/10/assessing-threat-of-cyber-terrorism.html

10.1 Manual ignoring

    Irssi's ignoring options should be enough for everyone :)

    /IGNORE [-regexp | -word] [-pattern <pattern>] [-replies] [-except]
            [-channels <channel>] <mask> <levels> <^levels>

        -regexp: <pattern> is a regular expression
        -word: <pattern> must match to full words
        -pattern: <pattern> must match to the message's text
        -replies: Ignore replies to nick in channels. For example
                  "/IGNORE -replies *!*@*.fi PUBLIC" ignores everyone
              from Finland, but also anyone sending message
              "tofinnishnick: blahblah".
        -except: *DON'T* ignore
        -channels: Ignore only in channels
        <mask>: Either a nick mask or list of channels
        <levels>: List of levels to ignore
        <^levels>: List of levels to NOT ignore
                   (/ignore -except nick notices = /ignore nick ^notices)

    /UNIGNORE <ref#> | <mask>

    /IGNORE without any arguments displays list of ignores.

    The best match always wins, so you can have:

        /IGNORE * CTCPS
        /IGNORE -except *!*@host.org CTCPS

10.2 Automatic ignoring

    Irssi can automatically set ignores for people who flood you.
    Currently you can autoignore MSGS, NOTICES, CTCPS and PUBLIC.
    Actions are placed to either MSGS or PUBLIC. See section 3.3 for
    definition of the flood.

    /SET autoignore_time <seconds> specifies how long to ignore the
    user.

    /SET autoignore_levels <levels> specifies what levels to ignore
    automatically, default is to ignore only CTCPS.

The Re-join message lacks the "(user@host)" part that's common for the other similar messages. It would be good if we could make that the default, but extract the format string into a format variable so users can customize this.

Once we had our first release, we should maintain a NEWS file or wiki page describing user-visible changes since the last release. I can see points for both the wiki and a file in the distribution.

Pro file: Can be updated in the same commit as the change that introduces the user-visible change. Also, it's The Way It Has Always Been Done.

Con file: Difficult to link to on a user's system, especially considering package.el

Pro wiki: Doesn't depend on commits. Especially making it more readable, fixing typos, or even just adding a forgotten entry all cause spurious edits. Wiki pages are accessible via a globally unique URL.

Con wiki: The information doesn't come with the distribution.

Opinions?

This page needs updating with the changes since the last update.

The new command circe-reconnect-all should run circe-reconnect in all active server buffers.