I never want Emacs to split a frame. Can you help?

[Paul Johnson-11]

For me (and students), there is an annoying feature of Emacs: is the
tendency to automatically split frames. Its very old fashioned, we
think :)

I have tried to reduce that when using ESS by customizing the Emacs
start options.  If the user hits the big blue R, this causes Emacs to
make a new frame and show the R session in it. (lisp below)

However, if the user forgets to hit the big blue R, and sends a
command to a non-existant R session, then ESS does us the favor of
splitting the frame and starting R within a buffer.   In the old days,
ESS would return an error saying there was no instance of R running.
That was adequate.  Now it does this annoying thing.

I'd settle if you could tell me an Emacs config command to completely
eliminate the odious split frame tendency of Emacs.  i've got giant
monitors, I am good at window management. If Emacs just popped up a
new frame every time it wanted to display something, I'd be happy
enough.

I expect that's impossible (have been googling), but maybe I could
just stop ESS from triggering splits when it starts R for me.

Here's the configuration from my .emacs that forces emacs to start in
its own frame.  Maybe you can tell me how to customize?

;;Set up emacs-ess for Emacs with other things we like at KU.
;;;;;
;;;;;; This file is automatically loaded by emacs's site-start.el
;;;;;; when you start a new emacs session.
;;;
(require 'pc-select)
(pc-selection-mode)
(custom-set-variables
 '(cua-mode t nil (cua-base))
 '(show-paren-mode t)
 '(text-mode-hook (quote (turn-on-auto-fill text-mode-hook-identify)))
 '(transient-mark-mode t))

;;;
(setq inferior-ess-own-frame t)

(setq inferior-ess-same-window nil)
;;;
;;;;;create a new frame for each help instance
;;;
(setq ess-help-own-frame t)
;;;;;If you want all help
;;;;; buffers to go into one frame do:
;;;
(setq ess-help-own-frame 'one)

(setq ess-ask-for-ess-directory nil)
(setq ess-local-process-name "R")

 (setq ansi-color-for-comint-mode 'filter)
  (setq comint-prompt-read-only t)
  (setq comint-scroll-to-bottom-on-input t)
  (setq comint-scroll-to-bottom-on-output t)
  (setq comint-move-point-for-output t)

;; This lets the "shift return" key combination send and step
(defun my-ess-eval ()
  (interactive)
  (if (and transient-mark-mode mark-active)
        (call-interactively 'ess-eval-region)
    (call-interactively 'ess-eval-line-and-step)))

(add-hook 'ess-mode-hook
          '(lambda()
             (local-set-key [(shift return)] 'my-ess-eval)))



--
Paul E. Johnson
Professor, Political Science
1541 Lilac Lane, Room 504
University of Kansas

______________________________________________
ESS-help@... mailing list
https://stat.ethz.ch/mailman/listinfo/ess-help

[Stephen Eglen]

hi Paul,
> However, if the user forgets to hit the big blue R, and sends a
> command to a non-existant R session, then ESS does us the favor of
> splitting the frame and starting R within a buffer.   In the old days,
> ESS would return an error saying there was no instance of R running.
> That was adequate.  Now it does this annoying thing.
>
> I'd settle if you could tell me an Emacs config command to completely
> eliminate the odious split frame tendency of Emacs.  


hi Paul,

something odd is happening here; I see you already have the following
in your config:
(setq inferior-ess-own-frame t)

which should tell emacs to create new frames for each new *R* regardless
of how *R* was created.  On my machine, running either M-x R or just
sending a line of R code (without any *R* buffers pre-existing) creates
*R* in a new frame.  This is with ESS 5.5, but this code hasn't changed
in a while.


Stephen

______________________________________________
ESS-help@... mailing list
https://stat.ethz.ch/mailman/listinfo/ess-help