I am running GNU Emacs 24.3.1 on Windows 8. I put the following 2 lines in my .emacs file to specify the height and width I want for the editor window:
(add-to-list 'default-frame-alist (cons 'height 63))
(add-to-list 'default-frame-alist (cons 'width 125))
That works fine. When I open another window from the main editor window using C-x 5 2, it starts up with the same width, but for some reason the height is 66, not 63.
Does anyone have thoughts on why this would happen?
How are you determining the actual size of the resulting (new) frame? If you are using function frame-parameters then that's the right approach.
Are you starting from emacs -Q, so that you are sure that you are not loading some code from your init file that might interfere?
If so, and if you see a discrepancy between what default-frame-alist says a new frame should be like and what the new frame is actually like, then this is most likely a bug. You can report it, giving your recipe starting with emacs -Q, by doing M-x report-emacs-bug.
Related
So I have been using emacs a lot lately. And I have been noticing that the window resizes for a second when it starts up. Is there a way to fix that?
Here is the GIF of what I'm talking about.
To prevent Emacs from resizing its window after startup, put all geometry and font options on the command line or .Xdefaults file rather than in .emacs or other lisp init files.
The initial Emacs frame is drawn before running the lisp startup files, but the X config and command line options have already been read.
As your GIF is mainly showing a width change, with only a minor change in height and no change in the position of the frame, I suspect it is most likely font settings rather than size settings that you need to look for.
My Sample Code (Ensure to put these codes at the first line of your init.el file)
(setq frame-inhibit-implied-resize t) ;; prevent resize window on startup
(setq default-frame-alist '((width . 120) (height . 42)))
(defun x/disable-scroll-bars (frame)
(modify-frame-parameters frame '((horizontal-scroll-bars . nil)
(vertical-scroll-bars . nil))))
(if (display-graphic-p)
(progn
(scroll-bar-mode -1)
(tool-bar-mode -1)
(fringe-mode '(8 . 0))
(add-hook 'after-make-frame-functions 'x/disable-scroll-bars))
(progn
(menu-bar-mode -1)
(setq-default
left-margin-width 1
right-margin-width 0)))
The core is (setq frame-inhibit-implied-resize t).
I've got this line in my .emacs to go fullscreen on startup:
(add-to-list 'default-frame-alist '(fullscreen . maximized))
I run Emacs from WSL with an X11 server on Windows 10. I could set some -geometry to make it not resize into a minimal initial window, but that seemed to be flaky and random. This happened with both Xming and Vcxsrv. It happened even with -Q so in my case it was not related to anything in my startup files.
I haven't tried Cygwins X11 server, but when I tried the evaluation version X410 (available in the Windows Store) it did not have the same problem.
I use below code to setup emacs using fullscreen:
(setq initial-frame-alist '( (fullscreen . maximized)))
(setq default-frame-alist '( (fullscreen . fullheight)))
I wish it startup with maximized window, the behavior is almost as expected but the window size firstly with default size, then I can see it changed to maximum size obviously.
How can emacs startup to fullscreen in one step?
Look at the documentation for initial-frame-alist (C-h v initial-frame-alist). In particular, Emacs creates the first frame before reading init.el, so you need to specify these things somewhere other than init.el. Two common ways are to give the --maximized command line option, or to set the X11 resource Emacs.Fullscreen: maximized; either of these are applied before init.el is read and evaluated.
It looks like you're on OS X, which I don't have, and it may be different there.
Update for Emacs 27:
You can set these things in early-init.el, which loads before the GUI starts.
I want emacs to start with specific settings by default. I found that I need to edit the .emacs file in my home directory and use LISP language. However I do get some errors. I need to have:
Windows split by vertical line (I work in C++ with headers and source files)
Column number mode
Cua-mode enabled (to work with normal copy, cut & paste shortcuts)
That's what I have in my .emacs file:
(column-number-mode)
(load "cua-mode")
(CUA-mode t)
(split-window-right)
I'ver tried coding two middle settings in one - (cua-mode). It didn't work out well.
The column-number-mode works, cua does not load and my window is split horizontally (top and bottom window). Where is my error? Thanks for feedback.
From the comments to the question:
if you're using Emacs 24.1 or later,
(column-number-mode)
(load "cua-mode")
(cua-mode t)
(split-window-right)
but if you're using an earlier version,
(column-number-mode)
(load "cua-mode")
(cua-mode t)
(split-window-horizontally)
By the way, the split-window-horizontally also works in later versions of Emacs (I'm using Emacs 25.2.1).
I get this graphical error with linum-mode in my Emacs. I tried upgrading from 23 to 24 (via git) and I've tried both with various supplied binaries online and with my home-compiled version. What I'm really interested in is where to start diagnosing the problem.
The problem goes away if I scroll the torn line numbers off screen and back in.
I have experienced the same problem and spent quite some time trying to resolve it. The graphical error is a result of a clash between linum-mode and how the fringe is rendered. Unfortunately, I was unable to resolve the problem in linum.el, and the fringe display code is part of the C-source.
It can still be done! The easiest way to fix it is to just turn off the fringe.
M-x fringe-mode RET none RET
To make the fringe permanently stay off, I recommend customizing the settings with M-x customize-group RET fringe because some compiled versions of Emacs for Mac OS X have their own fringe settings that can override parts of your .emacs file.
I don't really need those line wrap indicators, so not having a fringe doesn't bother me. However, I did miss a slight separation between the line numbers and the buffer text. I followed the advice of a post on the Emacs Wiki to get that spacing back. In version 0.9x of linum, change line 160 from
(setq width (max width (length str)))
to
(setq width (max width (+ (length str) 1)))
The inspiration for this change is here: http://www.emacswiki.org/emacs/LineNumbers
There are arguments at the source link to set the linum-format variable instead of modifying linum.el. While I understand where they are coming from, most color-themes these days would color the extra space and not provide what I am looking for (a separation of about a space that is the background color). If you do edit linum.el, make sure to run
M-x emacs-lisp-byte-compile-and-load
to make the changes persistent. You can see the result of this by looking at the space before the cursor in the picture found here: http://i.stack.imgur.com/TxyMr.png (I don't have enough reputation to embed images).
No more graphical artifacts!
I had the same problem and I figured out a solution and while it's not the prettiest, due to an extra space to the left of the line number, it's much more elegant than changing the linum.el. Here is the pertinent part of my ~/.emacs:
;; Linum mode
(global-linum-mode t)
;; Offset the number by two spaces to work around some weird fringe glitch
(setq linum-format " %d ")
This removes the fringe overlay issue and does not have any other impact other than offsetting the line number.
to make a separation between the line numbers and the buffer text, the follow change will be better:
In version 0.9x of linum, change line 150 from
(concat "%" (number-to-string w) "d")))))
to
(concat "%" (number-to-string w) "d ")))))
This make the separation have the same background color with line numbers'.
This is how I have it setup in my .emacs and I don't have the problem, although I also don't use emacs with gtk or any other gui.
(linum-mode +1)
(setq linum-format "%d ")
You might want to hack around with (setq linum-format) to see if you can get good results. Also don't forget to browse emacswiki on linum.
The problem was still here on emacs 24.4, OS X 10.10.1.
The solution I worked out:
after loading the theme of your choice:
(load-theme 'whatever)
(set-face-attribute 'fringe nil :background (face-background 'default))
I am using emacs 23 on my Ubuntu netbook edition. Every app, automatically goes to fullscreen (so does my emacs). But depending on the font size (:height), I get a smaller working window.
If I go to :height normal I get the full area but the fonts are HUGE!
any ideas?
Your window manager is broken. emacs resizes itself when you change the font size (this happens during startup). Your window manager should tell emacs that emacs was resized by the window manager, at which point everything will work normally.
Anyway, start emacs as "emacs --daemon" and connect with "emacsclient -c" and you should not notice this problem.
OK, so actually I added this to my initfile:
(add-hook 'after-make-frame-functions
(lambda (frame)
(progn
(add-to-list 'default-frame-alist
(cons 'height
(/ (x-display-pixel-height)
(frame-char-height)))
(add-to-list 'default-frame-alist
(cons 'width
(/ (x-display-pixel-width)
(frame-char-width))))))))
and now the window is the same size as the full screen. If you are setting your fonts inside of the after-make-frame-functions hook then it is important that this comes first in your initfile, (I think because hooks are run in reverse order) but if you're just setting the fonts then this should work OK anywhere.
Of course for maximum safety you could put this and your 'set fonts' stuff into the same defun, with this coming after the fonts have been set.
EDIT:
This is a slightly more forceful way to do it, in case that doesn't work.
This gives me some issues though, really you would probably want to subtract the height of the top panel from the height you're setting it to.
(add-hook 'after-make-frame-functions
(lambda (frame)
(progn
(set-frame-height frame
(/ (x-display-pixel-height)
(frame-char-height)))
(set-frame-width frame
(/ (x-display-pixel-width)
(frame-char-width))))))
The font size issue can be fixed simply by selecting a different size font as the default font (Options->Set Default Font), then saving the options (Options->Save Options). Emacs seems to have issues with font point sizes matching system sizes (there's discussion about X standard DPIs versus GTK standard DPIs), but if you select one that works it will stay the same.
To get the window to come up maximized correctly, I've found there's an issue with the frame alist not accounting for the minibuffer correctly as well as the different font sizes not triggering the frame to resize correctly. If you set the initial-frame-alist to include (fullscreen . fullwidth) and (minibuffer-lines . 1) it accounts for the minibuffer size correctly and comes up with the correct width, forcing an effect as if you resized the window by hand to the maximum visible area (not quite the same as maximizing). You can set these via Options->Customize Emacs->Settings Matching Regexp... Then typing initial-frame-alist. Set two new parameters and values, "minibuffer-lines" to "1" and "fullscreen" to "fullwidth".
Removing the "minibuffer-lines" parameter will give you a full screen width window that's the wrong height, and removing the "fullscreen" parameter means nothing resizes correctly. Attempting to set "fullscreen" to "fullscreen" gives the same issue as setting nothing, and "fullscreen" to "fullheight" gives blank space only across the height and not the width when a smaller font size is used.