Since an emacs upgrade I made a long time ago (or was it when I changed my laptop, or when I changed my Ubuntu release? I can't remember), emacs keeps opening new windows whenever I click into a file link in grep-mode (for example). Before, I had this behavior:
I have a window open (window 0)
I run a grep command
I get a new window, with the grep result (window 1)
I select any line in the grep result, and a new buffer is opened in window 0
Which is what I want: maximum two windows opened, and I get to see around 30 lines per window. Now, instead, I get:
I have a window open (window 0)
I run a grep command
I get a new window, with the grep result (window 1)
I select any line in the grep result, a new buffer is opened in a new window (window 3). The windows have 30, 15, and 15 lines.
So now I have 3 windows instead of 2, with too few lines. This happens again, until a maximum of 4 open windows. To keep my windows at a minimum height, I need to keep on manually closing windows, which is very annoying.
I guess this has to do with the minimum height of the window, and how many lines the frame has, but I am unable to find the exact settings.
How can I tell emacs to open at most 2 windows in the active frame?
Related
I am using emacs-daemon. When every I restart my daemon and do C-x C-b my Buffer List seems always full.
Later, when I start my emacsclient for a seconds(like a fast flash) it shows a file that located on the top of my Buffer List and opens the file I want to open. This is little annoying to face with all the time.
Example:
I type emacsclient -t file_a.py.
For a second or less, buffer called file_b.py opens (my lastly opened file).
Than file_a.py get opens.
This always repeats itself even I clean my buffer list doing following and open a new file (since buffer list now contains more than one file):
Link:
Edit: There's also the boring old buffer menu you get with C-x C-b.
In this menu, you can hold d until it marks each buffer for deletion,
then press x to commit.
Even after doing this after that IBuffer shows up since it is the latest opened buffer.
[Q] Is it possible to prevent 1 second file show up when I start emacsclient? If possible I always want to keep my Buffer List empty, but not sure would it be a good idea, or some how keep a empty file at the top of the buffer list since it will show a blank frame.
This also occurs when I using emacs -nw where scratch* buffer or latest opened buffer shows up for as seconds as well.
I just installed Rascal and Eclipse (4.7.2) on Windows 10.
I've imported CLaiR (C Language Analysis in Rascal) and am trying to parse an existing C program
rascal>import lang::cpp::AST;
ok
rascal>parseCpp(|file:///c:/users/user/testme.cpp|)
I get a little over a screenful of information. The last line looks truncated and the last 3 characters are ...
Am I right? How do I increase how much is shown?
I've tried:
1. Windows, Preferences, Terminal, Terminal Buffer Lines = 1000000
2. Windows, Preferences, Run/Debug, Console, Console Buffer Size = 1000000
Any other ideas?
We indeed truncate the output of the result of an REPL command.
If you pass the value into iprintln (i for indented), you will get the full value. There is also iprintToFile to write it to a file. Another option is to use the functions util::ValueUI to view the value as either a collapsable tree, indented text, or a graph.
I have the application
http://movemouse.codeplex.com/
and I want to launch the app at startup (which I can do) but I also want to automatically hit the "Start" button so it turns on as soon as windows starts.
I need to have command line options to do this.
Anyone know of a command line option to do this? And/or a command line list of options available for this program?
Thank You
From looking at the settings, there are three options, that have to be set:
Automatically start Move Mouse on LAUNCH (same as press start when Move Mouse is opened)
Automatically launch Move Mouse at Windows LogOn
Minimize on start
I assume that the options work as presented.
Otherwise, as said before writing your own MouseMover in AutoHotKey is easy. and compiling it to an exe is easy too.
Here is some AutoHotKey code:
#Persistent
#SingleInstance force
SetTimer MoveMyMouse, 60000 ; 1000 ms = 1 sec.
Return
MoveMyMouse:
MouseMove, 1, 0, 1, R ;Move the mouse one pixel to the right
MouseMove, -1, 0, 1, R ;Move the mouse back one pixel
Return
^!#Pause::ExitApp
Load the code in AutoHotKey and test it, once your'e happy compile to your own MouseMove.exe
What is does:
During startup it starts a timer that executes the little sub-routine labeled MoveMyMouse every 60 seconds. This little sub-routine will move your mouse one pixel back and forth.
I also added an escape by pressing Ctrl+Alt+Win+Pause.
create a cmd file that starts your app and sends a key press to either the left or right "Windows" keys
triggering the windows key will open the start menu
to trigger the windows key, you need to download nircmd.zip and unzip its folder somewhere, then cd the path to that folder
paths may be case sensitive
start "C:\path-to-your-apps\app-name.exe"
cd "C:\path-to-nircmd-folder\"
nircmd sendkey lwin press
do not run your app on startup
instead run the cmd file on startup
to run the cmd file on startup, you first need to make a desktop shortcut to it.
do not right click cmd file > create shortcut
right click the cmd file > send to > desktop (create shortcut)
a window should appear
place the following into the browse field
C:\Windows\System32\cmd.exe /C "C:\path-to-cmd-folder\cmd-name.cmd"
name the shortcut then press the enter key
next, right click your new desktop shortcut > properties
navigate to shortcut tab
set "Run" to "Minimized" so you don't see the command prompt pop up as it runs your cmd file
finally, copy or move your shortcut into your startup folder
"C:\Windows\User\your-user-name\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup"
I use gdb-many-windows in emacs for my debugging.
Recently, I discovered how to move a buffer to another X window using C-x 5 2.
I find it convenient: since I use multiple displays, I can have one window with source and variables, and gdb's command line in another window.
But my problem is when I perform a step-by-step in gdb: when it opens another source file, it does that in the same window where the command line is located, while I expect it to be updated in the other window.
Does anybody know how to tweak gdb or emacs to do that? Thanks,
The value display-buffer-reuse-frames does address exactly this "issue". Session-wide setting in configuration file:
(setq-default display-buffer-reuse-frames t)
I've recently upgraded from Carbon Emacs (v22.3) to vanilla Emacs 23.2 (from http://www.emacsformacosx.com). On Carbon Emacs when compiling a project, The frame is split in two with the current source file/SConscript in the top window, and the compile output in the bottom window. I'd hit C-x ` to navigate to the first warning or error in the compile output and it would replace whatever was in the top window with the source file the error or warning is in.
In Emacs 23.2, however, a 3rd window is opened causing two windows open in the top half of the frame (split vertically) and the compile output in the window of the bottom half of the frame. How do I tell Emacs to not open a new window and instead open the code in the the existing non-compiler output window in the frame?
A little further clarification on the behavior that I just noticed. If I hit C-x ` while the buffer containing the source file or SConscript file is active, no new window is opened. It's only if I'm manually navigating through the *compilation* buffer and hitting enter on an error or warning, or mouse clicking on a warning when a third buffer window appears.
The function which is used in next-error functionality is pop-to-buffer which in turn uses split-window-sensibly. You can control the behavior of split-window-sensibly by adjusting the variables split-width-threshold and split-height-threshold.
In your case it is split-width-threshold which is too small. In my emacs 23.1 it is set to 160. Just set it to a larger number and the problem should be solved:
(setq split-width-threshold 200)
I can't reproduce this problem myself, but you might try the following:
(setq split-width-threshold nil)
This tells display-buffer never to split windows horizontally, even if they are quite wide. There is also a split-height-threshold variable which is handled similarly. Checking these variables' current values might suggest whether they could be relevant to the behavior you're seeing.
One last thing to check: if you have defined your own display-buffer-function, that could be making these decisions for you.