headers
chad | 1 Sep 2011 01:06
Picon
Favicon

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?
Permalink | Reply | 0 comments |
headers
martin rudalics | 1 Sep 2011 02:25
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
Permalink | Reply | 3 comments |
headers
YAMAMOTO Mitsuharu | 1 Sep 2011 02:42
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
Permalink | Reply | 5 comments |
headers
Stephen J. Turnbull | 1 Sep 2011 03:35
Picon
Favicon

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)

Permalink | Reply | 0 comments |
headers
Chong Yidong | 1 Sep 2011 04:04
Favicon

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)

Permalink | Reply | 2 comments |
headers
Chong Yidong | 1 Sep 2011 04:06
Favicon

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.
Permalink | Reply | 0 comments |
headers
Eli Zaretskii | 1 Sep 2011 04:53
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.
Permalink | Reply | 35 comments |
headers
Deniz Dogan | 1 Sep 2011 07:44
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
Permalink | Reply | 14 comments |
headers
Tassilo Horn | 1 Sep 2011 09:04
Picon
Gravatar

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
Permalink | Reply | 0 comments |
headers
Juri Linkov | 1 Sep 2011 10:35
Favicon
Gravatar

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)

Permalink | Reply | 1 comment |

Gmane