Katsumi Yamaoka | 29 May 02:13 2015

Re: [Buildbot] Gnus build failed

On Fri, 29 May 2015 01:57:05 +0200, gnus-buildbot <at> randomsample.de wrote:
> The Buildbot has detected a new failure on builder emacs-devel.
> Details at: http://randomsample.de/gnus-buildbot/builders/emacs-devel/builds/737
> Blamelist: Katsumi Yamaoka <yamaoka <at> jpl.org>

> Please note:
>  - The Buildbot uses 'make fail-on-warn'
>  - If this build fails again, it will only be reported on the
>    Gnus-buildbot mailing list (gmane.emacs.gnus.buildbot)

> ---------------------------------------------------------------

Why did the build, in the last process `test', fail?
The change are for only string objects (see below), so it should
not be a cause of any error.

--- gnus-art.el~	2015-05-28 22:46:35.929698000 +0000
+++ gnus-art.el	2015-05-28 07:47:44.000000000 +0000
 <at>  <at>  -7828,11 +7828,11  <at>  <at> 
      ;; Exclude [.?] for URLs in gmane.emacs.cvs
      1 (>= gnus-button-emacs-level 8) gnus-button-handle-library 1)
-    ("`\\([a-z][-a-z0-9]+\\.el\\)'"
+    ("[`‘]\\([a-z][-a-z0-9]+\\.el\\)['’]"
      1 (>= gnus-button-emacs-level 8) gnus-button-handle-library 1)
-    ("`\\([a-z][a-z0-9]+-[a-z0-9]+-[-a-z0-9]*[a-z]\\|\\(gnus\\|message\\)-[-a-z]+\\)'"
+    ("[`‘]\\([a-z][a-z0-9]+-[a-z0-9]+-[-a-z0-9]*[a-z]\\|\\(gnus\\|message\\)-[-a-z]+\\)['’]"
      0 (>= gnus-button-emacs-level 8) gnus-button-handle-symbol 1)
-    ("`\\([a-z][a-z0-9]+-[a-z]+\\)'"
+    ("[`‘]\\([a-z][a-z0-9]+-[a-z]+\\)['’]"
(Continue reading)

Angelo Graziosi | 28 May 15:56 2015

Wrong PATH in MSYS2/MINGW64 builds?

Trying to visit a bzip2 file (foo.txt.bz2) with 
mingw-w64-emacs-git-r121447.8a9ba4d-1 installed package, I got

  Uncompression program `bzip2' not found

So, trying

   (getenv "PATH")

from scratch buffer, prints:


I wonder if this is Windows-builds related of we can do a better build. 
BTW I HAVE bzip2 installed (both in MINGW64 and MSYS2 shells):

$ type bzip2
bzip2 is /mingw64/bin/bzip2

$ type bzip2
bzip2 is /usr/bin/bzip2


raman | 27 May 17:44 2015

Feature Request: EWW: record content-type in eww-data?

Hi --

Could we add the content-type as a property on eww-data?

Also, could we set EWW so that one can attach handlers for additional content-types -- specifically, I'd
like to handle RSS, ATOM and OPML -- so mime types application/xml+rss and friends.



Petr Hracek | 27 May 12:00 2015

Question about PRIMARY saved-region-selection

Hi folks,

I saw that you have fixed the bug with PRIMARY issue.
Is this bug also relevant for emacs-24.3 or only for 24.4?

$ git show c3c4b758c6d3e33d7fa7621ba4a50ec75c121247
commit c3c4b758c6d3e33d7fa7621ba4a50ec75c121247
Author: Jan D <jan.h.d <at> swipnet.se>
Date:   Sun Mar 22 19:31:46 2015 +0100

    Fixes: debbugs:18939

    * simple.el (deactivate-mark): Only modify PRIMARY if we own PRIMARY.

diff --git a/lisp/ChangeLog b/lisp/ChangeLog
index 8f888e3..7c7c66d 100644
--- a/lisp/ChangeLog
+++ b/lisp/ChangeLog
<at> <at> -1,3 +1,8 <at> <at>
+2015-03-22  Jan Djärv  <jan.h.d <at> swipnet.se>
+       * simple.el (deactivate-mark): Only modify PRIMARY if we own
+       PRIMARY (Bug#18939).
 2015-03-22  Martin Rudalics  <rudalics <at> gmx.at>

        * emacs-lisp/debug.el (debug): Don't try using "previous" window
diff --git a/lisp/simple.el b/lisp/simple.el
index ae07f62..5e5cd87 100644
--- a/lisp/simple.el
+++ b/lisp/simple.el
<at> <at> -4420,7 +4420,8 <at> <at> run `deactivate-mark-hook'."
       ;; the region prior to the last command modifying the buffer.
       ;; Set the selection to that, or to the current region.
       (cond (saved-region-selection
-            (x-set-selection 'PRIMARY saved-region-selection)
+            (if (x-selection-owner-p 'PRIMARY)
+                (x-set-selection 'PRIMARY saved-region-selection))
             (setq saved-region-selection nil))
            ;; If another program has acquired the selection, region
            ;; deactivation should not clobber it (Bug#11772).

Greetings and thank you in advance

Petr Hracek
Software Engineer
Developer Experience
Red Hat, Inc
Mob: +420777056169
email: phracek <at> redhat.com

-- Petr Hracek Software Engineer Developer Experience Red Hat, Inc Mob: +420777056169 email: phracek <at> redhat.com
Artur Malabarba | 27 May 03:49 2015

Package refresh and install/delete marks

> Async refreshing has grown on me too, but it still needs to implement retaining the marks set by the user.

For the record, this is now done.
It was implemented by having tabulated-list only update the buffer, instead of printing it anew.
As a bonus, the printing step is now blazing fast. So the small hang we get after archives are downloaded is now barely noticeable.

Of note:
- if the user marks a package (for install/delete) and that package is gone after the refresh, then the mark is gone too.
- if the user hits U while a refresh is in progress, the package menu will wait until the refresh is done before actually marking the upgrades. This is to avoid the scenario where the refresh could erase the install marks and keep the delete marks.
- Hitting g will still revert the entire buffer and wipe all marks (this is intentional).

Kelvin White | 27 May 01:19 2015

After a git merge and manual correction of a conflict, how do I tell git the conflict is fixed?

Apologies, I'm using gmail on my mobile and it's not cutting me any slack at the moment

---------- Forwarded message ---------
From: Kelvin White <kwhite <at> gnu.org>
Date: Tue, May 26, 2015, 7:17 PM
Subject: Re: After a git merge and manual correction of a conflict, how do I tell git the conflict is fixed?
To: Dmitry Gutov <dgutov <at> yandex.ru>, Alan Mackenzie <acm <at> muc.de>

This tidbit here I think is the part you want I think...

"git rm --cached <file>" would remove <file> from version control, while keeping it in the working repository.

On Tue, May 26, 2015, 7:14 PM Kelvin White <kwhite <at> gnu.org> wrote:


also look at this...


Alan Mackenzie | 27 May 00:39 2015

After a git merge and manual correction of a conflict, how do I tell git the conflict is fixed?

Hello, Emacs

It's git misery time again.  :-(

I did a git stash, followed by git merge, followed by git stash pop.
This caused a conflict in .gitignore, which I repaired by editing
that file.

I think (but I'm not sure), I need somehow to tell git that the file has
been fixed.  The git equivalent of 'bzr resolve'.  I can't find any
documentation telling me how to do this, or alternatively that it's not

git status returns the following obscure "information":

    On branch master
    Your branch is up-to-date with 'origin/master'.
    Unmerged paths:
      (use "git reset HEAD <file>..." to unstage)
      (use "git add <file>..." to mark resolution)

            both modified:   .gitignore

.  I don't think I want to "unstage" anything (whatever that might
mean) - IIUC, the suggested recipe would discard all my changes.  I think
I might want to "mark resolution" (assuming this gobbledegook means
"mark <file> as resolved"), but the suggested recipe, as far as I am
aware, doesn't "mark resolution", instead it moves a file into a list of
files to be committed in the (?near) future.

Do I actually need to tell git that the merge conflicts in .gitignore
have been fixed?  If so, how do I do this?  There doesn't appear to be a
'git resolve' command.

Where is this 'bzr resolve' equivalent documented?  I now have git
2.3.6, and it now comes with an info manual, and all its man pages
stuffed into another info document, which is a great improvement.  I
still can't find what I need, though.

Thanks in advance for the help.


Alan Mackenzie (Nuremberg, Germany).

Sam Steingold | 26 May 23:06 2015

build problems

The current git tip does not built:

1. `make bootstrap` fails with
--8<---------------cut here---------------start------------->8---
No rule to make target `../src/lisp.mk', needed by `Makefile'.
--8<---------------cut here---------------end--------------->8---

2. when I edit Makefile to remove the lisp.mk dependency, I get
--8<---------------cut here---------------start------------->8---
  CC       image.o
../../src/image.c:8203:10: fatal error: 'wand/MagickWand.h' file not found
#include <wand/MagickWand.h>
1 error generated.
make[1]: *** [image.o] Error 1
--8<---------------cut here---------------end--------------->8---



Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1347
http://www.childpsy.net/ http://jihadwatch.org http://iris.org.il
http://www.dhimmitude.org http://palestinefacts.org http://honestreporting.com
Diplomacy is the art of saying "nice doggy" until you can find a nice rock.

Timur Aydin | 26 May 19:26 2015

configure run again during make bootstrap

I have retrieved the git emacs source today and have done the:

make bootstrap

dance as usual. But during the bootstrapping, I am seeing that the 
configure script is run again. So i did a git clean in the repository 
and this time, i just did a make bootstrap. That worked fine and the 
makefile has done the autogen.sh and configure steps by itself.

So my question is, is it enough to just do make bootstrap after 
retrieving the git sources?

Also, if this is enough, how do I pass options to the configure script? 
like for example, i want to pass in "--prefix=$HOME/emacs" to the 
configure script.




Vaidheeswaran C | 26 May 08:57 2015

[PATCH] Info-mode-font-lock-keywords: Fix-regexp

Fontification happens fine with the attached change.
Vaidheeswaran C | 25 May 17:26 2015

Image scaling in Info viewer

Image scaling in Info viewer

I happened to include a screenshot of an Emacs session in a *.info
file and viewed the info using C-u C-h i.  The screenshot seemed
truncated.  (But) Turning on the horizontal scroll bar told me that
the image was only partially displayed and not cropped.  So...

Shouldn't Emacs autoscale the image to fit in to the buffer...WDYT.
The link below (which talks about image scaling) mostly talks about
points and inches (which seem like measurements targetted at paper