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.
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
When using a term mode derivative (like ansi-term or multi-term), I often want to select a region and copy it someplace else. If that region includes a line which wraps at the edge of the terminal window, pasting that region in another buffer always inserts a hard newline at the place where term wrapped the line. This means I often have to go back and clean up pasted text. Is there a way to avoid doing this? I tried both term-line-mode and term-char-mode; both do the same thing.
I do not want to write a yank hook which strips out all newlines, since I want to preserve existing hard newlines in the original content.
This works for me:
(setq term-suppress-hard-newline t)
It's not that convenient when you do a typo during an incremental search and the search string receives the wrongly typed character. Is there a way to prevent this. As if control-g was pressed automatically on error.
For example we have the following text:
keywords
keys
Default emacs behavior:
We start incremental search and search for "keyz"
The "keyz" is displayed in the search echo area and the "key" part in "keywords" is higlighted
We press s
"keys" won't be found, the cursor stays on the "keywords" line, search echo area displays "keyzs", which is not convenient
Needed behavior:
We start incremental search and search for "keyz"
The "key" is displayed in the search echo area and the "key" part in "keywords" is higlighted
We press s
"keys" is found and highlited
You could try something like
(defadvice isearch-printing-char (before drop-mismatches-on-next-char activate)
(while (or (not isearch-success) isearch-error)
(isearch-pop-state)))
Emacs keeps the incorrect part, because it happens very often that you search for a string and it is not found, but not because it's incorrect, only the search string is found before the cursor. In this case it is very convenient that you can press C-s and the search starts from the beginning of the file.
It is very useful behavior and it happens to me more often than mistyping the search string. If there is indeed an error in the search string then you can simply press C-g to go back to last good search string.
I think the problem is that you're not thinking about searching in a way that's congruent with the way isearch has been designed to work, and so your question doesn't really make sense within the context of isearch as it currently exists.
Isearch does already give you exactly the feature what you want, but you have to tell it that you want it to happen by typing that C-g you seem so vehemently opposed to typing. If you don't tell isearch what you want to do, and when you want it to do it, how is it supposed to know what to do?
As #Tom tried to explain, the default way isearch starts from the current position in the buffer, and can restart at the beginning of the buffer if you've typed some failed characters and then press C-s, is a very valuable feature. I'm sure many people rely on this behaviour. Your method of using a macro to always start an isearch at the beginning of the buffer would confound and confuse many of us, though of course it's not a bad thing for someone such as yourself who is accustomed to it. It does mean though that the rest of us are quite confused by your dislike for having to press C-g to delete the non-matching text.
Think also for a moment about what a second C-s does if you press it immediately after starting isearch (any time but the first time in a session) (i.e. before you type any other character). Note in particular what happens if your previous search string would only partly match something in the current buffer, and then you press C-g (and also note how the failed search string is presented, regardless of whether it would partly match something in the current buffer or not).
Think also about how your feature might adversely affect the use of multi-isearch-next-buffer-function.
Claiming that other editors can do what you want isearch to do in emacs doesn't really help your case much.
I think what you really want is some slightly different type of search function which only allows you to search for text that it is possible to find in the current buffer, instead of isearch's ability to search for anything whether that text happens to exist in the current buffer or not.
Perhaps isearch-mode could be adapted to do what you want it to do, but one way or another I think you'll have to write some elisp code. Perhaps you could implement your new search mode as an option within isearch-mode that can be toggled on and off in the same way case sensitivity can be toggled on and off; and that can be set by default, again in the same way that case sensitivity can be turned on or off by default.
If you make a typo during incremental search all you need to do it press backspace to correct the typo.
We start incremental search and search for "keyz"
The "keyz" is displayed in the search echo area and the "key" part in "keywords" is higlighted
We press backspace
We press s
"keys" is found and highlited
As with most of the other answers, I'm just pointing out another feature which helps mitigate the described problem. This one is particularly useful if you've continued to type several would-have-been-good characters after the bad one.
M-e is the binding for editing the isearch string, and in the case where there are no matches for the current string, it rather helpfully places point at the first non-matching character.
So if you have made a small typo, you can quickly type M-e, fix the mistake, and type RET to return to isearch using the corrected search string.
I have 2 columns, separated by comma. How can I swap those columns with Emacs?
I have the following:
column 1,column2
x1,x2
y1,y2
f1,f2
and I want it like this:
column2,column 1
x2,x1
y2,y1
f2,f1
Use M-x query-replace-regexp and then:
\(.+\),\(.+\)
as replace regexp and
\2,\1
for replacement.
In Emacs, you need to escape grouping parentheses with \. So, above regexp would be usually written as
(.+),(.+)
which means that you want everything before comma in first group and everything after comma in second group.
\2,\1
means: write second group, then comma, then first group.
While you can apply techniques given by other people, you can also use the org-mode tables.
Once you convert the data into org-mode table, it is very easy to swap the columns by simple keystrokes. You can have M-x org-mode, select the region then do M-x org-table-convert-region, and then M- on the right most column. I am not sure, how to export the data as CSV, but that should be very easy for you with replace-regexp. This can be helpful: http://www.gnu.org/software/emacs/manual/html_node/org/Tables.html#Tables
Similar to the answer given by #darioo, type the following into the top of your buffer:
(query-replace-regexp "\\(.*?\\),\\(.*\\)" "\\2,\\1")
Then, put your cursor at the end of this line and press ctrl-x, ctrl-e.
You will have an interactive search-and-replace for which you press the space bar to make the change, and press ctrl-g to quit. If you press ! (exclamation mark) then the search will cease being interactive and take place on all matching text.
If you want to reverse the changes then press M-x (usually ESC followed by x) and type undo and press enter.
Emacs has a rectangular selection mode, see for example: http://emacs-fu.blogspot.com/2008/12/working-with-rectangular-selections.html
Even better, if you enable cua-mode, entering Ctrl-Enter will put you in rectangle selection mode that is very easy to use.
http://trey-jackson.blogspot.com/2008/10/emacs-tip-26-cua-mode-specifically.html
Use a macro !
Go to the first line of the buffer
Start recording a macro (F3)
Move to the beginning of the line (^a)
Search for comma (^s ,)
Transpose (M-t)
Move cursor down one line
Stop recording macro (F4)
Select the rest of the lines and:
M-x apply-macro-to-region-lines
UPDATE: This doesn't work properly if you have multiple words in a column. Looking for a more general solution...
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.