In an 80 column wide terminal emacs wraps 80 column lines, putting a backslash in the 80th column. Is there a way to tell emacs to use all 80 columns of my terminal and not wrap lines until they reach 81 characters?
If I understand this question correctly, this is not about logical line
wrapping (how lines are segmented in your file), but about visual wrapping
(how lines are displayed with respect to window width).
If you just want the display to visually wrap more than zero characters before
window boundary, and thus avoid the backslash everywhere, however long your logical lines really are, you can use longlines-mode
:
Unlike Visual Line mode, Long Lines mode breaks long lines at the fill column (see Fill Commands), rather than the right window edge. To enable Long Lines mode, type M-x longlines-mode. If the text is full of long lines, this also immediately “wraps” them all.
Then, it's only a matter of setting the fill-column appropriately, using
either global settings (.emacs, though you probably want to use a
specific mode-hook for that particular case), local settings (file
variable, dir-locals) or C-u 79 C-uC-x
f to set variable fill-column to 79. This way, lines 79
characters or higher will wrap, but before touching the right edge of the
80-char window (and thus never leaving an ugly backslash character). Your
file will be untouched.
If you simply want no visual wrapping to occur on 80-character lines, and thus do not want the 80th logical character visually displayed below the first, there are two
possible answers:
either you work in an environment where you don't necessarily wrap
logically at or before 80 characters, and you want to see the end of
those 81+ lines somewhere in your screen (i.e. you do want visual wrap, but at a number of chars above the window width), then I don't know how to do
it.
or you want to stop your lines at 80 chars logically (e.g. you
have auto-fill on and fill-column at 80), and if you do happen to have
lines 81 characters or more, you don't care about seeing their ending.
In that case, activate truncate-mode (toggle-truncate-lines).
If the issue is about the last character of your window, and what you really want is the 80th logical character of your line to be displayed on the 80th visual character of your window, though, I'm afraid I don't know how. Either you are truncating lines (as above), and the last character of your window will be a $, or you let emacs do its thing, and the last character will be a backslash.
Note when testing that auto-fill's wrapping (but also longlines-mode's, since it is its visual equivalent) will occur only at word boundaries.
One option is to set the wrapping to happen at 81, instead of 80.
M-x set-fill-column RET 81
Another option, maybe the best choice, is to define the variable overflow-newline-into-fringe as t. Try this once, manually:
M-x set-variable RET overflow-newline-into-fringe RET t
Either of these could be set by default. You can do that through M-x customize or by editing your .emacs file. Post again if you need help.
BTW, do you use emacs in a graphical or terminal environment? In a graphical environment, I often just make the window larger if I have long lines. Or I may turn on line truncation with a horizontal scrollbar.
added later
With the added information that you are running emacs in terminal mode, as you discovered, none of those options work. I tried an example running emacs in putty, where I can change the size of the window and emacs picks it right up. So, I could size to 81 columns and my 80-column lines remain intact without continuation. I am not sure which TERM value you have assigned with tmux, but you could consider creating a custom terminal type (termcap or terminfo) which supports 81 columns. I only took a brief glance at tmux but I noticed that you can resize panes within a terminal.
Now, out of curiosity, what is the primary motivator for you using tmux? I would think that the resume capability would be valuable. I would find however, that the other features are not that useful because in an X-Window environment it is cheap & easy to open more terminals or if I am using putty, I can create more of those. As far as using emacs, whether I am running under X-Window or MS-Windows, I just create as many frames as I would like and can work quite easily with that. So, is there something else that makes you interested in using tmux?
Six years after the previous answers and the workaround I still use is to use 81 character-wide windows.
Unfortunately 80-wide windows that wrap 'correctly' are not possible because of evil fringe characters. Emacs requires the last (fringe) character to have exclusive use of the final column. The argument for this is an optional fringe character is ambiguous. I dream of the day someone will submit a patch to make the fringe character optional, and perhaps solving the ambiguity with a background color.
I don't think that is prossible in general, because emacs needs at least one character to indicate that the line continues in the next line (wraps), although I'm not sure, because emacs has so many options... You could maybe instead select "Word Wrap (Visual Line Mode)" in the "Options" menu (or keyboard):
M-x visual-line-modeRET
This makes the flow more natural, without showing (at least in text modes) the indication of wrapping.
Related
I have a text that I already typed in a text editor, but when I open it in Emacs, so I can keep working o Emacs (Org-Mode), it appears it is not wrapping the lines propperly. The paragraph (or what it is supposed to be a paragraph) appears in a single line, instead of having a line break when reaching the screen limit.
Do you guys know how to reformat these line breaks?
Emacs has a built-in variable called word-wrap, which has a default value of nil. When word-wrap is nil, long lines are wrapped indiscriminately at the window-edge without consideration as to whether a whole word is visually broken up -- i.e., part of a word may be at the end of the visually wrapped line and part of the word may be at the beginning of the subsequent visually wrapped line.
The most common method of enabling word-wrap is to use the built-in visual-line-mode: http://www.gnu.org/software/emacs/manual/html_node/emacs/Visual-Line-Mode.html Visual line mode includes a few other goodies, like remapping certain keyboard shortcuts and pretty bitmap images in the fringes if they are visible in the window. Enabling visual-line-mode can be accomplished a number of ways -- one example is manually: M-x visual-line-mode
By default, Emacs 24 can handle Arabic, Hebrew, and other right-to-left (RTL) languages. I have multilingual term emulators that handle this in X, but I would like to use eshell inside emacs to see the non-English character filenames (and boy do I have many). When I use eshell, the characters are not in the correct order and it spells out gibberish. (setq-default bidi-display-reordering t) (which is default) makes no difference obviously.
Is this possible?
I believe you're getting double reordering by emacs + mlterm, and need to disable one.
Your screenshot shows in upper half mlterm successfully detects line-by-line base direction and reorders characters.
And Emacs 24 by default reorders bidi in the terminal, assuming a non-bidi LTR termianl.
Combining both results in double reordering ABC -> CBA -> ABC.
You have 2 options:
Disable bidi in mlterm (at least while running emacs, not sure how to automate that).
Disable bidi in emacs (at least when running under mlterm).
I.e. set bidi-display-reordering to nil, not t.
I expect the first will work better. mlterm can only give you a dumb "bidi display" layer, which may be confusing on top of an editor; emacs gives you "bidi editing" where someone thought of how the whole interaction should work.
Specifically, side-by-side "windows" within emacs should work well when emacs is doing the bidi and break horribly when mlterm is.
OTOH, mouse copy-paste probably works better when mlterm is doing the bidi.
If emacs sends reordered chars, that's what mlterm mouse selection will copy.
Emacs can mostly take over mouse with xterm-mouse-mode but (untested speculation) it works on terminal coordinates and would need extra work to match them to logical-order text.
P.S. I'm not sure why the end result is right-aligned, as it seems there is a blank line before so Emacs should consider it a new paragraph, decide it's RTL and send right-aligned text to mlterm, and I'd expect mlterm to then reverse the line resulting in it left-aligned. I'm probably missing something.
I'm a beginner with emacs. Altough I'm finding it amusing and challenging, I still don't know some basic things, like, when I open a text or a piece of script wrote in another editors, emacs don't show the text formatted properly (missing all tabs, all text left-aligned) and vice-versa.
Also, when I copy a link with emacs with M-w, my clipboard is still empty and I can't paste it in a browser. I already did my "homework". I've read the tutorial and I'm almost finishing the manual and didn't see anything to address that.
tnx in advance.
Some editors, like Intellij IDEA for example, will indent code based on how they understand it and not based on how it was actually indented, there's no Emacs mode that operates in the same way, not to my best knowledge. If you were using something like Eclipse or MS Visual Studio before - then you probably just have a different size of tab character (this is why some programmers insist on indenting code with spaces rather than tabs). But the width of the tab character is adjustable. In order to customize it you would:
add in your initialization file (usually .emacs file in your $HOME directory, you can create one, if it is not there yet):
;; makes tab character as wide as four space characters
(setq default-tab-width 4)
though some other major editing modes override this variable, you would need to tell what language you are dealing with to get better instructions.
Clipboard, see this answer: How to copy text from Emacs to another application on Linux if you are on Linux, then likely you need to set x-select-enable-clipboard to t.
Aligning text to the right (or left for LTR languages) is not possible in Emacs, as far as I understand. You could align block of text, if you split it into lines and align on the line ends, but that would mean aligning by adding spaces at the beginning - something you don't really want to do.
Tabs should work (you might need to fix the width). Use mouse to select to the clipboard, or use CtrlInsert to copy and ShiftDelete to cut.
Assuming emacs has picked the right mode for the file - it usually does - you can press C-x h to select all, then TAB to indent all selected lines. What other editors are you using, and what platform(s)?
As for the clipboard issue, some builds of emacs work correctly with the native clipboard, some don't. You might want to investigate CUA mode.
I decided that I was ready to try something new, after a few years of using gEdit for most of my coding needs, and try to learn using Emacs. I knew this would be difficult, as I have heard how complex Emacs can be, but I was lured by its power. The hardest thing has been getting used to writing ELisp in the .emacs file to change things about the editor. I can't currently do it myself, but I have found a few helpful snippets here and there to change some options.
One thing I have been having a lot of problems with is getting Emacs to remember the text I have selected after a command. For instance, I commonly highlight a section of code to mass indent it. However, if I do this in Emacs, it will move the selected text only once before unselecting all of the text. Does anyone know a way around this?
Anyway, I apologize for what seems to me to be an easy question, but after an hour of Google searching and looking around here on SO, I thought it was worth asking. I have a few more questions about Emacs, but I will save them and ask separately after I get this straightened out. Thanks!
UPDATE
A few people have asked about what mod I am using and what type of text I am entering. While I don't know much about Emacs modes, I am editing a pure text file at the moment. Something like this:
Hello, I am a simple text file
that is made up of three separate
lines.
If I highlight all three lines and hit TAB, I get this:
Hello, I am a simple text file
that is made up of three separate
lines.
This is great, however, if I use C-x C-x like some suggest below to reselect the text and hit TAB again, I get this:
Hello, I am a simple text file
that is made up of three separate
lines.
I hope this helps!
FWIW, here is the reason for the behaviour of your newly-added example. (I'm not 'solving' the issue here, but I'm posting it to demystify what you're seeing.)
This was determined with emacs -q which disables my customisations, so the following is default behaviour for emacs 23.2.
You are in text-mode. You should see (Text) or similar in the mode line at the bottom of the screen, and C-h m will tell you (under the list of minor modes) "Text mode: Major mode for editing text written for humans to read." Emacs decides (by way of the auto-mode-alist variable) that it should switch to text-mode if you visit a filename matching certain extensions (such as .txt).
In text-mode pressing TAB with a region highlighted causes indent-according-to-mode to be called on each line of the region in sequence. The slightly convoluted path to finding this out starts at C-h k TAB, which tells us that TAB is bound to indent-for-tab-command, which in this instance calls indent-region -- that function name is not stated explicitly in the help, but can be seen in the code -- which checks the buffer-local indent-region-function variable, which is nil, and: "A value of nil means really run indent-according-to-mode on each line."
indent-according-to-mode checks the indent-line-function variable, which has the buffer-local value indent-relative.
Use C-h f indent-relative RET to see the help for this function. (Read this).
Although you probably won't yet have had the experience to know how to check all that (or necessarily even want to!), and fully understand everything it tells you, this is an example of how the self-documenting aspect of Emacs enables a user to figure out what is going on (which then makes it feasible to change things). I essentially just used C-h k (describe-key), C-h f (describe-function), and C-h v (describe-variable) to follow the documentation. Looking at the source code for indent-for-tab-command was as simple as clicking the file name shown as part of its help page.
I suggest doing the following to help see what is happening when indent-relative runs on each line:
M-x set-variable x-stretch-cursor t
M-x set-variable ruler-mode-show-tab-stops t
M-x ruler-mode
Now for each line in turn, put the cursor at the very start of the line and press TAB. You'll end up with all three lines indented to the first tab-stop ('T' in the ruler).
Now repeat this -- again, ensure you are at the very start of each line, in front of the existing indentation.
The first character of the first line (which is currently a tab) is once again indented to the first tab-stop, as there is no preceding line for it to examine.
Next, the first character of the second line is indented to match the position of the first non-white-space character of the preceding line. Because the first character of the second line is also a tab, the actual text of the second line is pushed one tab further along.
The third line follows suit. Its first tab character is lined up with the first non-white-space character of the second line, with the same relative effect as before, giving you the final state in your example.
To emphasise, note what happens if you now put enter the line "a b c" above the existing lines, then move back to the start of the next line (what was previously the first line) and press TAB. The first tab character will now be indented in line with the 'b'. Provided that the indent-tabs-mode variable is true (meaning you have actual tab characters), then this will have no practical effect on the position of the words in the line, as 'indenting' a tab with spaces will not have an effect until the number of spaces exceeds the width of the tab (but that's another kettle of fish entirely!)
All this really means is that text-mode in Emacs doesn't behave the way you'd like it to in this situation. Other major modes can do completely different things when you press TAB, of course.
As is invariably the case with Emacs, things you don't like can be changed or circumvented with elisp. Some searching (especially at the Emacs Wiki) will frequently turn up useful solutions to problems you encounter.
Try typing C-x C-x after Emacs unselects it.
Then, instead of hitting tab (I never knew that tab does what you said! That's totally whacked.), do M-8 C-x C-i. Pity it's so many keys, but it ought to do what you want -- namely, shove everything over 8 columns. Obviously replace the M-8 with something else if you want some other number of columns.
What I usually do is simply type C-x C-x (exchange-point-and-mark) after a command that deactives the region.
How are you indenting, and in which mode?
The indentation rules in any programming mode should generally just get it right. (If they don't, that's probably more indicative that you want to configure the rules for that mode differently, but I suspect that's a different question which has been asked already).
If you're in text-mode or similar and just using TAB, then I can see the problem.
Note that if you're using indent-rigidly (C-x C-i, or C-x TAB which is the same thing) then you can repeatedly indent the same region simply by repeating the command, even if the highlighting has disappeared from view.
You can also use a prefix arg to indent-rigidly to make it indent many times. e.g. C-u C-u C-x C-i (easier to type than it looks) will indent 16 spaces (4 x 4, as the prefix arg defaults to 4, and it multiplies on each repeat). Similarly, M-8 C-x C-i indents 8 spaces. This is fine in some circumstances, and way too cumbersome in others.
Personally I suggest putting (cua-selection-mode 1) into your .emacs and using that for rigid indentation. Trey Jackson made a handy blog about it. With this, you can C-RET to start rectangle selection, down as many lines as you need, TAB repeatedly to indent the lines, and C-RET to exit the mode.
While the rectangle is active, RET cycles through the corners. For left-hand corners, typing inserts in front. For right-hand corners, typing inserts after. For the single-column rectangle, bottom counts as 'left' and top counts as 'right' for this purpose.
Trey's blog lists all the available features (or look in the source file: cua-base.el)
Be warned that indentation in Emacs is generally an unexpectedly complicated topic.
You can do this with something like the following:
(add-hook 'text-mode-hook (lambda ()
(set (make-local-variable 'indent-region-function)
(lambda (s e)
(indent-rigidly s e tab-width)))))
Then selecting a region and hitting TAB. will indent the region by a tab-width. You can then exchange point and mark with C-x C-x and hit TAB again to repeat.
I do, however, agree with the previous answers that suggest using indent-rigidly directly.
If I have a multiline sentence in Emacs it naturally overflows onto the the following lines. Now, if my cursor is at the beginning of such a sentence and I press the DOWN ARROW key, the cursor is placed at the beginning of the next sentence (which might be at 4-5 lines down), rather than on the next line itself (which other editors do). Same is the behavior of the END and HOME keys.
Is there a way in which I can change this behavior and get the cursor on the next line instead of the next sentence?
I haven't yet tried it myself, but I think what you are asking for is the default behavior for emacs 23. What version are you running?
You might want to check out the page Move By Visible Lines page on the emacswiki.
You might want to try auto-fill-mode or longlines-mode. To get either use M-X then type the command you want. Toggle them off the same way.
If that doesn't work you may want to examine the binding that is being applied to your down arrow. Type C-h k then hit the down arrow key.
It sounds as though the text is wrapping, so by definition (a line being a group of characters separated by a carriage return), it is moving down to the next line.
I agree it is a pain, however a lot of other editors also have this behaviour.
One way is to turn off wrapping:
M-x toggle-truncate-lines
You wont be able to see all of the text in the editor, however it will move down to the next line.