[display-buffer] a way to make it behave as before?

[display-buffer] a way to make it behave as before?

[Katsumi Yamaoka]

Hi,

I'm fiddling `display-buffer-alist' and others so as to make
`display-buffer' behave as before, though I didn't find out a
smart way so far.  What behavior I want is:

`find-file-other-window' opens a file in the other window of
the frame when the frame is split into two windows.  Don't split
either of two windows into two, IOW don't change the window
configuration of the frame[1].  Even if there is a window that
visits the file in another frame, don't use it[2].

As for the `other-window' specifier, it seems there's no way to
customize so as to make it behave as above.  (It might be
`display-buffer-macro-specifiers', but it's a constant.)

I wish there were a switch that makes it behave as before. ;-)

[1] I don't want an Emacs frame to be split into many windows,
    because the screen height of my note is not so high, and
    a font I use is not so small.
[2] `raise-frame' doesn't work on cygwin (and possibly some
    window managers, like metacity).

Re: [display-buffer] a way to make it behave as before?

[martin rudalics]

 > I'm fiddling `display-buffer-alist' and others so as to make
 > `display-buffer' behave as before, though I didn't find out a
 > smart way so far.  What behavior I want is:
 >
 > `find-file-other-window' opens a file in the other window of
 > the frame when the frame is split into two windows.  Don't split
 > either of two windows into two, IOW don't change the window
 > configuration of the frame[1].

I just provided a new specifier for `display-buffer-alist' called
other-window-means-other-frame.  Please set it and tell me whether it
works (Sometimes I wonder what `find-file-other-frame' is for ;-)).

 > Even if there is a window that
 > visits the file in another frame, don't use it[2].

Does this mean that in Emacs 23 you have `display-buffer-reuse-frames'
nil and `pop-up-frames' t?

Anyway.  Why don't you remove all instances of reuse-window from
`display-buffer-alist' that would use a window on another frame, that
is, use only instances of the (reuse-window ... ... nil) type.  This way
a window gets reused iff it's on the selected frame.

 > As for the `other-window' specifier, it seems there's no way to
 > customize so as to make it behave as above.  (It might be
 > `display-buffer-macro-specifiers', but it's a constant.)

It's been already removed from there.  Please have a look.

 > I wish there were a switch that makes it behave as before. ;-)
 >
 > [1] I don't want an Emacs frame to be split into many windows,
 >     because the screen height of my note is not so high, and
 >     a font I use is not so small.
 > [2] `raise-frame' doesn't work on cygwin (and possibly some
 >     window managers, like metacity).

martin

Re: [display-buffer] a way to make it behave as before?

[Katsumi Yamaoka]

(I believe I use the most recent bzr Emacs 24.)

>> I'm fiddling `display-buffer-alist' and others so as to make
>> `display-buffer' behave as before, though I didn't find out a
>> smart way so far.  What behavior I want is:
>>
>> `find-file-other-window' opens a file in the other window of
>> the frame when the frame is split into two windows.  Don't split
>> either of two windows into two, IOW don't change the window
>> configuration of the frame[1].

> I just provided a new specifier for `display-buffer-alist' called
> other-window-means-other-frame.  Please set it and tell me whether it
> works (Sometimes I wonder what `find-file-other-frame' is for ;-)).

Where/How can I find that specifier in the customization buffer?
Ok.  I tried those two:

(progn
  (makunbound 'display-buffer-alist)
  (load "window")
  (setcdr (car display-buffer-alist)
          (append (cdar display-buffer-alist)
                  '((other-window-means-other-frame . nil)))))

(progn
  (makunbound 'display-buffer-alist)
  (load "window")
  (setcdr (car display-buffer-alist)
          (append '((other-window-means-other-frame . nil))
                  (cdar display-buffer-alist))))

But I saw no difference.  `C-x 4 f' or `C-x 4 b' still opens a file
or a buffer in a new frame, or another existing frame that already
displays its window.  In the later case, I cannot see it immediately
if that frame is hidden by other applications or iconified.

I only want to see it in the other window of the current frame.

>> Even if there is a window that
>> visits the file in another frame, don't use it[2].

> Does this mean that in Emacs 23 you have `display-buffer-reuse-frames'
> nil and `pop-up-frames' t?

No, both are nil.  I leave most such options the default.

> Anyway.  Why don't you remove all instances of reuse-window from
> `display-buffer-alist' that would use a window on another frame, that
> is, use only instances of the (reuse-window ... ... nil) type.  This way
> a window gets reused iff it's on the selected frame.

The main reason I want to do all within the current frame is because
Emacs doesn't raise a hidden frame.  On cygwin (I use it in the office)
and on Fedora 14 Linux (I use it in home), Emacs puts a newly created
frame on the top of the screen, but it doesn't for a frame that exists
but is hidden.

As for Fedora 14, I use an external program called `wmctrl' to make
`raise-frame' work, but it has no effect on cygwin.  Cf.
http://lists.gnu.org/archive/html/emacs-devel/2006-10/msg01117.html

>> As for the `other-window' specifier, it seems there's no way to
>> customize so as to make it behave as above.  (It might be
>> `display-buffer-macro-specifiers', but it's a constant.)

> It's been already removed from there.  Please have a look.

Confirmed.  Thanks.

>> I wish there were a switch that makes it behave as before. ;-)
>>
>> [1] I don't want an Emacs frame to be split into many windows,
>>     because the screen height of my note is not so high, and
>>     a font I use is not so small.
>> [2] `raise-frame' doesn't work on cygwin (and possibly some
>>     window managers, like metacity).

Re: [display-buffer] a way to make it behave as before?

[Katsumi Yamaoka]

Katsumi Yamaoka wrote:
> I only want to see it in the other window of the current frame.

Maybe this one is the nearest to what I exactly want. :)

(when (boundp 'display-buffer-alist)
  ;; Specify the frame size used when creating a new frame.
  (unless (assq 'pop-up-frame-alist (car display-buffer-alist))
    (setcdr (car display-buffer-alist)
            (append (cdr (car display-buffer-alist))
                    '((pop-up-frame-alist (height . 35) (width . 80))))))
  (let ((spec (prin1-to-string display-buffer-alist))
        (start 0))
    ;; Delete `largest' and `lru' elements in every specifiers.
    (while (string-match "(\\(?:largest\\|lru\\)\\(?: [^)]+\\)?)" spec)
      (setq spec (concat (substring spec 0 (match-beginning 0))
                         (substring spec (match-end 0)))))
    ;; Make `same' elements void.
    (while (string-match " same\\([ )]\\)\\|\\(?:(same\\(?: [^)]+\\)?)\\)"
                         spec start)
      (setq start (+ (match-beginning 0) (if (match-beginning 1) 14 12))
            spec (concat (substring spec 0 (match-beginning 0))
                         (if (match-beginning 1)
                             (concat " (same . nil)" (match-string 1 spec))
                           "(same . nil)")
                         (substring spec (match-end 0)))))
    (setq display-buffer-alist (read spec))))

Re: [display-buffer] a way to make it behave as before?

[martin rudalics]

 > I only want to see it in the other window of the current frame.

There was a misunderstanding.  I thought you wanted a new frame :-(

In the first version of `display-buffer-alist' there was no minimum size
of the new window specified, so you got too many windows.  This should
have been fixed in the meantime.  So the best solution is probably to
try using the default value of `display-buffer-alist' again.

If you want to avoid that another frame showing the buffer already is
used, replace in all reuse-window specifiers you find in
`display-buffer-alist' the last element by nil.

That is, wherever you see an object like

   (reuse-window nil same visible)

replace the term `visible' by nil

   (reuse-window nil same nil)

so only the selected and not all visible frames get inspected.

martin

Re: [display-buffer] a way to make it behave as before?

[Katsumi Yamaoka]

martin rudalics wrote:
>> I only want to see it in the other window of the current frame.

> There was a misunderstanding.  I thought you wanted a new frame :-(

> In the first version of `display-buffer-alist' there was no minimum size
> of the new window specified, so you got too many windows.  This should
> have been fixed in the meantime.  So the best solution is probably to
> try using the default value of `display-buffer-alist' again.

I tried the new window.el without rebuilding Emacs as:

emacs -Q -eval '(makunbound (quote display-buffer-alist))' -l window

The *scratch* window appears in an Emacs frame.  Say it is the
first frame.  Type `C-x 5 b RET' there.  The *Messages* window
will appear in a new Emacs frame.  Say it is the second frame.
And then type `C-x 4 f ~/.emacs RET' in the second frame.  Hmm,
the .emacs window appears in the first frame.  Isn't it strange?
At least it differs from old Emacsen.

> If you want to avoid that another frame showing the buffer already is
> used, replace in all reuse-window specifiers you find in
> `display-buffer-alist' the last element by nil.

> That is, wherever you see an object like

>   (reuse-window nil same visible)

> replace the term `visible' by nil

>   (reuse-window nil same nil)

> so only the selected and not all visible frames get inspected.

I'll try it.  Thanks.

Re: [display-buffer] a way to make it behave as before?

[martin rudalics]

 > emacs -Q -eval '(makunbound (quote display-buffer-alist))' -l window

If you make this unbound, you ignore the default values which are
responsible for implementing the traditional behavior.

 > The *scratch* window appears in an Emacs frame.  Say it is the
 > first frame.  Type `C-x 5 b RET' there.  The *Messages* window
 > will appear in a new Emacs frame.  Say it is the second frame.
 > And then type `C-x 4 f ~/.emacs RET' in the second frame.  Hmm,
 > the .emacs window appears in the first frame.

With emacs -Q the *Messages* window is split here.  When
`display-buffer-alist' is unbound it uses a fallback method, which,
since you implicitly removed the window splitting part, reuses any
window but the selected one.

 > At least it differs from old Emacsen.

It shouldn't for emacs -Q.  And in this regard you're right.  I
remembered that someone wanted to change the default value of
`display-buffer-reuse-frames' to t and have set the default value of
`display-buffer-alist' accordingly.  That's what you've seen earlier
(but not in the scenario above!).  I'll take that back.  Meanwhile, try
the steps below which will anticipate my change and tell me whether it
works.

 >> If you want to avoid that another frame showing the buffer already is
 >> used, replace in all reuse-window specifiers you find in
 >> `display-buffer-alist' the last element by nil.
 >
 >> That is, wherever you see an object like
 >
 >>   (reuse-window nil same visible)
 >
 >> replace the term `visible' by nil
 >
 >>   (reuse-window nil same nil)
 >
 >> so only the selected and not all visible frames get inspected.
 >
 > I'll try it.  Thanks.

Thank you, martin

Re: [display-buffer] a way to make it behave as before?

[Katsumi Yamaoka]

martin rudalics wrote:
>> emacs -Q -eval '(makunbound (quote display-buffer-alist))' -l window

`makunbound' here was used to ensure using the default value of
`display-buffer-alist' that the new window.el provides.
If it is just `emacs -Q -l window', `-l NEW-window.el' will not
override the old default value of `display-buffer-alist', that
has been dumped into the Emacs executable.  Whereas you haven't
changed it in the last commit, so it was unnecessary.

> If you make this unbound, you ignore the default values which are
> responsible for implementing the traditional behavior.

But `emacs -Q -l window' makes no difference.  So, I'm going to
try again later.  Now rebuilding Emacs is in progress (it takes
a long time in the cygwin system :-<).

Re: [display-buffer] a way to make it behave as before?

[Katsumi Yamaoka]

martin rudalics wrote:
>> The *scratch* window appears in an Emacs frame.  Say it is the
>> first frame.  Type `C-x 5 b RET' there.  The *Messages* window
>> will appear in a new Emacs frame.  Say it is the second frame.
>> And then type `C-x 4 f ~/.emacs RET' in the second frame.  Hmm,
>> the .emacs window appears in the first frame.

I updated the bzr copy, rebuilt Emacs with it, launched Emacs with
the -Q option, and saw the behavior unchanged.

emacs -Q
C-x 5 b *Messages* RET
C-x 4 f ~/.emacs RET
 -> the file appears in the *other frame*.

It might be right in a literal sense because the ~/.emacs file
appears in the *other window* even if it is not in the frame in
which the `C-x 4 f' command is invoked, and even if it is a major
visible change of Emacs.  However, there is a case that violates
that specification:

emacs -Q
C-x 5 2
C-x 4 f ~/.emacs RET
 -> the file appears in the *other window* of the current frame.

[...]

> It shouldn't for emacs -Q.  And in this regard you're right.  I
> remembered that someone wanted to change the default value of
> `display-buffer-reuse-frames' to t and have set the default value of
> `display-buffer-alist' accordingly.  That's what you've seen earlier
> (but not in the scenario above!).  I'll take that back.  Meanwhile, try
> the steps below which will anticipate my change and tell me whether it
> works.

>>> If you want to avoid that another frame showing the buffer already is
>>> used, replace in all reuse-window specifiers you find in
>>> `display-buffer-alist' the last element by nil.
>>
>>> That is, wherever you see an object like
>>
>>>   (reuse-window nil same visible)
>>
>>> replace the term `visible' by nil
>>
>>>   (reuse-window nil same nil)
>>
>>> so only the selected and not all visible frames get inspected.

I tried this:

emacs -Q
(setcdr (cddr (assq 'reuse-window (car display-buffer-alist))) (list nil))
C-x 5 b *Messages* RET
C-x 4 f ~/.emacs RET

The behavior unchanged, i.e., the file appears in the other frame.

Well, does it happen with only Emacs built on cygwin?  Ok, I'll
test them in Linux in home, later.

Regards,

Re: [display-buffer] a way to make it behave as before?

[Katsumi Yamaoka]

Katsumi Yamaoka <yamaoka@jpl.org> wrote:
[...]

> emacs -Q
> C-x 5 b *Messages* RET
> C-x 4 f ~/.emacs RET
>  -> the file appears in the *other frame*.

> emacs -Q
> C-x 5 2
> C-x 4 f ~/.emacs RET
>  -> the file appears in the *other window* of the current frame.

[...]
> Well, does it happen with only Emacs built on cygwin?  Ok, I'll
> test them in Linux in home, later.

Emacs bzr built on Fedora 14 Linux has no difference.

Re: [display-buffer] a way to make it behave as before?

[martin rudalics]

 > I updated the bzr copy, rebuilt Emacs with it, launched Emacs with
 > the -Q option, and saw the behavior unchanged.
 >
 > emacs -Q
 > C-x 5 b *Messages* RET
 > C-x 4 f ~/.emacs RET
 >  -> the file appears in the *other frame*.
 >
 > It might be right in a literal sense because the ~/.emacs file
 > appears in the *other window* even if it is not in the frame in
 > which the `C-x 4 f' command is invoked, and even if it is a major
 > visible change of Emacs.  However, there is a case that violates
 > that specification:
 >
 > emacs -Q
 > C-x 5 2
 > C-x 4 f ~/.emacs RET
 >  -> the file appears in the *other window* of the current frame.
 >
 > [...]

There was a remnant of my test settings in the default value of the
pop-up-frame specifier: I made any new frame created this way
unsplittable.  So this is part of the behavior you see.  Currently, I
can reproduce the "display on another frame" behavior iff I make the
selected window small enough and all other windows on this frame
unusable.  Please try once more.

 > I tried this:
 >
 > emacs -Q
 > (setcdr (cddr (assq 'reuse-window (car display-buffer-alist))) (list nil))

I didn't check this but it doesn't have any effect here.

 > C-x 5 b *Messages* RET
 > C-x 4 f ~/.emacs RET
 >
 > The behavior unchanged, i.e., the file appears in the other frame.

If I prepend a (reuse-window nil nil nil) specifier to the first entry
in `display-buffer-alist' the selected window gets reused (with the old
unsplittable frame behavior).

martin

Re: [display-buffer] a way to make it behave as before?

[Katsumi Yamaoka]

martin rudalics wrote:
[...]
> There was a remnant of my test settings in the default value of the
> pop-up-frame specifier: I made any new frame created this way
> unsplittable.  So this is part of the behavior you see.  Currently, I
> can reproduce the "display on another frame" behavior iff I make the
> selected window small enough and all other windows on this frame
> unusable.  Please try once more.

What does `unusable' mean?

[...]
> If I prepend a (reuse-window nil nil nil) specifier to the first entry
> in `display-buffer-alist' the selected window gets reused (with the old
> unsplittable frame behavior).

Verified.  It's not what I want, though.  I only want `C-x 4 f'
to split the current window or to use the other window within
the frame as exactly the same as old Emacsen do.

That the new `display-buffer' and friends are useful is beyond
doubt, but I can imagine people will be getting flustered for
the new behavior sooner or later.  For instance, someone in Japan
asked for a help last night; a frame that BBDB makes is too large,
a frame used to compose a mail is too small, etc.  We can't support
all of them, can we?  So, you'd better make `display-buffer-alist'
default to `conservative' or provide a switch that enables a user
to make `display-buffer' behave as before completely, I think.

BTW, shouldn't the default size of a newly created frame follow
that of `emacs -Q' or `C-x 5 2' ?  I feel 80x24 is too small.

Regards,

Re: [display-buffer] a way to make it behave as before?

[martin rudalics]

 >> Currently, I
 >> can reproduce the "display on another frame" behavior iff I make the
 >> selected window small enough and all other windows on this frame
 >> unusable.  Please try once more.
 >
 > What does `unusable' mean?

Dedicated.  Maybe there are other means, but that's what I tried.

 >> If I prepend a (reuse-window nil nil nil) specifier to the first entry
 >> in `display-buffer-alist' the selected window gets reused (with the old
 >> unsplittable frame behavior).
 >
 > Verified.  It's not what I want, though.  I only want `C-x 4 f'
 > to split the current window or to use the other window within
 > the frame as exactly the same as old Emacsen do.

I see.  But does the current default now do what you need in this
respect?  Or are there additional glitches I shall repair?

 > That the new `display-buffer' and friends are useful is beyond
 > doubt, but I can imagine people will be getting flustered for
 > the new behavior sooner or later.  For instance, someone in Japan
 > asked for a help last night; a frame that BBDB makes is too large,
 > a frame used to compose a mail is too small, etc.  We can't support
 > all of them, can we?  So, you'd better make `display-buffer-alist'
 > default to `conservative' or provide a switch that enables a user
 > to make `display-buffer' behave as before completely, I think.

I fully agree with you.  Your comments in this regard are highly
appreciated.  The problem is that I started to think about backward
compatibility only about two weeks ago - till then I was debugging the
`display-buffer-alist' based code.  So most bugs of the past week were
introduced in the phase when I wrote the backward compatibility layer
(mostly what's done in the function `display-buffer-normalize-options').

 > BTW, shouldn't the default size of a newly created frame follow
 > that of `emacs -Q' or `C-x 5 2' ?  I feel 80x24 is too small.

You're right.  I removed that entry completely so it now uses the
default value used by C-x 5 2.  When, and if, you have the time to go
through the default settings of `display-buffer-alist' once more and
find anything that in your opinion just could lead to troubles please
tell me.

Thanks, martin

Re: [display-buffer] a way to make it behave as before?

[Katsumi Yamaoka]

martin rudalics <rudalics@gmx.at> wrote:
> The problem is that I started to think about backward compatibility
> only about two weeks ago

The best choice is to revert all your recent changes, I really,
really believe.  I also really believe that you are really
skillful, so I really believe you will bring the new version that
makes everyone happy, within a month.  Please consider that those
who use bzr Emacs are not necessarily the Emacs developers.

(I found a bug that I may have made in Gnus, so I'd like to waste
 all my free time to it. ;-)

Re: [display-buffer] a way to make it behave as before?

[martin rudalics]

 > The best choice is to revert all your recent changes, I really,
 > really believe.  I also really believe that you are really
 > skillful, so I really believe you will bring the new version that
 > makes everyone happy, within a month.  Please consider that those
 > who use bzr Emacs are not necessarily the Emacs developers.

Well this recommendation is not "really" helpful.  I've set up a bzr
branch more than a year ago and asked people to try it but with the
exception of Juanma nobody did.  So I have to go through with this by
annoying people in order to get some feedback.

The only other choice I see is reverting my changes and leave the window
code to someone else.

martin

RE: [display-buffer] a way to make it behave as before?

[Drew Adams]

>  > The best choice is to revert all your recent changes, I really,
>  > really believe.  I also really believe that you are really
>  > skillful, so I really believe you will bring the new version that
>  > makes everyone happy, within a month.  Please consider that those
>  > who use bzr Emacs are not necessarily the Emacs developers.
> 
> Well this recommendation is not "really" helpful.  I've set up a bzr
> branch more than a year ago and asked people to try it but with the
> exception of Juanma nobody did.  So I have to go through with this by
> annoying people in order to get some feedback.
> 
> The only other choice I see is reverting my changes and leave 
> the window code to someone else.

No, we should not give up.  Patience, for all.  There are lots of cases to
consider, no doubt, and it will take some time to iron out all the problems.

Some of us might not be able to use the development Emacs builds (beyond using
them as emacs -Q) for a while, but if we provide enough feedback and Martin can
fix the code to handle the cases we report then we'll get through this.

Think how long it took to get the latest round of mouse changes completed.  This
has to be at least as hairy, I would guess.

I don't know that we'll all be satisfied at the end, but I do know that Martin
is trying to handle the cases we report.  And I'm hoping that we all will be
satisfied - and better than that.

Re: [display-buffer] a way to make it behave as before?

[joakim]

martin rudalics <rudalics@gmx.at> writes:

>> The best choice is to revert all your recent changes, I really,
>> really believe.  I also really believe that you are really
>> skillful, so I really believe you will bring the new version that
>> makes everyone happy, within a month.  Please consider that those
>> who use bzr Emacs are not necessarily the Emacs developers.
>
> Well this recommendation is not "really" helpful.  I've set up a bzr
> branch more than a year ago and asked people to try it but with the
> exception of Juanma nobody did.  So I have to go through with this by
> annoying people in order to get some feedback.
>
> The only other choice I see is reverting my changes and leave the window
> code to someone else.

I think mot people are happy actually. I use bzr Emacs all the time and
I have lots of issues but not with the window code. Anyway, one must be
able to push scary changes to trunk now and then otherwise we will never
get anywhere.

> martin

-- 
Joakim Verona

Re: [display-buffer] a way to make it behave as before?

[Miles Bader]

joakim@verona.se writes:
> I think mot people are happy actually. I use bzr Emacs all the time and
> I have lots of issues but not with the window code. Anyway, one must be
> able to push scary changes to trunk now and then otherwise we will never
> get anywhere.

Yes, I agree.

I get annoyed by breakage too, but it's not like I didn't ask for it by
updating from the trunk frequently, and it's not like I don't have easy
fallbacks when things really are broken .  Emacs bugs, luckily, rarely
manage to completely hose the OS ... :]

-Miles

-- 
Scriptures, n. The sacred books of our holy religion, as distinguished from
the false and profane writings on which all other faiths are based.

Re: [display-buffer] a way to make it behave as before?

[Thierry Volpiatto]

martin rudalics <rudalics@gmx.at> writes:

>> The best choice is to revert all your recent changes, I really,
>> really believe.  I also really believe that you are really
>> skillful, so I really believe you will bring the new version that
>> makes everyone happy, within a month.  Please consider that those
>> who use bzr Emacs are not necessarily the Emacs developers.
>
> Well this recommendation is not "really" helpful.  I've set up a bzr
> branch more than a year ago and asked people to try it but with the
> exception of Juanma nobody did.  So I have to go through with this by
> annoying people in order to get some feedback.
>
> The only other choice I see is reverting my changes and leave the window
> code to someone else.
No, keep doing the big work, we will notify you when there is problem as
much as possible.
You did a lot of work now, it would be stupid to stop here.

I think also Emacs developers should use more external emacs extensions
to see what happen outside of "emacs -Q" and be able to help for bugs.

Specially in this case, it would speed up things.

-- 
A+ Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

Re: [display-buffer] a way to make it behave as before?

[Katsumi Yamaoka]

martin rudalics wrote:
>> The best choice is to revert all your recent changes, I really,
>> really believe.  I also really believe that you are really
>> skillful, so I really believe you will bring the new version that
>> makes everyone happy, within a month.  Please consider that those
>> who use bzr Emacs are not necessarily the Emacs developers.

> Well this recommendation is not "really" helpful.  I've set up a bzr
> branch more than a year ago and asked people to try it but with the
> exception of Juanma nobody did.  So I have to go through with this by
> annoying people in order to get some feedback.

> The only other choice I see is reverting my changes and leave the window
> code to someone else.

I must apologize to you for my rudeness.  I was mistaken; I thought
it's a great improvement but also thought that the code was far to
completion.  At last I realized that my misunderstanding was due to
an abnormal default behavior.  I got Emacs that works never funny now.
Thanks a lot for working on this.

Regards,

Re: [display-buffer] a way to make it behave as before?

[martin rudalics]

 > At last I realized that my misunderstanding was due to
 > an abnormal default behavior.  I got Emacs that works never funny now.

Could you please send us the corresponding default value for
`display-buffer-alist'?  That is the thing that "never works funny" for
you written as a Lisp expression we would then use right here:

(defcustom display-buffer-alist
   '((((regexp . ".*"))
      ;; Reuse window showing same buffer on same frame.
      reuse-window (reuse-window nil same nil)
      ;; Pop up window.
      pop-up-window
      ;; Split largest or lru window.
      (pop-up-window (largest . nil) (lru . nil))
      (pop-up-window-min-height . 40) ; split-height-threshold / 2
      (pop-up-window-min-width . 80) ; split-width-threshold / 2
      ;; Reuse any but selected window on same frame.
      reuse-window (reuse-window other nil nil)
      (reuse-window-even-sizes . t)))

Thanks, martin

Re: [display-buffer] a way to make it behave as before?

[Katsumi Yamaoka]

martin rudalics wrote:
>> At last I realized that my misunderstanding was due to
>> an abnormal default behavior.  I got Emacs that works never funny now.

> Could you please send us the corresponding default value for
> `display-buffer-alist'?  That is the thing that "never works funny" for
> you written as a Lisp expression we would then use right here:
[...]

I use the default value.  I've never seen any unpleasant thing
so far.  In reality, I'm still half in doubt, but it's a fact.
Thanks.

Re: [display-buffer] a way to make it behave as before?

[martin rudalics]

> I use the default value.  I've never seen any unpleasant thing
> so far.  In reality, I'm still half in doubt, but it's a fact.

OK.  As soon as you see any unpleasant thing please complain.

Thanks, martin

Re: [display-buffer] a way to make it behave as before?

[David Kastrup]

martin rudalics <rudalics@gmx.at> writes:

>> I use the default value.  I've never seen any unpleasant thing
>> so far.  In reality, I'm still half in doubt, but it's a fact.
>
> OK.  As soon as you see any unpleasant thing please complain.

This room could use cleaning up.

-- 
David Kastrup

Re: [display-buffer] a way to make it behave as before?

[Juanma Barranquero]

On Wed, Jun 22, 2011 at 15:32, Katsumi Yamaoka <yamaoka@jpl.org> wrote:

> Please consider that those
> who use bzr Emacs are not necessarily the Emacs developers.

There are releases for a reason. It's OK for people who want to live
in the edge to use the main repository, but restricting development
because of them seems absurd. As has been discussed several times, we
don't even guarantee that the trunk will be in a compilable / bootable
state at all times (though it usually is). Outside users who find
themselves unable to use a given revision can revert to a previous
one.

    Juanma

Re: [display-buffer] a way to make it behave as before?

[Katsumi Yamaoka]

Juanma Barranquero wrote:
> On Wed, Jun 22, 2011 at 15:32, Katsumi Yamaoka <yamaoka@jpl.org> wrote:

>> Please consider that those
>> who use bzr Emacs are not necessarily the Emacs developers.

> There are releases for a reason. It's OK for people who want to live
> in the edge to use the main repository, but restricting development
> because of them seems absurd. As has been discussed several times, we
> don't even guarantee that the trunk will be in a compilable / bootable
> state at all times (though it usually is). Outside users who find
> themselves unable to use a given revision can revert to a previous
> one.

>     Juanma

First of all, it's not my original purpose to oust enterprising
developments.  But as for `display-buffer-alist', it looks hard
to customize so as to make it one's favorite.  In fact, it's
hard (or impossible?) to make it behave as exactly the same as
old Emacsen.  I might get to like it, but my interest is not
necessarily in window.el and I have no time to debug it thoroughly
for the moment.  I was only made to waste time to work around[1].

I think it was not too late to have installed the new feature to
the trunk after having provided an option that enables a user to
make it work like old Emacsen.

[1] http://article.gmane.org/gmane.emacs.devel/140706

Re: [display-buffer] a way to make it behave as before?

[Juanma Barranquero]

On Thu, Jun 23, 2011 at 01:20, Katsumi Yamaoka <yamaoka@jpl.org> wrote:

> But as for `display-buffer-alist', it looks hard
> to customize so as to make it one's favorite.

That's not a reason to remove it from the trunk, but to document it better.

> In fact, it's
> hard (or impossible?) to make it behave as exactly the same as
> old Emacsen.

Martin's fixing bugs as fast as he can. But to discover bugs, the code
has to be there, and preferably enabled.

I might get to like it, but my interest is not
> necessarily in window.el and I have no time to debug it thoroughly
> for the moment.  I was only made to waste time to work around[1].

Most window.el bugs aren't serious enough to preclude using Emacs. And
if some are for you, you can revert Martin's changes, which are quite
self contained (mostly lisp/window.el, src/window.[ch], src/frame.c,
src/buffer.c).

> I think it was not too late to have installed the new feature to
> the trunk after having provided an option that enables a user to
> make it work like old Emacsen.

The new code has to be as compatible with the old as possible, sure.
But, an option to disable all the changes and get the exact previous
behavior back? That seems like an ugly hack. If you really need that
"option", I think it's called "bzr update -r104508".

    Juanma