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)
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'm editing python code using emacs, elpy and magit. When starting emacs using the -nw option (from bash and gnome-terminal in gnome 3). When started this way, emacs highlight the indented blocks of code using a black background single character; when using a graphic display (without the -nw option), the same character is a light gray. Please check out the two attached screenshots:
Is there a way to modify the darkness of the face in order make it less prominent?
I found a solutions that works. I'm not sure if it's the best one: if anybody knows a better way to do this, please comment!
In short:
Place the cursor on the indented block;
M-x customize-face;
Select the default value (highlight-indentation-face);
Select Show all (the face inherit from fringes);
Tick Background (this will overwrite the fringe background color);
Choose the white color (which is aliased to #e5e5e5)
Press Apply and Save
The last step will write few lines to the ~/.emacs file (on linux) to preserve the customization values. In my system, the lines that were added are:
(custom-set-variables)
(custom-set-faces
'(highlight-indentation-face ((t (:inherit fringe :background "white")))))
In emacs shell, invoked using M-x shell, input lines under the cursor are highlighted, so you can then "mouse 2: insert after prompt as new input" to repeat the command. I'd prefer not to have this activated and just select text under the mouse as I do in a regular terminal and middle click to insert (I know I can do this in emacs but I don't get any visual feedback until I stop the mouse selection).
Is there any way to do this? I've done quite a bit of searching and can't find anything.
That message comes from this function in comint.el.
Setting comint-use-prompt-regexp to a non-nil value should do what you want.
A good solution would probably be something like this (put the following somewhere in your initialization; regexp taken from comint-prompt-regexp docstring):
(add-hook 'shell-mode-hook
(lambda ()
(set (make-local-variable 'comint-use-prompt-regexp) t)
(set (make-local-variable 'comint-prompt-regexp) "^[^#$%>\n]*[#$%>] *")))
You do not specify the version of Emacs and I do not see that behaviour in my Emacs why I type M-x shell. However, a little googling turned up this:
(setq comint-highlight-input nil)
which is something that you can set in ~/.emacs.
This variable does not exist in GNU Emacs 25, even though there is a reference to a specific face (highlighting) to use in that case. Either that is a mere reminisence from when the feature was available or it is something that is actually enabled with another package. You can test by starting emacs with the "-Q" option and start shell as the first thing, if the behaviour does not appear, it is something that is related to your startup configuration or something you do before starting the shell.
The post in which the above variable was mentioned can be seen here:
https://stat.ethz.ch/pipermail/ess-help/2002-August/001134.html
Emacs 23.1.1 Ediff 2.81.2 on CentOs 6
Prior to any customization, Ediff would, by default, split the windows horizontally (one on top of the other).
I wanted them side by side so I tried adding the following lines to my .emacs
(setq ediff-split-window-function 'split-window-vertically)
(setq ediff-merge-split-window-function 'split-window-vertically)
This had no effect - the windows were still split horizontally. I also tried using the Emacs Customization interface for Ediff to get the vertical split by default - same story.
Note that I tried this in a comparison with two buffers that were vertically split. I also tried it with no files open in buffers and asked Ediff to compare two files - same result.
Then I tried specifying split-window-horizontally as the split window function for both ediff-split and ediff-merge.
(setq ediff-split-window-function 'split-window-horizontally)
(setq ediff-merge-split-window-function 'split-window-horizontally)
This caused the windows to split vertically (next to each other). This was also true when I commented out these lines and used the Emacs Customization interface to set these options.
And yes, I've seen this question but I don't want to eliminate horizontal splitting on a global basis - I just want Ediff to do it by default.
Am I losing my mind or has someone switched the meaning of "horizontal" and "vertical" (and by the way, I'm taking the definition of "vertical" and "horizontal" splitting from my copy of the O'Reilly book "Learning Gnu Emacs")?
I used emacs variable customization, invoked with C-h v ediff-split-window-function to change the value. After clicking Save for future sessions the following was written to my .emacs:
(custom-set-variables
...
'(ediff-split-window-function (quote split-window-horizontally))
...)
And it does exactly what I want: putting the two buffers side-by-side. And yes, emacs uses horizontal/vertical in the opposite of what you had in mind.
If you read this question again, you will see the explanation, others were confused, too.
Hitting "|" when you are in ediff mode with the 2 files loaded switches from horizontal to vertical.
"?" gives a little ediff help menu.
(I'm on Debian Wheezy with emacs 23.4+1-4)
While it doesn't quite answer your problem, you could also use a function to specify whether to split vertically or horizontally depending on window dimensions:
(setq ediff-split-window-function 'split-window-sensibly)
split-window-sensibly is built-in.
Im facing some problems, I looked around in the forum and didnt find
any solutions discussed. Im sorry if these have been resolved earlier.
Is there someway I can make the VIM line break after 80 characters. I
dont want the text to wrap around but create a new line. And I wish it would
break off the complete last word. So instead of fo in the previous and o
in the next line, can it break with foo in the next line?
When I end my comment and press enter, I get a # in the new line. This is
cool but when I delete # and want to start a line of code, I dont get syntax
highlighting there. It still thinks what Im typing is a comment. Is this a
bug or am I doing it wrong?
One more thing is that I have set the shiftwidth to 4. But when I press
Ctrl+S to save the document, the cursor jumps to the beginning of the
sentence. I then need to manually go back to my original position to begin
the code. Is there a way I can resolve this?
Thank you for reading this. I am new to Ruby and Vim. I hope you guys help
me out.
Ctrl-S ? This is not known to me. In Vim/Gvim, a file is usually saved by
:w filename.ext (if none's been given yet)
or
:saveas filename.ext
(for all of these commands try ":help :w" or ... the same principle).
I don't know about the comment part, since I don't do Ruby, but it would be pretty wise for you to get yourself a nice commenter plugin (I think I use LineCommenter) - eases up on the commenting. Just write the comment, and add the #'s later (set it to work in normal and in visual mode; it works beautifully).
As for the breaking the text part, that could be solved by adding
:set tw=80
"wrapscan" is the vim feature that wraps a whole word to the next line; it might not be set by default in your configuration - probably isn't. So in addition to
:set tw=78 you probably want to try one of these:
:set wrapscan
:set wrap <- just a shorter version
:set nowrap <- to turn the wordwrap feature back off
Incidentally, rather than setting the text width (tw) to some number of characters (smaller than your window), you could instead set the margin you want to leave on the right side of the window like so:
:set wrapmargin=1
If wrapmargin is set to something other than 0, textwidth should be ignored.
I would use ":w" to save and continue editing (or ":w filename" if it's a new file) and "ZZ" or ":wq" to save-and-exit when you're done - none of those will move the cursor position.
I'm not sure where your "#" continuation is coming from, but I'd also make sure to set these if they aren't already (you can check what variables are set by just typing ":set" with no other options):
:set syntax=ruby
:set filetype=ruby
:syntax enable
If you started with an empty document and then added "#!/usr/bin/ruby" to it, vim won't notice you're editing ruby until you save&exit and reopen the file. There are other cases where syntax coloring isn't very bright or needs a nudge but yes, that sounds like a bug to me.