It seems in this scenario:
*** Point 1|
If I hit enter
*** Point 1
|
the cursor is placed on the first column of the next line. How do I make it such that when I hit enter the cursor is placed thus:
*** Point 1
*** |
Related
Say you have a tree of the following form:
* Top
** Item A
*** Lower
** Item B
** Item C
What I would like to do is to be able to make a region containing Item A and Item B, and have a command run to change it into this:
* Top
**
*** Item A
**** Lower
*** Item B
** Item C
With the cursor at the blank item. I am wondering if something similar is already written into org-mode. If not, I can write it myself, but in that case I am wondering how I should loop through the lines in my region to shift them, avoiding items which are on a lower level than my starting one.
A naive first try
Starting with the outline
* Top
** Item A
*** Lower
** Item B
** Item C
If I place my cursor after Top and press Alt + Return (org-insert-heading) followed by Alt + Shift + right (org-demote-subtree) I get the structure
* Top
**
*** Item A
**** Lower
*** Item B
*** Item C
Unfortunately this demotes Item C, which you don't seem to want. However, you can just navigate to this item and press Alt + Shift + left. However, I imagine that this is a simplified example and want a more powerful method which doesn't involve moving around the file too much. Can we do better?
Transient mark mode
Reading through structure editing in the Org mode manual I found the note
When there is an active region (Transient Mark mode), promotion and demotion work on all headlines in the region. To select a region of headlines, it is best to place both point and mark at the beginning of a line, mark at the beginning of the first headline, and point at the line just after the last headline to change.
So perhaps this gives us a way forward. However, I haven't been able to do anything sensible with this information. Hopefully someone else can step and and show us how it is done.
Narrowing to a region
One other way we can move more is to "narrow" the buffer to only the region we want to work on.
Select the lines * Top, ** Item B in full and everything in between (with your mouse or by, for example, using Ctrl + Space and Ctrl + c + Ctrl + n (outline-next-visible-heading) a few times). We can now focus our attention on only this highlighted (or marked) region by "narrowing" the buffer to only this region, to the exclusion of all other text in the buffer (we won't delete the text, even though it will look that way, we'll just hide it for a bit. We narrow to the region by using Ctrl + x + n + n (narrow-to-region) (note the helpful message that appears if you haven't explicitly enabled this feature). We can always get back to the full buffer by using Ctrl + x + n + w (widen).
In our narrowed buffer we can now only see:
* Top
** Item A
*** Lower
** Item B
If we now repeat the steps from our naive try (see above) and then returning to the full (widened) buffer we see that we have the outline:
* Top
**
*** Item A
**** Lower
*** Item B
** Item C
which is the final result we were after! My apologise if this is an unnecessarily long answer. I learnt a lot researching it and wanted to document it all here.
Based off Chris's answer, I came up with the following code:
(defun org-file-region (start end)
"Moves the lines in region to be underneath a new header"
(interactive "r")
(extend-region-to-lines start end)
(narrow-to-region (save-excursion (goto-char start)
(line-beginning-position))
(save-excursion (goto-char end)
(line-end-position)))
(org-do-demote)
(org-insert-heading)
(setq mark-active nil)
(org-do-promote)
(setq mark-active t)
(widen))
Note that only org-do-demote will operate on the region; the other demotion functions do not.
This is some variation of a problem already mentioned, but I can't figure out what exactly.
I have my frame split in three windows:
----------------
| | |
| |------|
| |shell |
----------------
When I'm typing the shell, I do "tab" to get completions. They appear in the window on the left. Then emacs doesn't close the buffer, but the entire window, and I'm left with a horizontally split screen:
----------------
| |
|--------------|
| shell |
----------------
I'm not sure I understand how to stop this from happening, and it's not a problem I remember ever having. My botched attempts managed to get to the state where emacs would not close the completion suggestion buffer at all, but that's not ideal either.
What can I do to have emacs normally close the completion buffer, but leave my window alone?
M-x dedicated-mode
;; This minor mode allows you to toggle a window's "dedicated" flag.
;; When a window is "dedicated", Emacs will not select files into that
;; window. This can be quite handy since many commands will use
;; another window to show results (e.g., compilation mode, starting
;; info, etc.) A dedicated window won't be used for such a purpose.
;;
;; Dedicated buffers will have "D" shown in the mode line.
So in the Scala REPL, I can use the ctrl-{p,n,a,e} to do previous-, next-, beginning of- and end of line. However, I'll soon go crazy if I can't use ctrl-d to forward-delete.
Is it possible to achieve this in some way?
I'm using a Mac.
Update
Add the following lines to the accepted answer to get ctrl-{a,e}. A larger keybindings file kan be found in the jline2 repo jline2 repo at GitHub.
# CTRL-A: move to the beginning of the line
1=MOVE_TO_BEG
# CTRL-E: move the cursor to the end of the line
5=MOVE_TO_END
Update2
I just installed Scala 2.9.0.final and I can confirm that the ctrl-d is now working as it should. It's forward delete unless it's an empty line when it terminates the shell.
Here's a very minimal keybinding property file, including your desired ^D:
# CTRL-B: move to the previous character
2: PREV_CHAR
# CTRL-D: delete the previous character
4: DELETE_NEXT_CHAR
# CTRL-F: move to the next character
6: NEXT_CHAR
# BACKSPACE, CTRL-H: delete the previous character
# 8 is the ASCII code for backspace and therefor
# deleting the previous character
8: DELETE_PREV_CHAR
# TAB, CTRL-I: signal that console completion should be attempted
9: COMPLETE
# CTRL-J, CTRL-M: newline
10: NEWLINE
# ENTER: newline
13: NEWLINE
# CTRL-N: scroll to the next element in the history buffer
14: NEXT_HISTORY
# CTRL-P: scroll to the previous element in the history buffer
16: PREV_HISTORY
# CTRL-V: paste the contents of the clipboard (useful for Windows terminal)
22: PASTE
# DELETE, CTRL-?: delete the previous character
# 127 is the ASCII code for delete
127: DELETE_PREV_CHAR
Put it in a file, and call scala like this:
scala -Djline.keybindings=/path/to/keybindings.properties
Or pass it through JAVA_OPTS. You'll have to look up on the Internet what keybindings exist, and try :keybindings from Scala to see what are the defaults (it won't reflect your actual keybindings, though).
in scala 2.9's REPL you have a new :keybindings command. This reveals:
scala> :keybindings
Reading jline properties for default key bindings.
Accuracy not guaranteed: treat this as a guideline only.
1 CTRL-A: move to the beginning of the line
2 CTRL-B: move to the previous character
4 CTRL-D: close out the input stream
5 CTRL-E: move the cursor to the end of the line
6 CTRL-F: move to the next character
7 CTRL-G: abort
8 BACKSPACE, CTRL-H: delete the previous character 8 is the ASCII code for backspace and therefor deleting the previous character
9 TAB, CTRL-I: signal that console completion should be attempted
10 CTRL-J, CTRL-M: newline
11 CTRL-K: erase the current line
12 CTRL-L: clear screen
13 ENTER: newline
14 CTRL-N: scroll to the next element in the history buffer
15 CTRL-O: move to the previous word
16 CTRL-P: scroll to the previous element in the history buffer
18 CTRL-R: redraw the current line
21 CTRL-U: delete all the characters before the cursor position
22 CTRL-V: paste the contents of the clipboard (useful for Windows terminal)
23 CTRL-W: delete the word directly before the cursor
127 DELETE, CTRL-?: delete the next character 127 is the ASCII code for delete
on the macbook laptops, DELETE can be accessed via Fn + BACKSPACE.
I would like to have a pop-up bottom window for temporary buffers like compilation, Completions, etc. It should split-vertically the whole frame even if root window was split horizontally. For example:
Before M-x compile:
+------+------+
| | |
| | |
| | |
+------+------+
After:
+------+------+
| | |
+------+------+
| |
+------+------+
I'm absolutely satisfied with ecb-compilation-window, but I don't want to use ECB and CEDET.
Actually I see two ways make described behavior but both have their drawbacks.
Use split-root.el module.
Drawback: it uses delete-other-windows function and then rebuilds previous windows tree after root window is split as required. It invalidates all references to existed earlier windows in your code(or code of any module).
Set window-min-height variable to its minimal possible value(1) and call split-window-vertically during emacs startup minimizing window height after it's created. Then use this window for temporary buffers setting its height as required.
Drawbacks: Small annoying window with annoying modeline on the bottom of the frame, doesn't work with emacs --daemon.
Are there more elegant ways to do that without drawbacks?
Use popwin !
It behaves as you describe out of the box, and configuration is easy, it only took one line to get my anything buffers to pop-up at the bottom of the screen :
(push '("\*anything*" :regexp t :height 20) popwin:special-display-config)
There some more detailed config examples floating around japanese blogs, just google it.
I work with two monitors, and often use emacs with two frames open; one for each monitor. each frame is split into two side-by-side windows, like so:
a | b <-- frame 1 in monitor 1
-------
c | d <-- frame 2 in monitor 2
When I hit my 'compile' button while in window a, the compilation buffer opens in the buffer next to it. So far so good:
a | compilation
-----------------
c | d
However, if I then move to window c to edit some stuff, then hit compile again, window d visits the compilation buffer as well:
a | compilation
------------------
c | compilation
So now I have half of my screen real-estate taken up by two copies of the same compilation buffer, wondering why I have two monitors :)
I can prevent this by conscientiously only hitting the compile key when my cursor is in the buffer next to the currently open compile buffer, but I hit 'compile' so early and often that I usually don't have the presence of mind to do so. I feel like there must be something I can tweak in .emacs so I shouldn't have to.
Any suggestions? Ideally, when I hit 'compile', the currently open compilation buffer should move from its previous window to the one next to the currently used window. If that's too complicated, I'd easily settle for having emacs not visit the compilation buffer in the neighboring window, if it's already open in another window.
(setq-default display-buffer-reuse-frames t)
From the documentation:
Non-nil means `display-buffer' should reuse frames.
If the buffer in question is already displayed in a frame, raise
that frame.