Cédric Chépied | 30 Jul 08:52 2014

erc-format-nick and znc


I'm using erc to connect to my znc server. I now have an error each time I need
to display buffer playback:

Debugger entered--Lisp error: (wrong-type-argument arrayp nil)
  aref(nil 0)
  (memq (aref user 0) cl-struct-erc-server-user-tags)
  (and (memq (aref user 0) cl-struct-erc-server-user-tags))
  (or (and (memq (aref user 0) cl-struct-erc-server-user-tags)) (error "%s accessing a non-%s" (quote
erc-server-user-nickname) (quote erc-server-user)))
  (progn (or (and (memq (aref user 0) cl-struct-erc-server-user-tags)) (error "%s accessing a non-%s"
(quote erc-server-user-nickname) (quote erc-server-user))) (aref user 1))
  (let ((nick (progn (or (and (memq (aref user 0) cl-struct-erc-server-user-tags)) (error "%s accessing a
non-%s" (quote erc-server-user-nickname) (quote erc-server-user))) (aref user 1)))) (concat
(erc-propertize (erc-get-user-mode-prefix nick) (quote face) (quote erc-nick-prefix-face)) nick))
  erc-format-nick(nil nil)
  erc-server-PRIVMSG(#<process erc-localhost-2121> [cl-struct-erc-response ":***!znc <at> znc.in
PRIVMSG #gnaaaapouet :Buffer Playback..." "***!znc <at> znc.in" "PRIVMSG" ("#gnaaaapouet" "Buffer
Playback...") "Buffer Playback..."])
  run-hook-with-args-until-success(erc-server-PRIVMSG #<process erc-localhost-2121>
[cl-struct-erc-response ":***!znc <at> znc.in PRIVMSG #gnaaaapouet :Buffer Playback..."
"***!znc <at> znc.in" "PRIVMSG" ("#gnaaaapouet" "Buffer Playback...") "Buffer Playback..."])
  erc-call-hooks(#<process erc-localhost-2121> [cl-struct-erc-response ":***!znc <at> znc.in PRIVMSG
#gnaaaapouet :Buffer Playback..." "***!znc <at> znc.in" "PRIVMSG" ("#gnaaaapouet" "Buffer
Playback...") "Buffer Playback..."])
  erc-handle-parsed-server-response(#<process erc-localhost-2121> [cl-struct-erc-response
":***!znc <at> znc.in PRIVMSG #gnaaaapouet :Buffer Playback..." "***!znc <at> znc.in" "PRIVMSG"
("#gnaaaapouet" "Buffer Playback...") "Buffer Playback..."])
  erc-parse-server-response(#<process erc-localhost-2121> ":***!znc <at> znc.in PRIVMSG #gnaaaapouet
(Continue reading)

Bastien | 28 Jul 19:32 2014

[PATCH] Filter list-buffers by a regexp (interactively)

The patch below allows to use C-u C-u C-x C-b to interactively enter
a regular expression to only list buffers with a matching name.

The need came up on Org-mode when people have many agenda buffers and
want to only list those.

Any comment and/or improvement appreciated, thanks!


Mario Lang | 28 Jul 14:56 2014

A fast native `mapcan'


The typical `mapcan' emulation in Emacs Lisp

  (apply 'nconc (mapcar fn seq))

is wasting GC time.  This is because `mapcar'
has to build up a full list before it can pass it to `apply',
and GC has to collect this memory later on, although it was never
really "used" in Lisp world for anything other then passing args,
creating unnecessary work for GC.

`cl-mapcan' uses this emulation, plus it implements
the multi-sequence behaviour from CL.  We do not
have any callers that rely on the multi-sequence behaviour.

So I was thinking: Why not add a native `mapcan'?  The native
impelmentation is approx. twice as fast, because it can pass
the list of results from Fmapcar to Fnconc directly in C world,
using an ALLOCA'ed memory area.  So GC does not have
to deal with cleaning up, which is the reason for the speed up.

I have written an impelementation that works very nicely for me.
Of course I had to remove the alias from `mapcan' to `cl-mapcan', but
this feels like something we already have: `sort' vs. `cl-sort' for
instance: `cl-sort' adds keywords not provided by the native Emacs Lisp
`sort'.  Similarily, `cl-mapcan' now provides the
multi-sequence behaviour, which is not provided by `mapcan',
since we really never use this, and it keeps the function simple,
and is actually symmetric to how `mapcar' or `mapc' work.
(Continue reading)

David Kastrup | 28 Jul 13:24 2014

Several problems

Current master (as of

    commit c7dc7052d94a19476bd8037d680162fd7f51c361
    Merge: 399fe8b aab3459
    Author: Glenn Morris <rgm <at> gnu.org>
    Date:   Mon Jul 28 05:39:09 2014 -0400

        Merge from emacs-24; up to r117412

in the Git mirror) has several problems for me.  Gnus startup fails to
connect to my POP server (via TLS/SSL) as well as the NNTP server at
news.gmane.org.  I can go through with C-g, go from *Group* into
*Server* with ^, then open the NNTP server from *there*.


    commit 4c19675328d0de84cc3181cfc118973f591e8243
    Author: Dmitry Antipov <dmantipov <at> yandex.ru>
    Date:   Mon Jul 28 10:28:15 2014 +0400

        On GNU/Linux, use timerfd for asynchronous timers.
        * configure.ac (toplevel): Check whether GNU/Linux-specific
        timerfd functions and macros are available.
        * m4/clock_time.m4 (gl_CLOCK_TIME): Check for clock_getres as well.
        * src/atimer.c (toplevel) [HAVE_TIMERFD]: Include sys/timerfd.h.
        (toplevel): Rename alarm_timer_ok to special_timer_available.
        [HAVE_TIMERFD]: Declare timerfd.
        [HAVE_CLOCK_GETRES]: Declare resolution.
        (start_atimer) [HAVE_CLOCK_GETRES]: Round up timestamp to
(Continue reading)

martin rudalics | 28 Jul 11:26 2014

Re: Changes in frame/window code

 >> Sounds pretty hairy, tho ...  With bidi text as above do you have a
 >> fixed text width?
 > I said "simple", didn't I?  The width is not fixed.
 >> In which (virtual L2R) column does R2L text start?
 > Sorry, I don't understand the question.  Are you asking about the
 > "normal" display of R2L text, or are you asking about scrolling?

If you have

L2R text here ....

            ..... and R2L text here what is the L2R position after here?

If the text width is not fixed how can I calculate the width of a R2L
line as it is displayed including any space between the left edge of the
display until where the text ends?

 > What I added only works well if the entire visible portion of the
 > buffer has the same paragraph direction, either L2R or R2L.  If you
 > have paragraphs in both directions visible, they will scroll in
 > opposite directions (because columns are counted in logical order, not
 > in visual order).

IIUC this means that the slider width must be calculated paragraph-wise
and position and size of the slider are meaningful only with respect to
the paragraph point is currently in.

(Continue reading)

Dmitry Antipov | 28 Jul 08:31 2014

m4/clock_time.m4 from r117596

IIUC this should be incorporated into gnulib.


Mark Oteiza | 28 Jul 07:23 2014

emacs-24 bracketed paste and term library fixes


Some time ago, support for bracketed paste and fixes applied to some of
the term libraries made emacs' default behaviour in a term a lot more
pleasant.  I built from emacs-24 today and found the difference rather
jarring.  Would it be possible to backport these fixes from master to
the emacs-24 branch?


Angelo Graziosi | 28 Jul 00:25 2014

About horizontal scroll bar

I notice that when I start Emacs (rev. 117589, MSYS2/MinGW64 build), the 
buffer which is active (that on which I worked in the previous session) 
does not display the horizontal scroll bar (HSB).

Switching to another buffer, this DISPLAYS the HSB. Switching back to 
the first buffer, now it DISPLAYS the HSB..

Is this to be expected?


Nic Ferrier | 27 Jul 12:34 2014

eww as a package?

I wish that something like eww was delivered as a separate package so
that those of us not on daily trunk could pull it and start playing with

Any chance of that?


Matthew Plant | 25 Jul 21:47 2014

Raw string literals in Emacs lisp.

I think that raw string literals would be a really nice thing to add to Emacs
lisp. The most immediate benefit is that writing regexps would be much easier.
And since most of the work that goes into major modes is writing regexp, writing
major modes would become a lot faster.

Obviously it can't be done in any way that's really consistent with the language
(it'd be super nice if ``string'' could be used, but alas). However, perhaps I
have found a reasonable approach.

What if we assume that any string surrounded immediately by parenthesis is a raw
string literal? I'm pretty sure every instance of ("...") is currently illegal,
and it would be almost certainly trivial to extend the Emacs' lexer/parser to
support it. I can do it myself if everyone thinks this is a good idea.

Please let me know what your thoughts are on this.

Dmitry Antipov | 25 Jul 15:59 2014

Broken timers (handle_alarm_signal is never called)?

Can someone explain when handle_alarm_signal is expected to be called?

Executing keyboard macro, say, 100000 times, should enter Emacs into "busy"
state.  Thus hourglass cursor should be displayed, which is done with 1s
delay via start_atimer.  This means that SIGARLM should be (re)scheduled,
and it is.  But handle_alarm_signal is never called; instead, timers are
processed just after the next input becomes available.  So if there is no
input, timers will be processed...never?  If yes, this looks like a very
strange (read: fundamentally broken) timers subsystem.

It should be not so hard to observe this scenario under gdb or with attached
tracing patch.


Attachment (timer-trace.patch): text/x-patch, 896 bytes