gmane.emacs.devel

Add a paragraph describing a package

Ivan Kanis — 2013-06-19T13:44:11

I am going through all the packages in marmalade and my brain is getting
numb.

Some packages seem interesting but I can't tell from the one line
summary.

I feel that it is not giving me enough information. Like the Debian
package manager there should be a paragraph giving more details.

The paragraph would be displayed when pressing RET on a line in the
package list. It would appear next to the 'install' button. It would be,
of course, optional.

Is there interest for this feature?

24.3 linux runaway emacs processes

Neal Becker — 2013-06-19T12:52:00

I've been using 24.3 for a while on fedora 18 linux.  I remotely connect
every day using ssh -X emacs.

Frequently I come in the next morning to find a emacs process running away with 
100% cpu.  This did not happen with 24.2.  I use emacs all day, every day, so I
would certainly notice such things.

GNU Emacs 24.3.1 (x86_64-redhat-linux-gnu, GTK+ Version 3.6.4)
 of 2013-04-19 on nbecker7

request to revert the chnage of revno 112925

Kenichi Handa — 2013-06-19T11:54:13

I'd like to revert the following change (revno 112925):

2013-06-11  Stefan Monnier  <monnier< at >iro.umontreal.ca>

* international/mule-conf.el (file-coding-system-alist): Use utf-8 as
default for Elisp files.

By my recent changes for tuning up ASCII and UTF-8 file
reading, the speed for reading a UTF-8 file is almost the
same in the following cases:

* the file has coding: utf-8; tag
* find-operation-coding-system returns utf-8 for the file
  (the current case of *.el files)
* the file has no coding tag and utf-8 is the most preferred
  coding system
* the file has no coding tag and utf-8 is the most preferred
  coding system among 8-bit encoding (which means that such
  7-bit coding systems as iso-2022-jp may be more preferred)

So, the above change does not improve the performance that
much.

In addition, as iso-2022-jp and iso-2022-7bit have been the
most correctly detected coding systems in any environments,
there are many packages that uses them for *.el files (at
least in Japan).  Now many of them do

Fixed for namazu.el and gnus-nzm-1.el

Adam Sjøgren — 2013-06-18T20:48:19

  Hi.


After this recent change in GNU Emacs:

 * http://article.gmane.org/gmane.emacs.diffs/120871

The elisp files namazu.el and gnus-nzm-1.el no longer byte-compile.

The fix is to add a coding: cookie, similar to this, done on a file in
the same situation in auctex:

 * http://lists.nongnu.org/archive/html/emacs-elpa-diffs/2013-06/msg00005.html

i.e. change the first line to:

  ;;; namazu.el --- Support for Namazu.  -*- coding: iso-2022-jp-unix; -*-

and

  ;;; gnus-nmz-1.el --- interface between Namazu and Gnus.  -*- coding: iso-2022-jp-unix; -*-

respectively.

I hope this can be included in a future release of Namazu.


  Cheers!

    Adam

Build failure on MS-Windows

Dani Moncayo — 2013-06-18T10:54:41

Hi,

I've just tried to build from scratch the last trunk version of Emacs
on MS-Windows, but the build fails here:

[...]
Loading abbrev...
Loading simple...
Invalid function: with-eval-after-load
mv: cannot stat `emacs.exe': No such file or directory
Makefile:823: recipe for target `bootstrap-emacs.exe' failed
make[1]: *** [bootstrap-emacs.exe] Error 1
make[1]: Leaving directory `/c/msys/home/dani/emacs/build/src'
Makefile:381: recipe for target `src' failed
make: *** [src] Error 2

--
Dani Moncayo

[PATCH] Add `notes' function to store random notes across Emacsrestarts.

Michal Nazarewicz — 2013-06-17T16:13:04

From: Michal Nazarewicz <mina86< at >mina86.com>

You may think of it as a *scratch* buffer whose content is preserved.
In fact, it was designed as a replacement for *scratch* buffer and can
be used that way by setting `initial-buffer-choice' to 'notes an
`notes-buffer-name' to "*scratch*".  Without the second
change, *scratch* buffer will still be there for notes that do not
need to be preserved.

* list/startup.el (notes): New function creating notes buffer.
(notes-file, notes-recover-from-auto-save-file, notes-buffer-name)
(initial-notes-major-mode): New customize variables for customizing
behaviour of the notes buffer.
(notes--bury-on-kill-buffer, notes--insert-content): New helper
functions for `notes' function.
(notes--buffer): New helper variable for `notes' function.
(notes--initial-message): New helper constant for `notes' function.
---
 etc/NEWS        |   8 +++
 lisp/ChangeLog  |   8 +++
 lisp/notes.el   | 205 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 lisp/startup.el |   3 +-
 lisp/wind

EXC_BAD_ACCESS on Mac

Kazu Yamamoto — 2013-06-17T03:36:14

Hi all,

I'm using Emacs HEAD ("24.3.50.1") on Mac. It *often* crashes when I'm
reading e-mail messages with Mew. I took trace with gdb. The value of
"glyph" is 0x5bfe and this causes EXC_BAD_ACCESS.

If other information is necessary to fix this bug, please let me know.

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: 13 at address: 0x0000000000000000
0x000000010001b317 in get_glyph_face_and_encoding (f=0x10c408758, glyph=0x5bfe, char2b=0x7fff5fbfb790, two_byte_p=0x7fff5fbfb754) at xdisp.c:22544
22544code = face->font->driver->encode_char (face->font, glyph->u.ch);
(gdb) info stack
#0  0x000000010001b317 in get_glyph_face_and_encoding (f=0x10c408758, glyph=0x5bfe, char2b=0x7fff5fbfb790, two_byte_p=0x7fff5fbfb754) at xdisp.c:22544
#1  0x000000010001b44d in fill_glyph_string (s=0x10c408758, face_id=1606399872, start=1606399888, end=1606399828, overlaps=677) at xdisp.c:22766
#2  0x000000010001bded in draw_glyphs (w=0x10c408758, x=8, row=0x7fff5fbfb790, area=1606399828, start=677, end

About elements in `format-alist'

Xue Fuqiao — 2013-06-16T23:02:21

Hi list,

In the doc string of `format-alist':

  Elements are of the form
  (NAME DOC-STR REGEXP FROM-FN TO-FN MODIFY MODE-FN PRESERVE).

There should be 8 elements in each list.  But there are only 7 elements
in each list of the default value.  Which one is absent?  If there's an
optional element, I think we should mention it in the doc string.

--
Best regards, Xue Fuqiao.
http://www.gnu.org/software/emacs/

Question about todos.el copyright and author headers

Stephen Berman — 2013-06-16T22:53:41

Before I install todos.el (the new version of Todo mode), I'd like to
request clarification about the copyright and author headers.
Currently, I've written them like this:

;; Copyright (C) 1997, 1999, 2001-2013  Free Software Foundation, Inc.

;; Author: Oliver Seidel <privat< at >os10000.net> (original: todo-mode.el)
;;Stephen Berman <stephen.berman< at >gmx.net> (new: todos.el)

The copyright years are those of todo-mode.el.  My model here is js.el,
which was added to Emacs in 2009:

;; Copyright (C) 2008-2013 Free Software Foundation, Inc.

;; Author: Karl Landstrom <karl.landstrom< at >brgeight.se>
;;         Daniel Colascione <dan.colascione< at >gmail.com>

In 2008 the sole author was Landstrom, and the file was named
javascript.el.  Likewise, the sole author of the original todo-mode.el
was Seidel.  One difference between the situation with js.el and that
with todos.el is that AFAIK javascript.el was never part of Emacs under
that name.  However, todos.el cannot be installed as todo-mode.el
because the latter is not be

eww

Lars Magne Ingebrigtsen — 2013-06-16T14:53:57

eww probably has a lot of stuff that could still be fixed up, but the
basics are working now.  That is, you can search for stuff on Google and
visit Wikipedia.  :-)

I wrote it up a bit here:

http://lars.ingebrigtsen.no/2013/06/eww.html

Setting the background colour of a buffer or window

Lars Magne Ingebrigtsen — 2013-06-16T13:32:21

There still apparently isn't a way to set the background colour of a
buffer (or a window)?  You have to set the background colour of the
entire frame?

For eww, it would be really, really nice if it were possible to set the
background colour of the buffer.  That would be much more natural than
putting the background colour over every character in the buffer with
text properties.

Although while writing this, I now see that I could probably just do
exactly that in eww, since eww commands the entire buffer.  Probably not
for shr, though.

So, er, uhm.  Well, it would be nice in general to have that
functionality, even though eww probably can do without.  :-)

Is there any chance of that being added?

Interface of prog-prettification

Juanma Barranquero — 2013-06-16T01:56:12

A few questions about the new prog-prettification.

- prog--prettify-font-lock-compose-symbol's docstring says:
  "Compose a sequence of ascii chars into a symbol."

It is really true that it must be a sequence of ASCII characters? Why?

- Docstring of prog-prettify-symbols says:
  "When set to an alist in the form `((STRING . CHARACTER)...)'"

But in fact, instead of CHARACTER you can use a string, and its
characters will be "composed" (stacked) together.

- I don't fully understand how the user is supposed to extend the
default modes' prog-prettification. What is the expected interface?
Customizing prog-prettify-symbols sets the value for all prog-derived
modes, but what if I want to use different prettifications for
different modes?

I tried adding (set (make-local-variable 'prog-prettify-symbols)
'(("my-symbol" . ?MYCHAR))) to the relevant mode-hook, but that does
not work.

pushing '("my-symbol" . ?MYCHAR) to the corresponding mode-specific
alist (lisp--prettify-symbols-alist,
cfengine3--prettify-symbol

Built-in package resolution broken?

Sebastian Wiesner — 2013-06-15T19:03:54

Hello,

in latest trunk, installing a package that depends on "eieio" 1.3
fails with an error stating that "Package `eieio-1.3' is unavailable".

However, "eieio" is available in version 1.4.  Isn't package.el
supposed to accept higher versions?

Sincerely,
Sebastian Wiesner

package-installed-p broken

Sebastian Wiesner — 2013-06-15T19:01:39

Hello,

after "package-install", "package-installed-p" still returns nil for
the package that was just installed.  Consider:

ELISP> (package-installed-p 'nrepl)
nil
ELISP> (package-install (cdr (assq 'nrepl package-archive-contents)))
nil
ELISP> (package-installed-p 'nrepl)
nil
ELISP> (package-initialize)
t
ELISP> (package-installed-p 'nrepl)
t

Also, before "package-initialize", the newly installed "nrepl" package
still appears as "available", but not as "installed" in "M-x
list-packages".

Even worse, dependency resolution is now broken, likely as a result of
this misbehavior of "package-installed-p".  Consider "hardhat" and
"ignoramus", where "hardhat" depends on "ignoramus".  If I explicitly
install "ignoramus", "hardhat" cannot be installed afterwards:

ELISP> (package-installed-p 'ignoramus)
nil
ELISP> (package-installed-p 'hardhat)
nil
ELISP> (cdr (assq 'hardhat package-archive-contents))
[cl-struct-package-desc hardhat
                        (20130522 1243)
                        "Protect against

at risk

Andreas Röhler — 2013-06-15T11:54:39

When execution might rely on variables set by user, resp. at a later time, such a function should preferably not be used by programs, i.e.
in circumstances being with some probability not aware of the changed proceeding.

This is the case for example with `forward-sexp', which might be taken by `forward-sexp-function'.

Please consider bug#14611. Being concerned a certain amount of code is set already at risk that way.

Thanks,

Andreas

Help with gdb-mi.el + (possibly) comint.el + backslashes

Sergio Durigan Junior — 2013-06-15T04:46:12

Hey there,

I've been debugging gdb-mi.el in order to fix an annoying bug, but so
far haven't understood how to fix it.

The bug is basically that gdb-mi.el doesn't recognize backslashes for
wrapped lines, so something like:

    (gdb) run \
      ARG1 \
      ARG2

Fails with:

    Undefined command: "ARG2".  Try "help".

This is because "gdb-send" (inside gdb-mi.el) is receiving the wrong
arguments every time the user presses RET (I debugged the function and
noticed that it is receiving each line separately as if they were single
commands, which can also be confirmed by the error message).  Initially
I thought it could be fixed inside gdb-mi.el itself, but then my
attention was dragged to comint.el (since shell.el uses it and accepts
backslashes normally), but so far I couldn't figure out how to solve
this issue.

I tried setting some comint.el variables inside gdb-mi.el
(comint-prompt-regexp, or comint-delimiter-argument-list, for example),
without success.  So now I'm asking your opinion.  Any hints on h

When should I use "`" and "'" in NEWS?

Xue Fuqiao — 2013-06-15T02:51:58

Hi list,

In etc/NEWS[fn:1], I found this sentence:

  You should either convert them to utf-8 or add an explicit coding:
  cookie.

I expected a "`" and a "'" around the "coding:" cookie, but there's
none.  So I have a question: when should we add these delimiters?  I
can't find a reference/convention documentation.

IMHO at least these things need those delimiters:
  * Lisp symbols
  * Configure options

and there are something I'm uncertain about:
  * Key sequences
  * Code span (I think "coding:" cookie is belong to this category)
  * "Modules" (like those in Eshell and Org)
  * Library/package names (with or without `.el')
  * Value of Lisp variables
  * Value returned by functions/lambda/primitives/macros

Footnotes:

[fn:1] http://bzr.savannah.gnu.org/lh/emacs/trunk/revision/112957

--
Best regards, Xue Fuqiao.
http://www.gnu.org/software/emacs/

erc and notify-via-dbus breaks scroll position in channel buffers

Barry Warsaw — 2013-06-13T18:57:38

I recently upgraded to Emacs 24.3 from 24.2 in Ubuntu 13.10 and I noticed a
weird regression in erc.  When someone pinged my nick, the channel buffer
would scroll the current line to the top, so I'd have to manually recenter the
buffer to read the scrollback.

After a lengthy debugging session, I traced the problem down to
notify-via-dbus.  AFAICT, here's what's happening.

I add a hook to erc-text-matched-hook so that when my nick appears in a
channel, I get a notification in the on-screen display (osd).  This was
working beautifully in 24.2.  It calls (notify) which in turn calls whatever
notify-method is set too.  In 24.3 and 24.2 this is set by default to
notify-via-dbus.  e.g:

(defun baw-notify-erc (match-type nickuserhost message)
  "Notify when a message to my nick is received"
  (notify (format "%s in %s"
                  ;; Username of sender
                  (car (split-string nickuserhost "!"))
                  ;; Channel
                  (or (erc-default-target) "#unknown"))
          ;; Rem

About prog-prettify-symbols

Tassilo Horn — 2013-06-13T15:09:00

Hi all,

I have some issues with `prog-prettify-symbols'.

1. I'd like to get it working with clojure-mode [fn:1].  In clojure,
   `fn' is what `lambda' is in elisp or common lisp.  So I added

--8<---------------cut here---------------start------------->8---
(setq prog-prettify-symbols t)
(add-hook 'clojure-mode-hook
  (lambda ()
    (prog-prettify-install '(("fn" . ?ƒ)))))
--8<---------------cut here---------------end--------------->8---

   to my .emacs.  Unfortunately, when I open a clojure file now, (fn
   ...) is correctly displayed as (ƒ ...), but also (lambda ...) is
   shown using a greek letter.  And most clojure functions and macros
   aren't highlighted any more.

   The reason is that the value of `font-lock-keywords' has nothing to
   do with its original value setup by clojure-mode without the
   prettification.  Basically, the value looks like the correct value
   for `emacs-lisp-mode' + the prettification for lambda and fn.

   Then I added

--8<---------------cut here---------------star

non-ascii in committer names?

2013-06-13T08:47:34

Can the commiter name contain non-ascii with bzr?

I'm asking because I'm experiencing this issue:
https://github.com/felipec/git/issues/38

As far as I can determine non-ascii committer names doesnt work with
bzrlib, but I might be wrong.

In order to push the patches to bzr on Savannah, I need to resolve this
issue somehow.

The patches in question are here:
https://github.com/jave/xwidget-emacs/pull/1

Any suggestions?

Heres what I can come up with:

- Squash the committer name to ascii: That doesnt feel right, but if
 thats the convention, so be it.

- Fix bzrlib: I'm not sure it's a bug. The trace seems to indicate it's
  intended behaviour.

I would rather not stop updating the savannah repo, and I would rather
not stop using git-remote-bzr, if at all possible.

Thanks,

thing-at-point's meaning of current sexp vs. up-list's: which iscorrect?

Kelly Dean — 2013-06-12T13:23:51

If point is on a closing delimiter, then thing-at-point says the delimiter is part of the current sexp, but up-list says the delimiter is part of the sexp that contains the current sexp.
The result is that kill-backward-up-list, which assumes that thing-at-point and up-list have the same meaning for current sexp, fails when point is on a closing delimiter: type "((a))" and put point on the first closing parenthesis, then do kill-backward-up-list, and it reinserts the same sexp that it kills, leaving the text unchanged.
I'll file a bug report, but should I file it for thing-at-point, or for up-list? Surely not for kill-backward-up-list.