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/74434 <pre> Sorry, I cannot do anything with this information. I don't have sources of ntoskrnl and of ntdll. If Emacs no gets stuck in threads that we didn't launch from our Emacs application code, then perhaps this is not an Emacs problem at all. Thanks. The only ones that might be relevant are those that connect to localhost: But I know nothing about these processes. </pre> Eli Zaretskii 2013-05-21T16:48:28 http://permalink.gmane.org/gmane.emacs.bugs/74433 <pre>--text follows this line-- Using M-x gud-gdb &lt;CR&gt; to debug an application then if I issue a command like "b main", then gud buffer gets no response back. The gdb prompt will only appear if I type C-c C-c. M-x gdb works for simple applications but have other issues when debugging more complicated applications, thus I can not use M-x gdb too. my gdb version is 7.6. and application is compiled with the following gcc version: $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: /build/src/gcc-4.8-20130502/configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/ --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared --enable-threads=posix --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch --enable-gnu-unique-objec</pre> support< at >torapp.info 2013-05-21T13:19:50 http://permalink.gmane.org/gmane.emacs.bugs/74432 <pre>I've got another hung session, with a newer version of Emacs: In GNU Emacs 24.3.50.1 (i686-pc-mingw32) of 2013-05-17 on LEG570 Bzr revision: 112622 eliz&lt; at &gt;gnu.org-20130517093654-eu3txjz42z99r29y Windowing system distributor `Microsoft Corp.', version 5.2.3790 Configured using: `configure --prefix=/c/usr --enable-checking CFLAGS='-O0 -g3' CPPFLAGS='-DGLYPH_DEBUG=1 -I/c/usr/include'' But the call stacks I've got with Process Explorer are different (and strange), because I see no frames inside Emacs, in any of the threads: * ID: 584 * State: Wait:UserRequest * Stack: ntoskrnl.exe+0x20908 ntoskrnl.exe+0x1fb2e ntoskrnl.exe+0x10e63e ntoskrnl.exe+0x234cb ntdll.dll+0x285ec ntdll.dll+0x3d281 ntdll.dll+0x2f20c ntdll.dll+0x2f336 ntdll.dll+0x2f2a3 * ID: 3216 * State: Wait:UserRequest * Stack: ntoskrnl.exe+0x20908 ntoskrnl.exe+0x1fb2e ntoskrnl.exe+0x10e63e ntoskrnl.exe+0x234cb ntdll.dll+0x285ec ntdll.dll+0x3d281 ntdll.dll+0x2f20c ntdll.dll+0x2f336</pre> Dani Moncayo 2013-05-21T07:01:01 http://permalink.gmane.org/gmane.emacs.bugs/74431 <pre> % emacs24 -Q --batch -f batch-byte-compile eme.el In toplevel form: eme.el:3:1:Warning: global/dynamic var `ll' lacks a prefix eme.el:13:1:Error: Symbol's value as variable is void: ll % So the code has a problem, since byte-compiling it doesn't work (emacs24 is 24.1, here). No wonder eager macro-expansion also leads to problems. Stefan </pre> Stefan Monnier 2013-05-21T02:11:15 http://permalink.gmane.org/gmane.emacs.bugs/74430 <pre> Thanks for the report. I can reproduce this in 24.3, but not current trunk, so it seems to already be fixed. Can you check trunk and confirm? </pre> Glenn Morris 2013-05-21T02:12:29 http://permalink.gmane.org/gmane.emacs.bugs/74429 <pre>Delete your .emacs.desktop, and put in init.el: (desktop-save-mode 1) (add-hook 'deactivate-mark-hook (lambda () (setq cursor-type t))) (add-hook 'activate-mark-hook (lambda () (setq cursor-type 'bar))) Start Emacs 24.3, open a file, press C-SPC C-g, then exit Emacs and save the desktop, then restart Emacs. Notice that the cursor type is now a bar, not a block. It should be a block. The attached patch fixes it. It could be fixed without patching set-mark, by conditionally calling deactivate-mark in desktop-create-buffer after calling set-mark, but that's a hack; the mark shouldn't be activated in the first place. Besides that, I need a dont-activate option for set-mark in some of my other code, so this bug gives me an excuse to add it. The attached patch relies on the fix for bug 13027, which was reportedly applied last November, but didn't make it into 24.3, so either apply that to 24.3, or use the current development version, but I haven't tried the latter. </pre> Kelly Dean 2013-05-21T02:06:43 http://permalink.gmane.org/gmane.emacs.bugs/74428 <pre> Fast is good, but that would be simply wrong. Stefan </pre> Stefan Monnier 2013-05-21T01:55:33 http://permalink.gmane.org/gmane.emacs.bugs/74427 <pre>BTW, the current symbol is incorrectly highlighted when `hi-lock-face-buffer' is called from isearch. This should be fixed by this patch: === modified file 'lisp/isearch.el' --- lisp/isearch.el2013-05-18 22:46:59 +0000 +++ lisp/isearch.el2013-05-20 23:27:28 +0000 &lt; at &gt;&lt; at &gt; -1773,7 +1791,10 &lt; at &gt;&lt; at &gt; (defun isearch-highlight-regexp () (isearch-done nil t) (isearch-clean-overlays)) (require 'hi-lock nil t) - (let ((string (cond (isearch-regexp isearch-string) + (let ((string (cond ((functionp isearch-word) + (funcall isearch-word isearch-string)) + (isearch-word (word-search-regexp isearch-string)) + (isearch-regexp isearch-string) ((if (and (eq isearch-case-fold-search t) search-upper-case) (isearch-no-upper-case-p It still can't correctly set `case-fold-search' for hi-lock, but this can't be improved because hi-lock is based on font-lock when font-lock is enabled in the buffer, and changing `font-lock-keywords-case-fold-search' to the same value as `isearch-ca</pre> Juri Linkov 2013-05-20T23:28:21 http://permalink.gmane.org/gmane.emacs.bugs/74426 <pre>Starting from emacs -Q: M-x c-mode &lt;RET&gt; C-x h &lt;BACKSPACE&gt; Type the text "#include &lt;stdio.h&gt;" C-Space C-a C-w C-y C-y M-/ This causes a segmentation fault, I can't even imagine why. I've found that any last line of text beginning with the '#' character, cannot be yanked, and then have that yank undone, without emacs crashing. It's very specific, but also very detrimental. $ gdb 'emacs' GNU gdb (GDB) 7.6 Copyright (C) 2013 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later &lt;http://gnu.org/licenses/gpl.html&gt; This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "i686-pc-linux-gnu". For bug reporting instructions, please see: &lt;http://www.gnu.org/software/gdb/bugs/&gt;... Reading symbols from /usr/bin/emacs-24.3...(no debugging symbols found)...done. (gdb) run -Q Starting program: /usr/bin/emacs-24.3 -Q warning: Could not load shared library s</pre> Jesse 2013-05-20T22:58:18 http://permalink.gmane.org/gmane.emacs.bugs/74425 <pre>Version: 24.3.50 This was fixed recently in bug#13923, so I'm closing this report. </pre> Juri Linkov 2013-05-20T22:50:58 http://permalink.gmane.org/gmane.emacs.bugs/74424 <pre>This feature request mostly doesn't depend on the outcome of bug#14405. I don't know why Jambunathan didn't propose this feature earlier, but it logically follows from his other improvements in hi-lock.el, i.e. the feature that doesn't ask for a face and automatically uses the next face from the list of available faces suggests also a command that doesn't ask for a symbol and automatically uses the symbol at point: === modified file 'lisp/hi-lock.el' --- lisp/hi-lock.el2013-03-31 13:34:35 +0000 +++ lisp/hi-lock.el2013-05-20 22:52:54 +0000 &lt; at &gt;&lt; at &gt; -483,6 +461,27 &lt; at &gt;&lt; at &gt; (defun hi-lock-face-phrase-buffer (regex (unless hi-lock-mode (hi-lock-mode 1)) (hi-lock-set-pattern regexp face)) +;;;###autoload +(defalias 'highlight-symbol-at-point 'hi-lock-face-symbol-at-point) +;;;###autoload +(defun hi-lock-face-symbol-at-point () + "Set face of each match of the symbol at point. +Use `find-tag-default-as-symbol-regexp' to retrieve the symbol at point. +Use non-nil `hi-lock-auto-select-face' to retrieve the next face</pre> Juri Linkov 2013-05-20T22:54:34 http://permalink.gmane.org/gmane.emacs.bugs/74423 <pre> Ping? </pre> Reuben Thomas 2013-05-20T22:21:48 http://permalink.gmane.org/gmane.emacs.bugs/74422 <pre> I see, and reading a bit of tls.el it makes sense. It does all this crazy regexp searching... This is a hack in my book too, albeit one that's been working fine, Here is a patch that should be equivalent to the defadvice I'm using. As I said, it works for me. Also I didn't have a VC copy of emacs so I used `diff-buffer-with-file' diff -u -L /usr/local/share/emacs/24.3/lisp/net/tls.el.gz -L \#\&lt;buffer\ tls.el.gz\&gt; /tmp/jka-com1909LVh /tmp/buffer-content-1909lpt --- /usr/local/share/emacs/24.3/lisp/net/tls.el.gz +++ #&lt;buffer tls.el.gz&gt; &lt; at &gt;&lt; at &gt; -286,7 +286,11 &lt; at &gt;&lt; at &gt; (format "Host name in certificate doesn't \ match `%s'. Connect anyway? " host)))))) (setq done nil) -(delete-process process))) +(delete-process process)) + ;; delete all the informational messages that could + ;; confuse futures users of `buffer' + ;; + (delete-region (point-min) (point))) (message "Opening TLS connection to `%s'...%s" host (if done "done" "failed")) (when use-temp-buffer João </pre> João Távora 2013-05-20T22:07:30 http://permalink.gmane.org/gmane.emacs.bugs/74421 <pre>We see this in the opening paragraph, "no argument is equivalent to an argument of one". It's not always the case, as in the example for C-u 1 C-k, which removes both the text and the newline. Maybe there's other examples I don't know about. </pre> Tshepang Lekhonkhobe 2013-05-20T20:39:54 http://permalink.gmane.org/gmane.emacs.bugs/74420 <pre>The Python style guide, http://www.python.org/dev/peps/pep-0008/, says: At present, Emacs uses the former style. I'd prefer there to be an option to enable use of the latter style. I am preparing a patch. </pre> Peter Oliver 2013-05-20T15:02:01 http://permalink.gmane.org/gmane.emacs.bugs/74419 <pre> What risk? what responsibility? A user who installs software on her computer is already trusted with certain responsibilities, because a single mistyped command or a badly built package can easily shut down a perfectly healthy system for hours, if not days. Users install dozens of packages needed to create a workable environment for whatever they need to accomplish. Why is GnuTLS so special? And mind you, in view of the latest sparring between GnuTLS developers and the FSF (which I have no idea how ended, except that the license was downgraded a bit and the official site moved), I'm not even sure the FSF will agree to distribute GnuTLS with Emacs, on any platform. Why should Emacs development enter this minefield? And for what? for solving a non-existing problem of installing a simple package? Don't we have better places to apply our time and energy? Don't misunderstand me: if someone decides to provide regular builds of GnuTLS ready to be downloaded and installed, I will applaud that person. Heck, </pre> Eli Zaretskii 2013-05-20T16:28:40 http://permalink.gmane.org/gmane.emacs.bugs/74418 <pre>My apologies. I'm running Emacs 24.2, but I see that the changes to python-mode in 24.3 mean that my preferred behaviour is now what's used. Closing. </pre> Peter Oliver 2013-05-20T15:44:14 http://permalink.gmane.org/gmane.emacs.bugs/74417 <pre>Am 20.05.2013 15:27, schrieb Reuben Thomas: GNU Emacs 24.3.1 (i686-pc-linux-gnu, GTK+ Version 2.24.14) of 2013-03-05 M-x flymake-mode RET toggles it right from the spot. Andreas </pre> Andreas Röhler 2013-05-20T14:32:48 http://permalink.gmane.org/gmane.emacs.bugs/74416 <pre>On Sun, 19 May 2013 18:32:37 +0300 Eli Zaretskii &lt;eliz&lt; at &gt;gnu.org&gt; wrote: EZ&gt; I see no problems with the current situation. Installing precompiled EZ&gt; GnuTLS from a zip file is a snap. That's only a small part of the risk and responsibility we're shifting onto the Emacs users. Ted </pre> Ted Zlatanov 2013-05-20T13:56:27 http://permalink.gmane.org/gmane.emacs.bugs/74415 <pre>Let find-gnu-message.el contain: (progn (switch-to-buffer "*Messages*") (goto-char (point-min)) (let ((case-fold-search t)) (re-search-forward "gnu"))) With Emacs 24.3: emacs -Q --load find-gnu-message.el The string "GNU" is found in the *Messages* buffer. Do the same thing with Emacs from trunk. "GNU" is not found. As discussed at https://bitbucket.org/lyro/evil/issue/286/evil-search-with-smart-evil-ex-search-case, the implicated commit is: b7139a2e8b2dc9c06507909cd863d0c124388f91 is the first bad commit commit b7139a2e8b2dc9c06507909cd863d0c124388f91 Author: Stefan Monnier &lt;monnier&lt; at &gt;iro.umontreal.ca&gt; Date: Wed Mar 27 10:33:03 2013 -0400 * lisp/case-table.el (case-table-get-table): New function. * lisp/case-table.el: Use lexical-binding. (case-table-get-table): New function. (get-upcase-table): Use it. Mark as obsolete. Adjust callers. * src/casetab.c (init_casetab_once): Don't abuse the ascii eqv table for the upcase table. --- In GNU Emacs 24.3.50.2 </pre> Barry OReilly 2013-05-20T13:43:27 http://permalink.gmane.org/gmane.emacs.bugs/74414 <pre> Ping? I've been using this setting in my init file without problems for a while now… </pre> Reuben Thomas 2013-05-20T13:27:03 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.emacs.bugs