Dmitry Antipov | 24 Nov 05:08 2014

Latest gnutls changes breaks --enable-gcc-warnings

As of e01ec2ed084776b370e0634120deec6b65424b8a, --enable-gcc-warnings produces:

../../emacs/src/gnutls.c:772:1: error: no previous prototype for ‘gnutls_hex_string’ [-Werror=missing-prototypes]
  gnutls_hex_string (char *buf, size_t buf_size, char *prefix) {
../../emacs/src/gnutls.c:790:1: error: no previous prototype for
‘gnutls_certificate_details’ [-Werror=missing-prototypes]
  gnutls_certificate_details (gnutls_x509_crt_t cert)
../../emacs/src/gnutls.c: In function ‘gnutls_certificate_details’:
../../emacs/src/gnutls.c:813:7: error: passing argument 3 of ‘gnutls_hex_string’ discards
‘const’ qualifier from pointer target type [-Werror]
        gnutls_hex_string (serial, serial_size, "")));
../../emacs/src/gnutls.c:772:1: note: expected ‘char *’ but argument is of type ‘const char *’
  gnutls_hex_string (char *buf, size_t buf_size, char *prefix) {
../../emacs/src/gnutls.c:927:9: error: passing argument 3 of ‘gnutls_hex_string’ discards
‘const’ qualifier from pointer target type [-Werror]
          gnutls_hex_string (buf, buf_size, "")));
../../emacs/src/gnutls.c:772:1: note: expected ‘char *’ but argument is of type ‘const char *’
  gnutls_hex_string (char *buf, size_t buf_size, char *prefix) {
../../emacs/src/gnutls.c:945:14: error: passing argument 3 of ‘gnutls_hex_string’ discards
‘const’ qualifier from pointer target type [-Werror]
               buf_size, "sha1:")));
../../emacs/src/gnutls.c:772:1: note: expected ‘char *’ but argument is of type ‘const char *’
  gnutls_hex_string (char *buf, size_t buf_size, char *prefix) {
(Continue reading)

Unknown | 23 Nov 22:56 2014

vc-state-heuristic is gone

First, easiest gain from attacking the VC backend API with fire and
sword:  vc-state-heuristic is gone. vc-stay-local is probably next.

These were attempts at performance optimizatiion that made sense when
disk and network operations were much slower than they are now.  I
remember quite clearly that when I first wrote VC mode in 1992 I spent
the majority of my effort on thinking up ways to avoid hitting the

But the tradeoffs have changed.  The operations I was trying to avoid
are much less expensive today, but the cost of the bugs and edge
conditions produced by incautiously doing repository operations behind
Emacs's back (and this rendering the caching and heuristics involved
ivalid) has not dropped.  If anything, it has risen.

Thus, a brutal and effective simplification: *all caching goes away*.

Affected back ends: SCCS, RCS, CVS, SVN, Bazaar.  I've already tested
with RCS and any change in preformance is now so small that a human is
not capable of registering it.

		<a href="">Eric S. Raymond</a>

A nation or civilization that continues to produce soft-minded men
purchases its own spiritual death on an installment plan.
	--Martin Luther King, Jr. 

Dani Moncayo | 23 Nov 19:38 2014

Build failure (master; MS-Windows)

gcc -std=gnu99  -mtune=pentium4      -I. -I../src -I../lib
-mtune=pentium4  -DGLYPH_DEBUG=1 -DUSE_CRT_DLL=1 -I
/c/cygwin64/home/Dani/devel/emacs/repo/nt/inc -g3 -O2 -gdwarf-2
/c/cygwin64/home/Dani/devel/emacs/repo/lib-src/emacsclient.c \
   -DVERSION="\"25.0.50\"" ntlib.o ../lib/libgnu.a   \
   -lwsock32 -lcomctl32 -o emacsclient.exe
make[1]: *** No rule to make target
needed by `emacsclient.res'.  Stop.
make[1]: Leaving directory `/home/Dani/devel/emacs/build-master-i686/lib-src'
Makefile:372: recipe for target `lib-src' failed
make: *** [lib-src] Error 2


Dani Moncayo

Roland Lutz | 23 Nov 16:35 2014

Stop fiddling with my preferences

I've been using Emacs for quite a while, and I think it's a great program. 
Sure, things work differently than in most newly-written GUI applications, 
but at least for me, they work *better*.

For the past few months, however, each time I upgraded to a new version of 
Emacs, something in the behavior changed.  I had to figure out each time 
what it was that caused the change and how to compensate for it.  This 
usually took me an hour or more since it isn't easily documented and most 
solutions suggested on the web have unwanted side-effects.  Right now, the 
compatibility section in my .emacs file reads:

(set 'x-select-enable-clipboard nil)
(set 'x-select-enable-primary t)
(set 'select-active-regions nil)
(set 'mouse-drag-copy-region t)
(set 'delete-active-region nil)
(set 'electric-indent-chars (remq ?\n electric-indent-chars))

This sort of behavior changes is common among browsers and proprietary 
operating systems, but does this make it appropriate for Emacs?  One of 
the reasons I'm using mature software is exactly that I *don't* have to be 
worried with each new version that ESC won't stop playing animated GIFs 
any more, etc.

I'm not arguing about defaults (I think they shouldn't change without a 
good reason--other than personal preference--either, but that's an 
entirely different story) but that I don't want them to change once I've 
got used to how Emacs works.

How about not changing the defaults but shipping an updated skeleton 
(Continue reading)

Lars Magne Ingebrigtsen | 23 Nov 16:18 2014

DOM manipulation functions

As part of the TLS management thing, it was suggested that Emacs display
visually certificate fingerprints:

I've started looking into this, and it seems like this would be really
easy to implement as SVG images -- SVG provides all the primitives
vizhash needs.

SVG is basically an XML DOM, and while constructing these it would be a
lot easier if Emacs had a DOM manipulation library.

So here's my two questions:

1) Would it be OK if I added a DOM manipulation/searching library to

2) Due to stupidity on my part I disregarded Chong's advice on how to do
the DOM manipulation things in shr.el, so we now basically have two DOMs
in Emacs -- the xml.el one and the one that shr uses.

I think it would be a good idea if I rewrote shr.el to just use the
xml.el DOM, like Chong said back then.  This will break any third-party
code that relies on shr internals, though.

So: New dom.el, and rewrite shr/eww to depend on dom.el.

Stefan, does this sound OK to you?


(Continue reading)

Lars Magne Ingebrigtsen | 23 Nov 15:16 2014

The Network Security Manager is now on the trunk

`network-security-level' defaults to `low', though, so it will not
actually be used, so there should currently be no impact on anybody,
unless I made a boo-boo somewhere.

There may be building problems on non-GNU/Linux systems because of the
gnutls.c changes, but hopefully not.


(domestic pets only, the antidote for overdose, milk.)
   bloggy blog:

Paul Michael Reilly | 23 Nov 13:19 2014

Emacs, Mac OS X Yosemite and restarts after sleep

I recently upgraded to Yosemite (fresh install) on a 6 month old MacBook Pro and noticed that upon being woken up after "sleep"ing, the system had been restarted.  This led to a triage by Apple support where the logic board was replaced.  Upon getting the system back I tested it again (sleep needs to be in place for around an hour, at least) and got the same problem.

I should note that this problem did not occur at all while running Mavericks and a devel build of Emacs 24.4 for the entire six months I had the new computer.

At the time of the upgrade I also built a fresh devel copy of Emacs 25.  Not believing it was a hardware issue any longer I became suspicious that it was a software issue in general and Emacs in particular.  So I ran a few experiments.

First I brought up just Google Chrome and a few auto-started apps of no import and let the system sleep for a few hours.  No restart after subsequently waking the system up.  No Emacs, no problem.

Next I started up a freshly installed version of the 24.4 Mac build from and reran the experiment.  This time a restart occurred after waking the system up.

The final test was to use Emacs 25 built around the time Eric announced the git conversion ready for testing.  This test also failed.  Conclusion: Emacs and Yosemite do not play nice together.

So I have two questions:  1) would someone with a recent model MacBook Pro, running Yosemite and either Emacs 24.4 or 25.0.90 (fullscreen mode) please run the experiment and report back your results; 2) can someone suggest methods I can use to log relevant information on Emacs' termination or maybe even a breakpoint (I'm inclined to use both if I can).  Of course all other suggestions that will help triage this problem will be much appreciated.  It appears to me that Apple has changed something in Yosemite that would be good for them to know, not that that will lead to a solution from them.  I expect that will come from us, once we understand if and why Emacs is dying and bringing the system down with it.

Harry Putnam | 23 Nov 00:26 2014

Lucid or motif... any difference?

Building emacs-25 on Debian (jessie)

Should I see visible differences when building 25 with toolkit=lucid
vs toolkit=motif?

After building with toolkit=lucid, motif and gtk.... the only one that
looks different (and to me; worse) is gtk... is that normal?

Glenn Morris | 22 Nov 23:31 2014

emacs-diffs emails can get long subject if log starts with "*"

So as an FYI, it looks like:

If you start your commit message with a "*" (which is quite a common
practice for Emacs), git-multimail ignores line-breaks in your commit
log, and stuffs the entire log into the subject of the mail that it
sends out to emacs-diffs.


Stephen Berman | 22 Nov 15:23 2014

Undesired interactive call of major mode command

Bug#19112 reports an error resulting from typing `M-x todo-mode RET'.
The real issue (at least for me, as the maintainer of Todo mode) is not
the error but that todo-mode, although it is the "major mode command",
is not intended to be invoked interactively.  I'm not sure how best to
deal with this.  Three alternatives have occurred to me.  (i) Tell
users: "Don't do that."  (ii) Add to todo-mode the condition
(called-interactively-p 'any) and if it returns t either show a message
saying how to enter todo mode or simply call the intended (and
documented) Todo mode entry command (todo-show).  But this has the
problem that, as soon as todo-mode is invoked, the current buffer
changes to Todo mode; this is because todo-mode is defined with
define-derived-mode.  (iii) The only way I can see to avoid this is not
to use define-derived-mode.  Then I could also make todo-mode
noninteractive.  Of course, this goes against the convention that major
modes have a major mode command.  But there are precedents,
e.g. dired-mode.

Is there a best-practice recommendation for this situation, or is there
another alternative I've overlooked?  I'd be grateful for any advice.

Steve Berman

Unknown | 22 Nov 14:33 2014

My plans for VC mode

I have noted in previous mail that the VC code lacks a clean set of
primitives to deal with branching.  My goal is to fix that.

In the way is the fact that the VC backend API is still something of
a mess.  Everyone who has previously modified it (including me in 2007
when I did the fileset rewrite) has tried to preserve backward
compatibility to the year zero.  As a result, the upper-level code
has never gotten completely divorced from the file-oriented back ends.

The merge command is a particular trouble spot where the back-end model
pokes upward into what should be VCS-independent - as is revealed
by the ";; FIXME: This is CVS/RCS/SCCS specific." in vc/vc.el.
Because of the code that calls out, SVN merge in particular plain
doesn't work right - it assumes RCS behavior in SVN revision numbers.

A related effect of trying to preserve backward compatibility is that
the backend API has more entry points than it should and is harder to
understand than it should be. I had my nose rubbed in this writing the
support for SRC. Given the advantages of having written both VC mode
and SRC and the freedom to modify SRC to make VC-mode happy, it was
*way* more difficult than it should have been.

Accordingly, I have concluded that it is time to chuck backward
compatibility and rewrite tha back-end API, simplifying as radically
as I can and enforcing much stricter separation between the VC upper
layer and the back ends.

This is going to break out-of-tree back ends - not in any way that is
fundamentally difficult to fix, but it will break them. I've already had
one polite complaint about that in email, but explained that we can't
be stuck with the cruft and the previous design mistakes forever.

I'm explaining this, while "make bootstrap" runs to test a build,
because it may cause some minor disruptions.  I'm a little worried
about breaking CVS support; that back end is both the worst hairball
in the file-oriented group (SCCS/RCS/CVS/SRC) and the one I'm least
able to test well.  I could use some help with this if there is
anyone on the list using vc-cvs regularly.

While I do branching I'm also going to look at removing the elaborate
caching the older back ends use to avoid disk traffic as much as
possible.  That made sense when I first wrote it twenty-odd years
ago, but it's been a chronic source of TOCTOU bugs and other
coherency problems ever since.  Disks are much faster now; it's
probably time for the state-heuristic stuff to die.

		<a href="">Eric S. Raymond</a>

The saddest life is that of a political aspirant under democracy. His
failure is ignominious and his success is disgraceful.
        -- H.L. Mencken