headers
Drew Adams | 1 Nov 2009 01:04
Picon
Favicon

bug#4835: 23.1; Improper `Invalid face reference' messages. Performance degraded.

> > You haven't given one reason why this should be limited to 
> > a symbol. Show why `functionp' is problematic, and you
> > might have an argument.
> 
> I'm afraid I don't have time to wade through the sea of 
> words, but I've stated that it would be nice if a lambda
> expression can be used.  But I doubt it's worthwhile to
> change this for 23.2.

Why? Why wouldn't it be worthwhile to change `fboundp' to `functionp'?

> Assuming there's no third-party code relying on using a
> lambda expression (which does not work properly), for
> now we should simply document the case that works.

Then please consider fixing this to allow all functions for 23.3, if you don't
want to fix it now. Do I need to file another bug report for that?

In any case, _this_ bug is about the `Invalid face reference' messages and
performance degradation. I get those messages even when using a symbol function,
so this bug is not fixed by simply adding a restriction to symbols.

If I'm mistaken and have missed something, please advise. I will be happy if I
can get the function to work without provoking those bizarre error messages and
slowing Emacs to a crawl. I don't have a problem with using a symbol function
instead of a lambda.

IOW, for Emacs generally, I agree with you that "it would be nice if a lambda
expression can be used" at some point. But my concern now is the `Invalid face
reference' messages. I corrected the code to use a symbol, not a lambda, but the
(Continue reading)

Permalink | Reply | 6 comments |
headers
Richard Stallman | 1 Nov 2009 03:31
Picon
Picon

bug#4837: with-fewer-warnings ?

    Eg (with-fewer-warnings '(obsolete cl-functions) ...)

    would not warn about obsolete things or cl-functions in the body. The
    possible arguments are the members of byte-compile-warnings.

    I can implement this if it is considered worth it (it's very similar
    to with-no-warnings).

I think it isn't worth doing, because it would only gain you very much
if you put a lot of code inside with-no-warnings; we avoid doing that.
Permalink | Reply | 4 comments |
headers
Helmut Eller | 1 Nov 2009 09:25
Picon

bug#4845: 23.1.50; Uninterned symbols in .elc files


In GNU Emacs 23.1.50.1 (i686-pc-linux-gnu, GTK+ Version 2.12.11)
loading a file x.el with contents

 (defmacro foo ()
   (let ((sym (make-symbol "bar")))
     `(progn
        (defun ,sym () (message "function %s called" ',sym))
        (,sym))))

 (foo)

works as expected:

 shell> emacs -Q -batch -load x.el
 function bar called

However loading the corresponding compiled file signals an error:

 shell> emacs -Q -batch -eval '(byte-compile-file "x.el")' -load x.elc
 Wrote /tmp/x.elc
 Symbol's function definition is void: bar
 [Exit 255]

There is a #1=#:bar in the constant pool of the compiled function but #1
isn't used at the call site.

Helmut
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jan Djärv | 1 Nov 2009 13:45
Picon

bug#4843: creating menus

Daniel Carvalho skrev:
> hi
> when I recently upgraded to Ubuntu 9.10 the elisp code to create menus
> stop working.
> 
> Consider example in http://xahlee.org/emacs/elisp_menu.html
> It creates the menu "MyMenu", but the menu itens inside it don't show!
> 
> The emacs version didn't change: GNU Emacs 22.2.1
> 
> Anyone else had this problem? how to solve it?

It can be because you are now using a newer Gtk+ version.  Please use 
report-emacs-bug so we can see that at once instead of having to ask.

If indeed you are using Gtk+, it is due to the introduction of native windows.
To see if this is the case, start emacs with
% GDK_NATIVE_WINDOWS=1 emacs
and try again.

	Jan D.
Permalink | Reply | 2 comments |
headers
Eli Zaretskii | 1 Nov 2009 19:33
Picon

bug#4816: change of coding system without inquiry

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Date: Fri, 30 Oct 2009 11:02:49 -0400
> Cc: 4816 <at> emacsbugs.donarmstrong.com
> 
> I think you're right that we should at least do a y-or-n-p prompt
> when changing the buffer-file-coding-system, unless the change is to
> a "superset coding system" (like from us-ascii to latin-1).

FWIW, in the past users explicitly expressed annoyance by these
questions.  The request was to use the "native" encoding silently.  By
introducing back this question, we are restoring that annoyance.
Permalink | Reply | 1 comment |
headers
Michael Albinus | 1 Nov 2009 19:53
Picon
Picon
Gravatar

bug#4842: 23.1.50; tramp-gvfs-dbus-event-error: Connection ":1.35" is not allowed to add more match rules

"Roland Winkler" <Roland.Winkler <at> physik.uni-erlangen.de> writes:

> I wish I knew what triggered this bug and what it means!
> Recently, I get occassionally the error message
>
> tramp-gvfs-dbus-event-error: Connection ":1.35" is not allowed to
> add more match rules (increase limits in configuration file if required)
>
> As far as I could find out, the message is not generated by emacs.
> Yet I am confused that tramp picks up this error message.
> This happens with ubuntu intrepid.
>
> Even if the error message ultimately has nothing to do with emacs,
> it might help if tramp handled it in a way that made it easier for
> the user to put this message into perspective. (Yet as I do not know
> what the message means, I do not no either whether such a thing was
> feasible for tramp.)

tramp-gvfs uses D-Bus. The message above comes from D-Bus, it is related
to Tramp.

I agree, that it shall be transformed into something understandable by
the user. I will check how I could do it.

However, I also would like to know where it comes from. Which Tramp
method have you used? Did you enable Tramp traces (by setting
tramp-verbose to 8), so I could check them?

Best regards, Michael.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Michael Albinus | 1 Nov 2009 19:44
Picon
Picon
Gravatar

bug#4841: 23.1.50; tramp su/sudo makes vc-dir hang (found remote shell ...)

Stefano Zacchiroli <zack <at> upsilon.cc> writes:

> To edit system configuration files, I'd like to use tramp's su:: or
> sudo::. What blocks me to do that is that I have versioned /etc (with
> etckeepr over Git) and I need to commit the performed changes
> afterwards.
>
> When not inside su::/sudo:: I often commit stuff in Git repositories
> using vc-mode. That unfortunately does not work under tramp's
> su::/sudo::. Trying to do that results in vc-dir hanging forever just
> after the "found remote shell on ..." message and the correspondent
> "waiting" message in the vc buffer if I stop Emacs with C-g.

Looks to me like vc-git is waiting for a password, or something like
this. Could you, please, check the *tramp ...* buffer, whether you see a
corresponding message?

If there is nothing obvious, you might set `tramp-verbose' to 8, and
rerun the test. The corresponding debug buffer of Tramp shall tell us
what happened.

> Many thanks in advance,
> Cheers

Best regards, Michael.
Permalink | Reply | 9 comments |
headers
Roland Winkler | 1 Nov 2009 22:47
Picon
Picon
Favicon

bug#4842: 23.1.50; tramp-gvfs-dbus-event-error: Connection ":1.35" is not allowed to add more match rules

On Sun Nov 1 2009 Michael Albinus wrote:
> However, I also would like to know where it comes from. Which Tramp
> method have you used? 

Recently, I have been using tramp very rarely. In the current emacs
session that gives me these messages I haven't used it at all
(intentionally).

(I do have from old times a (require 'tramp) in my .emacs, but there
is no further customization or any other intentional reference to
tramp in my current emacs sesion.)

> Did you enable Tramp traces (by setting tramp-verbose to 8), so I
> could check them?

I've done that in my .emacs. Up to now it hasn't given me anything
helpful (though I got more messages from tramp-gvfs-dbus-event-error
about these match rules). I'll let you know if I get anything
useful.

Roland
Permalink | Reply | 2 comments |
headers
Stefano Zacchiroli | 1 Nov 2009 23:05
Picon
Favicon

bug#4841: 23.1.50; tramp su/sudo makes vc-dir hang (found remote shell ...)

On Sun, Nov 01, 2009 at 07:44:14PM +0100, Michael Albinus wrote:
> Looks to me like vc-git is waiting for a password, or something like
> this. Could you, please, check the *tramp ...* buffer, whether you see a
> corresponding message?

I've checked the *tramp ...* buffer and I found it empty.

> If there is nothing obvious, you might set `tramp-verbose' to 8, and
> rerun the test. The corresponding debug buffer of Tramp shall tell us
> what happened.

... so I've tried this, the *tramp ...* buffer was still empty, but the
*debug tramp ...* was not. I'm attaching its content, gzipped since it
is 160 Kb (yes, I've cleaned it up just before doing the test, but still
... :-).

AFAICT, in that log I see the password being delivered to su (I did the
test with the "/su::" prefix), luckily not reported in the log, and I
also see the prompt of a root shell clearly returned to tramp, so I
don't think the issue is the "waiting for a password". Rather, it looks
like that in the vc <-> tramp dialog someone fails to recognize that the
login has been properly done.

Thanks for your feedback,
Cheers.

--

-- 
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc  <at>  Univ. Paris 7
zack <at> {upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..|  .  |. Et ne m'en veux pas si je te tutoie
(Continue reading)

Permalink | Reply | 8 comments |
headers
Taylor R Campbell | 2 Nov 2009 00:09
Favicon

bug#4847: C++ Mode mistreats < and > as balanced delimiters

GNU Emacs 22.3.1 (i386-apple-darwin9.7.0, GTK+ Version 2.12.9) of 2009-08-10 on Oberon.local

In an empty buffer in C++ Mode, type

if (foo < bar) { }

and then change it to

if (foo < > bar) { }

and then change it back.

Now your buffer is in a bogus state, with Emacs thinking that the < is
mismatched with the ), and that there is nothing matching the (.

It is OK not to treat angle brackets as delimiters when they are, in
templates: it requires a little extra work by the user (to see, edit,
indent, &c., the balanced pairs), but doesn't break anything.

It is not OK to treat angle brackets as delimiters when they aren't,
in comparisons and shifts: it breaks the entire structure of the text
in the buffer, and thus it breaks swaths of commands that users use
all the time without thinking such as C-M-f and C-M-b.

If Emacs has the option of being clever about angle brackets in
templates, the user should have the option of disabling it because it
is incredibly frustrating when the cleverness fails.  But I couldn't
find any way to disable this broken cleverness, by aproposing for
`C++', by reading the CC Mode manual, or by skimming the (unbelievably
hairy) code.
(Continue reading)

Permalink | Reply | 2 comments |

Gmane