Michael Welsh Duggan | 1 Feb 2012 02:27

bug#10669: 24.0.93; Emacs daemon high CPU load

Chong Yidong <cyd <at> gnu.org> writes:

> Michael Welsh Duggan <md5i <at> md5i.com> writes:
>
>> In certain circumstances, emacs running in daemon mode ends up in a high
>> CPU state, and fills the .xsession-errors log with large numbers of
>> "Back to top level." messages.  I am using a freshly bootstrapped bzr
>> trunk checkout of emacs from 2012.01.29.
>>
>> Here follows the minimal set of steps I was able to determine that
>> recreates the problem.  Small deviations from this (such as not using
>> emacsclient) did not trigger the problem.  I am running Gnome 3 and the
>> gnome-shell, but have seen (although not tested in detail) this same
>> problem in a Gnome 2 desktop session.
>
> Can you reproduce this with Emacs 23.4, or is this specific to the
> trunk?

I can reproduce this with Emacs 23.4.

--

-- 
Michael Welsh Duggan
(md5i <at> md5i.com)

Chong Yidong | 1 Feb 2012 03:47
Picon

bug#8406: 23.3; cc-engine.el incorrectly classifies member-init-intro as member-init-cont

Alan Mackenzie <acm <at> muc.de> writes:

> The patch was just fine.  I've committed it to the trunk.

Thanks all.  Closing the bug.

Chong Yidong | 1 Feb 2012 03:49
Picon

bug#10682: 23.4; Corrupted libXpm.dll in Windows distribution of 23.4

Hi Christoph,

Could you take a look at this bug report?  Thanks.

Hideki Saito <hidekis <at> gmail.com> writes:

> The libXpm.dll file included in Windows binary version of Emacs 23.4 is
> corrupted that when the user loads Emacs off the shelf without any other
> libxpm.dll installed on the system elsewhere, Emacs displays toolbar
> icon in black and white pbm icon, instead of xpm.
>
> Workaround that worked at the point was to bring over libxpm.dll from
> 23.3 distribution.
>
> File size of libxpm.dll as included in emacs 23.4 is 218 bytes while it
> is 504419 bytes in 23.3, so it looks like the file is corrupted, and
> need to be repackaged.
>
> If Emacs crashed, and you have the Emacs process in the gdb debugger,
> please include the output from the following gdb commands:
>     `bt full' and `xbacktrace'.
> For information about debugging Emacs, please read the file
> c:/Users/hideki/bin/emacs/etc/DEBUG.
>
>
> In GNU Emacs 23.4.1 (i386-mingw-nt6.1.7601)
>  of 2012-01-29 on MARVIN
> Windowing system distributor `Microsoft Corp.', version 6.1.7601
> configured using `configure --with-gcc (4.5) --cflags
> -ID:/devel/emacs/libs/libXpm-3.5.8/include
(Continue reading)

Paul Eggert | 1 Feb 2012 07:10
Favicon

bug#10677: 24.0.93; missing pathmax.h on Solaris

I cannot reproduce the bug on my Solaris 10 box,
but I think I see the problem.  I installed a fix
into the trunk as bzr 107037; please give it a try
on your box.  Thanks.

Glenn Morris | 1 Feb 2012 08:38
Picon

bug#10650: view-mode inconsistencies wrt special mode-class

Stefan Monnier wrote:

>> The Lisp manual (node Basic Major Modes) says:
>>    Special mode is a basic major mode for buffers containing text
>>    that is produced specially by Emacs, rather than from a file.
>
> Then again, doc-view-mode is a special mode even though the PDF code is
> rarely if ever generated by Emacs.

I interpret special modes as being applicable to stuff where you won't
ever want to create an empty buffer and just start writing said stuff.
That covers PDFs, tar files, dired buffers, etc.

Personally I think a separate variable controlling which modes are
incompatible with view-mode would be better, but I'm not going to
complain if the definition of special modes is extended to cover this.

Chong Yidong | 1 Feb 2012 09:32
Picon

bug#10650: view-mode inconsistencies wrt special mode-class

Glenn Morris <rgm <at> gnu.org> writes:

> Stefan Monnier wrote:
>
>>> The Lisp manual (node Basic Major Modes) says:
>>>    Special mode is a basic major mode for buffers containing text
>>>    that is produced specially by Emacs, rather than from a file.
>>
>> Then again, doc-view-mode is a special mode even though the PDF code is
>> rarely if ever generated by Emacs.
>
> I interpret special modes as being applicable to stuff where you won't
> ever want to create an empty buffer and just start writing said stuff.
> That covers PDFs, tar files, dired buffers, etc.
>
> Personally I think a separate variable controlling which modes are
> incompatible with view-mode would be better, but I'm not going to
> complain if the definition of special modes is extended to cover this.

I changed view-buffer-other-* to behave like view-buffer.  (Could have
changed view-mode-enter instead, but that is called from other placed in
Emacs so it didn't seem worth the risk.)

Łukasz Michalik | 1 Feb 2012 12:33
Picon
Gravatar

bug#10683: 23.4; Reverse video doesn't work for -nw

On 17:39 2012-01-31 -0500, Dan Nicolaescu wrote:
> Could you say what terminal emulator you are using and what the value of
> $TERM is?

TERM is rxvt-unicode-256color

> In rxvt COLORFGBG can be used to determine the fg and bg color used by
> the terminal.  Emacs can use that to set the `background-mode', and
> all the faces are defined based on `background-mode'.

COLORFGBG is 15;0

> It might be interesting to evaluate this:
> 
> M-: (frame-parameter (selected-frame) 'background-mode)) RET

It prints 'dark' for both.

Another note: frames started for emacsclient aren't affected by this.
Lars Ingebrigtsen | 1 Feb 2012 15:00
Picon
Favicon
Gravatar

bug#10687: 24.0.92; Interactive edebug/eieio interaction

Put the following in *scratch*, and say `C-u M-C-x' to edebug-instrument
it.

(defun test-edebug ()
  (interactive)
  (auth-source-search :max 1
		      :host "news.gmane.org"
		      :port '("119" "nntp")))

Then say `(test-edebug)' and step through the form.  Everything will be
fine.

But then say `M-x test-edebug'.  I get the following error when stepping
over the search function:

Wrong type argument: arrayp, auth-source-backend

I think the problem is that the function returns something defined as a
class by ieieio, but I have no idea why it being called interactively
should trigger the bug, and not otherwise.

In GNU Emacs 24.0.92.2 (x86_64-unknown-linux-gnu, GTK+ Version 2.24.6)
 of 2012-01-26 on rusty
Windowing system distributor `The X.Org Foundation', version 11.0.11004000
Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
(Continue reading)

Lars Ingebrigtsen | 1 Feb 2012 15:19
Picon
Favicon
Gravatar

bug#10039: 23.3; Connection Refused when closing gnus

Lars Magne Ingebrigtsen <larsi <at> gnus.org> writes:

>> After quitting reading gnus by pressing 'q' in *Group* buffer for 'quit
>> reading news' I get the ".newsdribble.." file shown in an own buffer and
>> in 'emacs command line' buffer I get 'Connection Refused'.
>
> `M-: (setq debug-on-error t) RET', repeat the bug and post the resulting
> backtrace.

More information was requested, but no response was given within a few
months, so I'm closing this bug report.  If the problem still exists,
please reopen this bug report.

--

-- 
(domestic pets only, the antidote for overdose, milk.)
  http://lars.ingebrigtsen.no  *  Sent from my Rome

Lars Ingebrigtsen | 1 Feb 2012 15:21
Picon
Favicon
Gravatar

bug#10180: 24.0.92; Gnus shows spurious message with org MIME part

Lars Magne Ingebrigtsen <larsi <at> gnus.org> writes:

>> which calls org-cycle-internal-global,
>> which calls (message "OVERVIEW").
>>
>> Since the email or posting I'm reading in Gnus is not in org-mode and I
>> cannot cycle the state of the MIME part, the message is at best
>> superfluous, at worst confusing.
>
> Yes, that seems rather confusing.
>
> Bastien, can the
>
>   (message "OVERVIEW")
>
> be removed from the org function?

Bastien?

--

-- 
(domestic pets only, the antidote for overdose, milk.)
  http://lars.ingebrigtsen.no  *  Sent from my Rome


Gmane