http://permalink.gmane.org/gmane.emacs.bugs hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.emacs.bugs/60366 <pre>emacs -Q (defcustom foo '(current-time-string) "&lt; at &gt;&lt; at &gt;&lt; at &gt;&lt; at &gt;&lt; at &gt;&lt; at &gt;&lt; at &gt;&lt; at &gt;&lt; at &gt;&lt; at &gt;&lt; at &gt;&lt; at &gt;&lt; at &gt;&lt; at &gt;&lt; at &gt;" :type 'sexp) M-x customize-option foo Type this into the editable field: (current- Then hit `M-TAB'. You get this inappropriate error message: "Not in an editable field" If completion is not available, the message should say that. It should not claim that the field is not editable when it is. In GNU Emacs 24.0.97.1 (i386-mingw-nt5.1.2600) of 2012-05-16 on MARVIN Windowing system distributor `Microsoft Corp.', version 5.1.2600 Configured using: `configure --with-gcc (4.6) --no-opt --enable-checking --cflags -ID:/devel/emacs/libs/libXpm-3.5.8/include -ID:/devel/emacs/libs/libXpm-3.5.8/src -ID:/devel/emacs/libs/libpng-dev_1.4.3-1/include -ID:/devel/emacs/libs/zlib-dev_1.2.5-2/include -ID:/devel/emacs/libs/giflib-4.1.4-1/include -ID:/devel/emacs/libs/jpeg-6b-4/include -ID:/devel/emacs/libs/tiff-3.8.2-1/include -ID:/devel/emacs/libs/gnutls-3.0.9/include' </pre> Drew Adams 2012-05-26T03:12:39 http://permalink.gmane.org/gmane.emacs.bugs/60365 <pre> This is reproducible with 23.X (up to 23.4), but it does not happen with 24.0.97 (there is much window stuff changed in 24.1 with respect to 23.X).     Juanma </pre> Juanma Barranquero 2012-05-26T03:10:34 http://permalink.gmane.org/gmane.emacs.bugs/60364 <pre>Version: 24.2 Thanks; applied. </pre> Glenn Morris 2012-05-26T02:41:07 http://permalink.gmane.org/gmane.emacs.bugs/60363 <pre>Version: 24.2 Kevin Ryde wrote: OK; changed. </pre> Glenn Morris 2012-05-26T02:35:39 http://permalink.gmane.org/gmane.emacs.bugs/60362 <pre>I'm using Emacs on X on Debian 6 Stable. emacs-version says GNU Emacs 23.2.1 (i486-pc-linux-gnu, GTK+ Version 2.20.0) of 2010-12-11 on raven, modified by Debian. Steps to reproduce the bug: emacs -Q C-x b foo ret C-x 2 C-x r w a C-x 1 C-x k ret C-x r j a Notice that in the bottom window, you get a buffer named "*Minibuf-1*". Press M-x and type something; notice that your text appears both in the minibuffer and in the bottom window. Surely this is a bug. Previously I managed to get it to give an error message "exit-minibuffer: No catch for tag: exit, nil", but I don't remember how, and my notes say that this had something to do with ido-mode, but I don't remember why. It was a couple weeks ago. Just now while verifying reproduction of the window corruption, I did it a little differently and managed to lock up Emacs with 100% CPU usage, and got a segfault when I killed it, but I can't reproduce that. Too bad that dumping core isn't the default anymore. </pre> Kelly Dean 2012-05-26T01:46:13 http://permalink.gmane.org/gmane.emacs.bugs/60361 <pre>Hello John, On Wed, May 23, 2012 at 05:28:24AM -0500, John Wiegley wrote: This has been the case for some while, as you have said. The offending function is probably c-font-lock-enclosing-decls, a relatively new function. c-f-l-e-decls solves the former problem of misfontification when a jit-lock chunk started within (mainly) a struct/enum/union/class/... and lacked the context to fontify correctly. An example of this happening was the first enum construct in .../emacs/src/gnutls.h. Could you possibly check this is the case in your file.c++ using elp. Here's a quick recipe in case you haven't used it before: [ M-x elp-instrument-package &lt;ret&gt; c- &lt;ret&gt;. Scroll with C-v, either once or an arbitrary number of times. M-x elp-results.] The cost of this correct fontification is the "slight" sluggishness being seen here. It is likely possible to optimise this function somewhat, though probably it's now too late for Emacs 24.1. </pre> Alan Mackenzie 2012-05-25T21:45:47 http://permalink.gmane.org/gmane.emacs.bugs/60360 <pre>ping again. This is a regression. It has a simple fix. Can this please be fixed? </pre> Drew Adams 2012-05-25T20:52:23 http://permalink.gmane.org/gmane.emacs.bugs/60359 <pre>Stefan OKed this patch so I installed this into the trunk as bzr 108370 and am marking the bug as done. The idea is to give Dmitry a chance to rework his proposal for immediate strings &lt;http://lists.gnu.org/archive/html/emacs-devel/2012-05/msg00435.html&gt; in the light of the usually-smaller data structures when configured --with-wide-int on 32-bit hosts. This patch affects w32fns.c and w32menu.c in what I hope are trivial and safe ways, so I'm CC'ing this to Eli to give him a heads-up too. </pre> Paul Eggert 2012-05-25T20:50:35 http://permalink.gmane.org/gmane.emacs.bugs/60358 <pre> `edebug-eval-defun' uses `eval-sexp-add-defvars' after the specialcaseing, so `eval-defun-1' could do the same: === modified file 'lisp/emacs-lisp/lisp-mode.el' --- lisp/emacs-lisp/lisp-mode.el2012-05-24 23:24:47 +0000 +++ lisp/emacs-lisp/lisp-mode.el2012-05-25 20:28:17 +0000 &lt; at &gt;&lt; at &gt; -830,10 +830,10 &lt; at &gt;&lt; at &gt; (defun eval-defun-2 () (end-of-defun) (beginning-of-defun) (setq beg (point)) - (setq form (eval-sexp-add-defvars (read (current-buffer)))) + (setq form (read (current-buffer))) (setq end (point))) ;; Alter the form if necessary. - (setq form (eval-defun-1 (macroexpand form))) + (setq form (eval-sexp-add-defvars (eval-defun-1 (macroexpand form)))) (list beg end standard-output `(lambda (ignore) ;; Skipping to the end of the specified region </pre> Juri Linkov 2012-05-25T20:35:58 http://permalink.gmane.org/gmane.emacs.bugs/60357 <pre>Just to complete this discussion for the sake of the archives, the crashes I was getting resulted from a Cygwin bug, which has been fixed in the 2012-05-25 Cygwin snapshot. But I still think that the patch I applied makes sense, as long as it doesn't cause other problems down the road. Ken </pre> Ken Brown 2012-05-25T20:32:17 http://permalink.gmane.org/gmane.emacs.bugs/60356 <pre> Can you build the current emacs-24 branch on that machine? If so, what happens if you visit leim/MISC-DIC/ziranma.cin? For the trunk, does it help to add --eval '(progn (setq imagemagick-types-inhibit t) (imagemagick-register-types))' to RUN_EMACS in leim/Makefile.in and rebuild from a clean state? If so, this is probably http://debbugs.gnu.org/11521 </pre> Glenn Morris 2012-05-25T20:21:03 http://permalink.gmane.org/gmane.emacs.bugs/60355 <pre>[I'm using a pretest, but this isn't a regression. Applying the fix in 24.2 is fine with me.] Reproduce: M-x load-library thingatpt M-: (forward-same-syntax) gives Lisp error: (wrong-type-argument number-or-marker-p nil) Thanks for Emacs, /a 2012-05-25 Aaron S. Hawley &lt;aaron.s.hawley&lt; at &gt;gmail.com&gt; * thingatpt.el (forward-same-syntax): Calling as a function in Lisp with no argument gives error "wrong-type-argument number-or-marker-p nil" from `while'. --- thingatpt.el2012-04-07 23:03:02.000000000 -0400 +++ thingatpt.el2012-05-25 12:33:28.817991100 -0400 &lt; at &gt;&lt; at &gt; -455,8 +455,9 &lt; at &gt;&lt; at &gt; (defun forward-same-syntax (&amp;optional arg) "Move point past all characters with the same syntax class. With prefix argument ARG, do it ARG times if positive, or move backwards ARG times if negative." (interactive "p") + (or arg (setq arg 1)) (while (&lt; arg 0) (skip-syntax-backward (char-to-string (char-syntax (char-before)))) </pre> Aaron S. Hawley 2012-05-25T19:40:13 http://permalink.gmane.org/gmane.emacs.bugs/60354 <pre> That sounds right to me. </pre> Jim Meyering 2012-05-25T17:18:21 http://permalink.gmane.org/gmane.emacs.bugs/60353 <pre> How about turning this ImageMagick thing around: Instead of enabling image support for the 100s of extensions that ImageMagick thinks are images, minus a few exceptions (imagemagick-types-inhibit), have an explicit customizable list of the types to accept, defaulting to things "everyone" agrees are really images (bmp etc). </pre> Glenn Morris 2012-05-25T17:09:46 http://permalink.gmane.org/gmane.emacs.bugs/60352 <pre> I can not reproduce it on Windows 7. After 4), Emacs uses the full screen, minus the left-side taskbar, which is not obscured.     Juanma </pre> Juanma Barranquero 2012-05-25T17:04:06 http://permalink.gmane.org/gmane.emacs.bugs/60351 <pre> I testing this issue on Windows 7 and got the same results. This is not limited to Windows XP. </pre> Rolf Campbell 2012-05-25T16:20:39 http://permalink.gmane.org/gmane.emacs.bugs/60350 <pre> Same issue as http://debbugs.gnu.org/11521 (memq 'X (imagemagick-types)) -&gt; (X X3F ...) </pre> Glenn Morris 2012-05-25T16:23:53 http://permalink.gmane.org/gmane.emacs.bugs/60349 <pre>Hi, For the past week or so the Emacs bzr HEAD has failed to build with image magick support. The following error is signaled [1]. I'm running a 64-but Arch GNU-Linux system, and other Arch users have noticed this problem as well [2]. As Arch tries to include the latest version of all tools this is likely due to a conflict with the most recent version of imagemagick. I have the following version installed [3]. Please let me know if there is any other information I can provide. Thanks, Footnotes: [1] $ make build ... temacs: magick/exception.c:968: ThrowMagickExceptionList: Assertion `exception-&gt;signature == 0xabacadabUL' failed. /bin/sh: line 5: 17636 Aborted `/bin/pwd`/temacs --batch --load loadup bootstrap [2] https://bbs.archlinux.org/viewtopic.php?id=140037 [3] $ convert --version Version: ImageMagick 6.7.6-8 2012-05-01 Q16 http://www.imagemagick.org Copyright: Copyright (C) 1999-2012 ImageMagick Studio LLC Features: OpenMP </pre> Eric Schulte 2012-05-25T15:35:01 http://permalink.gmane.org/gmane.emacs.bugs/60348 <pre>I was surprised to find that emacs now tries to display all of coreutils' man/*.x files as images. It seems to treat any nonempty *.x file that way. Instead of seeing what I normally treat as a simple text file with man file [section]/text snippets, all I see is a small square (maybe 20x20 pixels) in the upper left corner of the window. Reproduce via e.g., echo foo &gt; a.x &amp;&amp; emacs -q a.x The mode line reports that it is in (Image[imagemagick]) mode. What version? $ emacs --version GNU Emacs 24.1.50.1 I build snapshots from bzr nearly daily, and could quickly bisect down to this 3-day interval: GOOD emacs-2012-04-13.06h37/bin/emacs BAD emacs-2012-04-16.08h09/bin/emacs When it works as I expected (i.e., I can see actual text in the primary buffer, and no outlined square), I see "LD-script" in the mode line. </pre> Jim Meyering 2012-05-25T15:56:36 http://permalink.gmane.org/gmane.emacs.bugs/60347 <pre> Good point. We should change eval-defun-1 to look inside `progn'. Or alternatively, we should use eval-sexp-add-defvars after the macroexpand+specialcaseing. Stefan </pre> Stefan Monnier 2012-05-25T13:21:02 http://permalink.gmane.org/gmane.emacs.bugs/60346 <pre>Hi, I recently switched from Emacs 23 to the current version on the emacs-24 branch (r108014) and bumped into a strange behaviour of bury-buffer at the start of a session. I'm using desktop.el and (global-set-key "\C-xy" 'bury-buffer) in .emacs (because I have a bad memory and like to bury stuff ;-). Every time I start Emacs, I see the correct buffer, i.e. the one I used before I closed Emacs previously. I edit that buffer a bit and bury it. In my case, bury-buffer switches to the wrong buffer. Instead of switching to the buffer next in line (so to speak), bury-buffer switches to what seems to be the last buffer in the list of all buffers. Here's a little example in form of a "emacs -Q" recipe: 3 C-x C-s 3 RET C-x b 2 RET 2 C-x C-s 2 RET C-x b 1 RET 1 C-x C-s 1 RET M-x desktop-save &lt;filename&gt; This should leave you with with three saved buffers in the order 1-2-3 and a desktop file. C-x C-b should be able to confirm the buffer order. Now close Emacs, start a fresh one and M-x desktop-read your d</pre> Tobias Bading 2012-05-25T08:50:47 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.emacs.bugs