chad | 1 Sep 01:06 2011
Picon

Re: Killing a frame sometimes kills emacs

Do you have a non-nill confirm-kill-emacs?  If not, try setting it.  If so,
have you tried (debug-on-entry 'kill-emacs)?

Hope that helps,
*Chad

On Aug 31, 2011, at 1:16 PM, Tassilo Horn wrote:

> Do you have any suggestions on how to debug this issue?

martin rudalics | 1 Sep 02:25 2011
Picon
Picon

Re: display-buffer-alist simplifications

 > One question: is there any reason you gave the revised `pop-to-buffer-*'
 > functions arglists of (&optional buffer-or-name norecord)?  These
 > functions didn't exist in Emacs 23, so it seems that they should be
 > written to be pluggable into (the revised) display-buffer-alist.  So the
 > second argument should instead be an action list instead of NORECORD,
 > right?

I don't know.  If we do so, then the action list should be probably also
made an argument of the switch-to-* family of functions which, IIUC,
according to Stefan should remain callable from programs.

I wouldn't have included the pop-to-* functions in the first place but
there are already too many callers around.  So please rewrite them the
way you consider most suitable.

martin

YAMAMOTO Mitsuharu | 1 Sep 02:42 2011
Picon

Re: Emacs 23 Mac port

>>>>> On Sat, 27 Aug 2011 09:52:54 +0900, YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp> said:

> The 25th update of the Mac port, which is experimental/hackers-only,
> is now available from

>     ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-23.3a-mac-1.9995.tar.gz

Mac OS X 10.7 users may occasionally find an unerased cursor in a line
where face is extended to end of line.  Please apply the patch
available from

    ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-23.3a-mac-1.9995-unerased-cursor.patch.gz

Though I think it is rare that users of other versions Mac OS X find
this problem, that can happen in principle.  The root cause of the
problem is actually platform-independent, and I've just reported it as
Bug#9415 (with a patch).

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

Stephen J. Turnbull | 1 Sep 03:35 2011
Picon

RE: display-buffer-alist simplifications

Drew Adams writes:

 > Why not?  What real deadline does free software development have?

Self-imposed ones.  There are things that are real that are
intangible, as someone who works with software experiences every day.

 > There might be practical limits such as the lost opportunity of
 > someone not being available to help after some date, but it's not
 > like you have to deal with contracts and paying customers.
 > 
 > Let's not exaggerate.  You can do anything you want wrt development
 > schedules.

So can a commercial enterprise, and many failures occur as a result.
But those failures aren't important per se, except to owners; there is
some friction, of course, but the productive resources which have been
freed are reasonably soon applied in new, and on average more
productive, activities.  The real problem here is that users (aka
customers), both current and potential, are suffering while the
company languishes.

The same real problem occurs in a non-profit.  If clients are not
served promptly, something is being wasted.  It's just that measuring
"what is wasted" and "the right thing to do" is much harder if you
don't have profit as a measure, and trading off "different what"s is
much harder.

That doesn't mean non-profit activities are a bad idea; just that
socialism sucks as a management tool.  Still, that's no reason for
(Continue reading)

Chong Yidong | 1 Sep 04:04 2011

Re: display-buffer-alist simplifications

martin rudalics <rudalics <at> gmx.at> writes:

> I don't know.  If we do so, then the action list should be probably also
> made an argument of the switch-to-* family of functions which, IIUC,
> according to Stefan should remain callable from programs.
>
> I wouldn't have included the pop-to-* functions in the first place but
> there are already too many callers around.  So please rewrite them the
> way you consider most suitable.

OK, I understand better now.

The pop-to-* function should NOT be "action functions" (in the sense of
display-buffer-alist), because they select the window in addition to
displaying it.  But, they should make use of action functions.

TRT is to define two functions, `display-buffer-same-window' and
`display-buffer-other-window', which serve as action functions, which
handle the window selection/display part.  Then the implementation of
the pop-to-* functions is very simple: it consists choosing a particular
order for two action functions, or omitting one of them; and then
selecting the window.

This involves a simple re-factoring of your code:

(defun display-buffer-same-window (buffer alist)
  "Display BUFFER in the selected window, and return the window.
If BUFFER cannot be displayed in the selected window (usually
because it is dedicated to another buffer), return nil."
  (setq buffer (window-normalize-buffer-to-display buffer))
(Continue reading)

Chong Yidong | 1 Sep 04:06 2011

Re: display-buffer-alist simplifications

Juri Linkov <juri <at> jurta.org> writes:

> Stefan said yesterday:
>
>> Actually, I think there are 2 defcustoms: display-buffer-alist
>> and display-buffer-default-rule.  The default-rule will replace things
>> like pop-up-frames/pop-up-windows/display-buffer-reuse-frames, while
>> display-buffer-alist will replace things like same-window-* and
>> special-display-*.
>
> And I agree it would be good to do that before 24.1.

Yes, so can someone draw up the *exact* list of variables that we want
to fold into display-buffer-alist, and their corresponding names in the
action alist?  Such a list will facilitate matters greatly.

Eli Zaretskii | 1 Sep 04:53 2011
Picon

Re: Killing a frame sometimes kills emacs

> From: Tassilo Horn <tassilo <at> member.fsf.org>
> Date: Wed, 31 Aug 2011 22:16:55 +0200
> 
> Do you have any suggestions on how to debug this issue?

Run Emacs under a debugger, put a breakpoint on Fkill_emacs, and when
this happens again, tell use who called it by showing the backtrace.

Deniz Dogan | 1 Sep 07:44 2011
Picon

Is it time to create more subdirs in lisp/?

The lisp/ directory in trunk could use some more subdirectories.

Examples:

dired-aux.el
dired-x.el
dired.el
epa-dired.el
find-dired.el
image-dired.el

help-at-pt.el
help-fns.el
help-macro.el
help-mode.el
help.el

ps-bdf.el
ps-def.el
ps-mule.el
ps-print.el
ps-samp.el

Tassilo Horn | 1 Sep 09:04 2011
Picon

Re: Killing a frame sometimes kills emacs

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Tassilo Horn <tassilo <at> member.fsf.org>
>> Date: Wed, 31 Aug 2011 22:16:55 +0200
>> 
>> Do you have any suggestions on how to debug this issue?
>
> Run Emacs under a debugger, put a breakpoint on Fkill_emacs, and when
> this happens again, tell use who called it by showing the backtrace.

Ok, breakpoint is set.  Let's see what happens...

Bye,
Tassilo

Juri Linkov | 1 Sep 10:35 2011

Re: Is it time to create more subdirs in lisp/?

> The lisp/ directory in trunk could use some more subdirectories.
>
> Examples:
>
> dired-aux.el
> dired-x.el
> dired.el
> epa-dired.el
> find-dired.el
> image-dired.el

You forgot wdired.el.

> help-at-pt.el
> help-fns.el
> help-macro.el
> help-mode.el
> help.el

And ehelp.el.

> ps-bdf.el
> ps-def.el
> ps-mule.el
> ps-print.el
> ps-samp.el

And printing.el and htmlfontify.el.

(Continue reading)


Gmane