When I upgraded to (vanilla) emacs 24.1 on OSX, using iswitch for switching buffers seems to behave differently.
When I press ctrl-x b to switch buffers, instead of restricting the list of buffers to 1 line, it shows every single buffer by expanding the mini-buffer to be several lines long, then progressively removes buffers as I type in the buffer name I'm switching to.
I find having the status bar and mini buffer bumping up and down whenever I switch buffers to be visually distracting, so I want to recover the previous behavior, which cuts off buffer names which after 1 line. How do I do this?
If you want to globally restrict the number of lines the minibuffer uses to a single line, this should work:
(setq max-mini-window-height 1)
Additional info from documentation:
The variable max-mini-window-height controls the maximum height for
resizing the minibuffer window. A floating-point number specifies a
fraction of the frame's height; an integer specifies the maximum
number of lines; nil means do not resize the minibuffer window
automatically. The default value is 0.25.
However, if you just want to limit the number of minibuffer lines used by iswitchb, the documentation for iswitchb-minibuffer-setup-hook suggests:
Iswitchb-specific customization of minibuffer setup.
This hook is run during minibuffer setup if `iswitchb' is active.
For instance:
(add-hook 'iswitchb-minibuffer-setup-hook
(lambda ()
(set (make-local-variable 'max-mini-window-height) 3)))
will constrain the minibuffer to a maximum height of 3 lines when iswitchb is running.
I do not think this behavior has changed between Emacs 23 and Emacs 24, so I'm not sure why you only see this now. Maybe you had some customization to get this behavior, and it now fails to work in Emacs 24? If so, please report it so we can fix it.
Also note that with Emacs 24, the behavior of the default (non-iswitchb) buffer switching is very close to the behavior of iswitchb. The most visible difference is the display of potential completions which you can also get with M-x icomplete-mode, which does not affect the actual behavior, only the display, but also affects other completions. Also icomplete-mode does try to limit the completion list it displays to about one line (additionally to the actual minibuffer's content, so you will still get some line-wrapping, but less so).
Related
I can't get emacs to scroll horizontally!
To replicate the problem:
Open the *scratch* buffer.
Write a long line.
Make the long line exceed the window width with M-xtoggle-truncate-lines. The left hand text (column 0) will now be off the left of the window.
Try M-xscroll-left or its shortcut C-x < to scroll left.
Type y to enable the disabled commands.
NOTHING HAPPENS!
I also tried C-a to go to the beginning of the line.
I also tried M-xtoggle-horizontal-scroll-bar but got the error message "Horizontal scroll bars aren't implemented yet".
There seems to be no way to scroll horizontally!
I need this because I have many wide CSV files to read.
I'm using the latest prelude on emacs 24.5 on Windows 10.
I filed an issue on the prelude project in case it is a genuine bug and could be fixed there.
You seem not to understand how horizontal scrolling works. It's not intuitive, that's why the command is disabled by default.
When I press C-x< at the end of the long line, the line disappears to the left. When I press C-x> there, nothing happens.
Pressing C-x< at the beginning of the long line, though, shows the second part of the long line.
Consider using visual-line-mode or even the csv-mode instead.
There is new a feature in Emacs 26. You can customize mwheel-tilt-scroll-p and use mouse to scroll.
M-x customize group RET mouse
Then set mwheel-tilt-scroll-p to t
No need to handroll it yourself. This is provided out of the box in emacs 27, and it probably was available for longer:
This feature is off by default; the variable mouse-wheel-tilt-scroll turns it on, if you customize it to a non-nil value.
(setq mouse-wheel-tilt-scroll t)
Sounds like xemacs have horizontal scroll in a 'natural' way.
As far as I can see it there is a [Options] button in the menubar, when clicking on it there is a [Frame Appearance] sub menu and there, there are 2 button []scrollbars, [] Truncate Lines
When these 2 buttons are checked in, long line are truncated and scrolling is smooth.
May be xemacs is non standard though.
I use it, I find it easy to cut/paste even rectangular areas, selection is faster and more precise to me that what I could achieve with keyboard meta-ctrl-shift stroke alone.
Cheers
Phi
I
I've got emacs in front of me.
I've run a find-grep, and it's got many hits, which are displayed in a window. The file names are displayed in green as hyperlinks.
I make that the only window, with C-x 1.
If I click on a file name, the window splits vertically, and the file with the found text is displayed in the other window.
If I click on further filenames, then the new file replaces the old file, which is what I want to happen.
So far, so good...
However if I resize the windows, then emacs will periodically (when I click) split one of the two windows again, rendering the display difficult to read. It will then cycle opening new files between the two new windows. Occasionally it will open more windows and make the situation worse. If I close any of these new windows they just get reopened again.
In fact sometimes this perverse behaviour happens even if I don't resize anything. It just seems to happen more often if I do.
I would like emacs to stop buggering around and just have one find-grep window and one 'display' window, and always replace the display window with the new file. I would also like to be able to set these windows to the sizes that seem most convenient.
Is there any way to achieve this?
Or can anyone point me to an essay on how the whole (replace the contents of this window/replace the contents of a different window/create another window by splitting) thing works, so I can go and hack it sane.
Short fix:
Try doing this
(setq split-height-threshold nil
split-width-threshold nil)
This will prevent Emacs from splitting windows automatically (horizontally or vertically). This might be undesirable in other situations, but this should do the job. Try it for a week or so and see if it disrupts your flow.
Also, I found that if the point was in one of the windows, and I clicked on a link, the file opened up in the next window (if any).
So, if you want to make the file open in the right window (when you have more than one window), you can ensure that the point is in the window before the window you want.
Longer answer:
OK. I was able to reproduce the problem. The thing is the window showing the files is pretty big (wide or tall) because you resized it and Emacs sees that the width or height is greater than the respective threshold and splits it likewise. So, we have to either make the threshold higher or disallow the behaviour completely.
And, just to answer the last few questions:
To get current window - (selected-window)
To get next window - (next-window)
To select a window - (select-window foo-window)
To get the buffer of the current window - (current-buffer)
To get the buffer of some window - (window-buffer foo-window)
To set a buffer for a window - (set-window-buffer foo-window bar-buffer)
I'm sure you can hack together decent window/buffer management functions using these functions.
You can use C-h f to get more details on each of these functions.
Also check out the Elisp manual - http://www.chemie.fu-berlin.de/chemnet/use/info/elisp/elisp_26.html
I'm running Emacs 23.3.1 on Mac OS X. When I have linum-mode enable some lines are not numbered. Sometimes when my cursor scrolls past a line that is not numbered its number will appear and then sometimes it will disappear again. Is there away to prevent this from happening?
From your screenshot, it looks like lines with only comments are not numbered. Dunno why.
Perhaps there is another overlay at such positions, and it has a higher priority, thus masking the line-number overlay. Try turning off font-lock temporarily, to see whether that affects things. Then try increasing the priority of the line-number overlays. For a quick test, do this:
(defun foo ()
(dolist (ov linum-overlays)
(overlay-put ov 'priority 2000)))
(add-to-list 'post-command-hook 'foo t t)
If that helps, then instead of that, do the overlay-put (but try with a ower priority, say, 200) in function linum-update-window. IOW, add the priority when the overlay is put on the text.
In setting up my personal Linux command line development environment, I want to use term inside emacs b/c then I can switch to 'line mode' and copy/paste the output into any other buffer.
However, when I run mysql inside term inside emacs, the pretty sql tables still word wrap according to the width of that emacs window :(. I was hoping that emacs would truncate the bash output.
Is there a way to do this?
EDIT:
toggle-truncate-lines is on, so "word wrap" is off, but the problem is that before emacs even does anything with the text, the underlying bash process itself manually adds newlines to wrap text according to the width it's told it's using. That's at least how it acts. toggling truncate lines on/off doesn't change anything for me in the term buffer
I think what you probably want is "M-x toggle-truncate-lines". That toggles between wrapping or requiring you to scroll right and left to see the entire line.
You probably want to add something to the sql hook to turn off the wrapping:
(add-hook 'sql-interactive-mode-hook '(lambda () (toggle-truncate-lines 1))
I think Emacs might be setting the COLUMNS environment variable to indicate when the shell should wrap lines. Try setting it to a very large value and see if that helps.
I have no idea what other things this will break though.
Meta-X auto-fill-mode
This will toggle auto-fill mode and stop the line wrap.
The function term--unwrap-visible-long-lines is called by term-reset-size whenever the window is resized and appears to be responsible for the unwanted wrapping, and is not configurable. I hack this by advising the function to fix the wrapped width to a large value.
(defun my-prevent-term-unwrap (original-function height width)
(apply original-function (list height 10000)))
(advice-add 'term-reset-size :around 'my-prevent-term-unwrap)
I need to turn automatic margins off according the following statement from Screen's manual in my Mac
If your terminal is a "true"
auto-margin terminal (it doesn't allow
the last position on the screen
to be updated without scrolling the screen) consider using a version
of your terminal's termcap that
has automatic margins turned off.
How can you turn automatic margins off by your terminal's termcap?
Most terminal emulators, including the mac default terminal, are not "true auto-margin terminals" in the sense being discussed here - they emulate a vt100-series terminal, which had "smart" wraparound. You can check by running cat and typing to the end of the last line - after you type the last character, the cursor remains at the end of the line (highlighting the character you just typed) until you type another character.
The only consequence of a 'true auto-margin terminal' is that a character cannot be displayed in the lower right hand corner (though some programs are able to work around that by shifting a character into place with ich/ich1)
According to XTerm Control Sequences, this sequence should do what was asked:
CSI ? 7 l
That is,
printf '\033[?7l'
The 7 is documented as
Ps = 7 -> Wraparound Mode (DECAWM).
and the final character l (lowercase L) denotes this as a reset rather than a set control.
For whatever reason, the terminfo name for this is more obscure: "automatic margins". These terminfo capabilities deal with the feature (see terminfo(5)):
auto_right_margin am am terminal has auto‐
matic margins
enter_am_mode smam SA turn on automatic
margins
exit_am_mode rmam RA turn off automatic
margins
Interestingly, the vt100-nam terminal description in ncurses (which apparently no one uses) initializes the terminal to use automargins margins using this string:
rs2=\E>\E[?3l\E[?4l\E[?5l\E[?7h\E[?8h,
(the \E[?7h sets it), and asserts that the terminal does not use automatic margins by cancelling am. It also has the terminfo capabilities rmam and smam. So you could do this to prove that it works:
tput rmam
stty columns 999
ps -efwwwwwl
and (for the ordinary user) see the ps listing nicely truncated against the right margin of the terminal window.
The other variants vt220-nam and vt320-nam appear correct...
By the way, for Mac, you would use the terminfo names such as rmcup rather than the termcap RA, because OSX uses ncurses' tput (terminfo) rather than the BSD variant.
Further reading:
tput, reset - initialize a terminal or query terminfo
database
history section for tput
history section for tset
Occasionally someone asks about suppressing automargins because they suppose that terminals can pan/scroll left/right to show the information which was not wrapped to a new line. Terminals which do this are rare, and OSX Terminal is not one of those. It behaves like a subset of xterm, which itself emulates the series of DEC terminals vt52/vt100/vt220/etc. In this question, OP is concerned/confused about this paragraph from the screen manual:
If your terminal is a "true" auto-margin terminal (it doesn't allow the
last position on the screen to be updated without scrolling the screen)
consider using a version of your terminal's termcap that has automatic
margins turned off. This will ensure an accurate and optimal update of
the screen in all circumstances. Most terminals nowadays have "magic"
margins (automatic margins plus usable last column). This is the VT100
style type and perfectly suited for screen. If all you've got is a
"true" auto-margin terminal screen will be content to use it, but
updating a character put into the last position on the screen may not
be possible until the screen scrolls or the character is moved into a
safe position in some other way. This delay can be shortened by using a
terminal with insert-character capability.
That last position on the screen refers to the lower-right corner of the terminal. In the normal case, if your cursor is on the lower-right corner and you print a character, you would expect the display to scroll up by one line and show the character on the next line. Also (because terminals can be implemented in different ways), some could scroll up when you print a character in the last position. The VT100 does not do this. Not only does it not scroll up in that case, but it ignores non-printing characters while on the margin (see xterm FAQ That description of wrapping is odd, say more?). There is a terminfo flag xenl which is set to show when the terminal does this special behavior. About a third of the terminal descriptions in the terminal database have this flag. While most of those are for terminals which you likely will never encounter, keep in mind that the advice in the manual page was written back in an era when those other terminals were as likely to be found as a VT100-lookalike. The early change-history for screen is poor, but the text was in screen's second posting to Usenet in 1992. The initial posting in 1987 said something similar:
Screen
never writes in the last position of the screen, unless the boolean
capability LP is found in the termcap entry of the terminal.
Usually,
screen
cannot predict whether or not a particular terminal scrolls when
a character is written in the last column of the last line;
LP indicates that it is safe to write in this position.
Note that the LP capability is independent of am (automatic
margins); for certain terminals, such as the VT100, it is reasonable
to set am as well as LP in the corresponding termcap entry
(the VT100 does not move the cursor when a character is written in
the last column of each line).
The later wording reflects the fact that the terminfo system was prevalent, and the name LP was not termcap name chosen for corresponding with xenl (it is xn).
The point of all of this is that screen attempts to convert between programs writing to different terminal types and make them all appear like one type of terminal — which means that it tries to put text on the terminal's display in all of the locations. The lower-right corner is a problem because some terminals would scroll up, spoiling the attempt to write there. As a workaround, some terminals provided an alternative:
using a different mode (insert),
put the cursor on the next to last position of the display,
write characters to fill in, pushing a character into the last position, and
turn insert-mode off once it is done (otherwise a nuisance).
About two thirds of the descriptions in the terminal database have the capability to do this insert-mode (smir). That still was not perfect, but it certainly was worth mentioning in 1992. About a quarter implement a similar similar feature ich1. Some implement both (and vi could get confused by those, by trying to do both methods).
VT100-lookalikes provide a third way to write that last position; screen checks for and uses whatever is there.
If I understand you correctly you're looking to set the autowrap feature to NO using terminfo database. If so I believe you can use the -nam flag to turn it off - something like vt100-nam should do it. You can also check by looking at the man pages for terminfo.
If this solves your question, mark this up. (^_^) If not... well comment back and I'll check again for you. Cheers!
Update: There's also a shortcut that may apply to you to toggle the wrap off and on. Check out the shortcut sheet here. And additional information for Screen can be found here (search for wrap). You can also check here on how to use setterm (section 17.14 Changing the Terminal Settings). Also check here for examples of changing settings.
Good luck again. (^_^)