[ESS-bugs] new buglet: M-x R-2.8.x shows *R-..* buffer in two windows

[Martin Maechler]

>>>>> Vitalie Spinu <spinuvit at gmail.com>
>>>>>     on Sat, 20 Oct 2012 13:29:51 +0200 writes:

    >>> Vitalie Spinu <spinuvit at gmail.com> on Sat, 20 Oct 2012
    >>> 00:59:54 +0200 wrote:

    >>> Martin Maechler <maechler at stat.math.ethz.ch> on Fri, 19
    >>> Oct 2012 13:03:03 +0200 wrote:

    >>> I would like to push it further. Why the new R window
    >>> covers the original buffer? For me this is never
    >>> desirable. How about using switch-to-buffer and make the
    >>> window split in 2? This would be consisten to how our
    >>> auto start or C-c C-z works.

    MM> Sounds "ok" to me.... (but I'm not 100% sure yet I'd
    MM> really like it...)

    MM> Be careful to what happens when I M-x R(-...) inside a
    MM> *R* buffer where R has died (in my case typically:
    MM> killed by me via C-c C-q) It should restart R in the
    MM> current buffer, not a new one.

    >> We actually had it already implemented. It's
    >> inferior-ess-same-window which defaulted to t. I have
    >> changed it to nil. It feels better this way as it is
    >> consistent with the splitting which we have during the
    >> auto-start.

    > Hm, I have tried it and it feels a bit weired when having
    > several windows in a frame. Can others also try it out. I
    > am getting slightly inclined to change this back.
    
In this case (your feeling), and so close before release, I'd
advise to revert the change.

Note: That my problem that gave rise to this thread was *not*
calling M-x R-<something> from a R script buffer, but from an
*R* buffer (in *one* only window).
And as said, what happened (only in some cases), is that
*R* got replaced by the *R-<something>* buffer   *AND* that same
buffer was shown in two windows..

As said initially, that's a bug I call  'buglet' (and not
release crticical) because it
happens quite rarely and it is only surprising not really very
bad behavior.

Martin