bug#11052: 24.0.94; Display problem under OS X Lion

bug#11137: 24.0.94; c-tab-always-indent and tab-always-indent

On 2012-04-01 06:15 +0800, Alan Mackenzie wrote:
> There isn't a completion engine in CC Mode, so it is difficult to see
> what this could do in c-tab-always-indent.  Did you have some specific
> idea as to what this could be?

I was thinking if someone adds something to
completion-at-point-functions TAB in cc-mode can do the completion for
them.

Leo

bug#11137: 24.0.94; c-tab-always-indent and tab-always-indent

> tab-always-indent can take the value of complete that does
> completion-at-point too.  Does it make sense to make c-tab-always-indent
> consistent with this?  Thanks.

[ CC-mode is under Alan's control, so this answer is just to stir
  things up a bit. ]

If you ask me, all the <foo>-tab-always-indent should die and be
replaced by generic support for mode-local customization of
variables like tab-always-indent.

        Stefan

bug#11139: 24.0.94; inappropriate `face' property for `apropos*' button types

On Sat, Mar 31 2012, Drew Adams wrote:

> A face should almost never be hard-coded, fixing Emacs's appearance in
> concrete.  Please think of the users and of Emacs's mission to be
> customizable by them.  It is hard to believe that this kind of thing is
> still going on.  This is 2012, not 1980.

May I ask a rhetorical question: What's wrong with

#+begin_src emacs-lisp
(add-hook 'apropos-mode-hook
	  (lambda ()
	    (face-remap-set-base 'italic '(:reverse-video t))))
#+end_src

It's rhetorical because you already made it clear that a new load of
defface's or defcustom's would be the proper way to handle the issue.

My question is also rhetorical and hypocritical because I really just
wanted to seize on the opportunity to say that some people don't
actually enjoy wading through an ever growing plethora of options and
faces.

On the other hand, they revel in general mechanisms like face-remap-*.

YMMV 

Wolfgang

bug#11142: 24.0.94; objc-mode fails for imenu and which-function-mode

Turn on which-function-mode and open an objc file, it cannot show the
function name. Also, M-x imenu-add-menubar-index says: Error in
menu-bar-update-hook (imenu-update-menubar): (wrong-type-argument
integerp nil)

Leo

bug#11138: 23.3; on Windows, message-box does not display line breaks in the message

> From: "Drew Adams" <drew.adams <at> oracle.com>
> Cc: <dpchiesa <at> hotmail.com>, <11138 <at> debbugs.gnu.org>
> Date: Sat, 31 Mar 2012 14:29:31 -0700
> 
> (BTW, I do not have the Emacs 24 C code, but in Emacs 23.3 it looks like
> `message-box' calls `x-popup-dialog', not `x-popup-menu'.  Same idea, anyway.)

If you look at the sources, you will see that x-popup-dialog calls
x-popup-menu internally.

bug#11134: 24.0.94; Mac's Text to Speech stopped working in emacs buffers when I moved from Snow Leopard to Lion

>>>>> On Sat, 31 Mar 2012 16:34:56 +0200, Jan Djärv <jan.h.d <at> swipnet.se> said:

> The NS port does not support accessability at all, but if it is the
> function described by YAMAMOTO Mitsuharu above you want, try the
> patch below.  

> +  else if ([attribute isEqualToString:NSAccessibilityValueAttribute])
> +    {
> +      if (! NILP (BVAR (current_buffer, mark_active)))
> +        str = ns_get_local_selection (QPRIMARY, QUTF8_STRING);
> +      if (NILP (str))
> +        str = Fbuffer_string ();
> +    }

Is it safe to call Fbuffer_string (in particular, move the gap) inside
read_socket_hook?  It is apparently unsafe without SYNC_INPUT, but I'm
not sure if it is supposed to be OK for the SYNC_INPUT case.

				     YAMAMOTO Mitsuharu
				mituharu <at> math.s.chiba-u.ac.jp

bug#11143: 24.0.94; buggy buggy gnutls freezes emacs

This issue isn't easy to reproduce because it depends on the network.

gnutls-boot can sometimes go into infinite 100% CPU consummation (looks
like a infinite loop) as shown in this screenshot:

C-g cannot stop it. I have left it running for > 15 minutes and no sign
of stopping too.

I know it is gnutls-boot because, I tried:

 - kill -USR2 <pid>
 - killall emacs

and a debug buffer pops up to say that. Unfortunately I was just about
to get a copy of the backtrace and the network was back to normal. But I
think gnutls is doing some funny business. gnutls should kill itself
after some time instead of freeze emacs forever.

Leo

bug#11141: 24.0.94; crash with `x-popup-dialog'

"Drew Adams" <drew.adams <at> oracle.com> writes:

> 100% reproducible, from emacs -Q.
>  
> (defun titi (event)
>   (interactive "e")
>   (let ((choice (x-popup-dialog
>                  event
>                  '("ABC"
>                    "DEF"
>                    ("OK" . bar)))))
>     (and choice (call-interactively choice))))
>  
> (defun bar () (interactive) t)
>  
> (global-set-key [double-mouse-2] 'titi)
> (global-set-key [mouse-2] nil)
>  
> Then double-click mouse-2.  Note that if you remove the string "DEF"
> there is no crash.

No crash on latest trunk, x86_64-unknown-linux-gnu.  Maybe a Windows
issue.  Any backtrace?

bug#11119: 23.4; Xcode 4.3.2 dislikes valueless return statements in non-void functions

Pavel Repin <prepin <at> gmail.com> writes:

> Yes this is great it was fixed in trunk (my patch is almost identical).
> Any chance it might be applied to 23.4 branch?

No more changes are going to that branch, since we are not planning any
more 23.x releases.