This question is linked to my previous one: Shift arrow selection in emacs
It was solved but partially only.
For now I have another problem:
when I'm pressing shift-right 2 times - only last selection will be present. So. It is not extended (as it should be according my achivements) but always overwritten...
f.e. I have 1 word "window" only. And my cursor at position 0. I want to copy "wi" only. I've pressed shift-right 2 times. But only "i" was selected.
How I can fix this?
den#playground:~/.emacs.den$ cat -v
^[[1;2C^[[1;2C
M-x version
GNU Emacs 23.2.1 (i486-pc-linux-gnu, GTK+ Version 2.20.0) of 2010-12-11 on raven, modified by Debian
I'm running my emacs on a remote machine via screen
den#playground:~/.emacs.den$ echo $TERM
screen
Without screen
den#playground:~$ echo $TERM
xterm
Behavior the same as under screen.
As I have understood the problem. Emacs after each shift-right click overwrites selection instead of expanding it...
So. Without screen and without my scripts (emacs -q).
Shift-right, shift-left, shift-down - working. shift-up - doing nothing. So. cursor is not moved after shift-up is pressed. Also shift-home, shift-end are working. shift-pgdown, shift-pgup - does not.
With screen and without my scripts (emacs -q).
Nothing.
Why do you press Shift-right 2 times, and not press on 'w' C-SPACERightRight
This selects the wi. Now you press M-w, and you copied it.
Probably I understood wrong the problem ?
Related
In Vim, you can press fx and Fx to move to the next and previous occurrence of x on the same line:
**fx** - jump to next occurrence of character x
**Fx** - jump to previous occurence of character x
source: https://vim.rtorr.com/
I don't wish to use a vim emulator in VS Code, I instead would like to bind Ctrl+f to forward search and Ctrl+b for backwards search.
How can I do that?
I just posted an extension (I'm pretty sure you can't do it without an extension) that does what you want: Jump and Select
It does a little more than you want in case other people would like the selection option. You can bind any keybinding to the commands you want. The following demo uses Alt+f for forward and Alt+b for backward.
Note that the key you want to go to is not displayed. And you don't have to hit Enter to trigger the move - it just goes there immediately. And it works with multiple cursors.
Also, I am not familiar with vim. If you go back to some designated previous character, should the cursor end up before or after that character? Right now it goes to that character (so the cursor is after it) but it is easy for me to make to change that behaviour in the extension. Just let me know.
In VSCode, "find next" is performed by Ctrl+G (Cmd in MacOS) and "find previous" by Ctrl+Shift+G.
You can edit the keyboard shortcuts by going to Code > Preferences > Keyboard Shortcuts and looking for both "Find Next" and "Find Previous", and hovering over the keybinding to edit it to your preference.
In Neatbeans, unindent works as expected when multiple lines are selected. But consider the following, where the pipe character | symbolizes the cursor position in the editor:
(a) Cursor at start of line (no selection)
|hello world!
(b) Cursor inside of line (no selection)
hell|o world!
In Netbeans, when I hit Shift+Tab on version (a) then the indentation is removed. This is what I expect.
However, when I hit Shift+Tab on version (b) then nothing happens. This is different from the code editors that I am used to. I would expect the indentation to be removed, or that the cursor moves to the start of the line, such that the next Shift+Tab will remove the indentation.
Is there a config in Netbeans that makes unindent via Shift+Tab work when the cursor is inside the line?
To shift the line to the left, regardless of the cursor position you can use the "Shift line left" editor action. In the default NetBeans mapping this is assigned to Alt+Shift+KP_LEFT and Alt+Shift-LEFT
Just open the keymap options page and search for the action "shift line"
It's not exactly what you are asking, but you could try to remap that action to "Shift-Tab" and see if it works.
TLDR: There seems to be a bug in the way NetBeans handles indenting/unindenting.
I would expect the indentation to be removed
I don't see any formal documentation on how unindenting is supposed to work in NetBeans, but it appears to move the text to the right of the cursor to the left, as long as there is only whitespace to the left of the cursor. While that is different to how unindenting works in other code editors such as Intellij IDEA and Eclipse, where the entire line is shifted to the left even when the cursor is poitioned within the text, it's not necessarily incorrect.
If you want to unindent in NetBeans there are two simple alternatives: either position the cursor at the start of the line, or select some text - anything at all! - on that line before unindenting.
Some comments in the NetBeans Bug Report Bug 212353 - Shift+Tab (Delete tab) shortcut does not work in editor may be relevant:
Please note that those actions should be inverse - I mean when you
select a block and you hit <TAB> <TAB> <Shift-TAB> <Shift-TAB> you
should always end up with the same text. The same should be true if
you change the order to <Shift-TAB> <Shift-TAB> <TAB> <TAB> you
should end up with the same text.
That said, NetBeans is not adhering to that standard. Using your second example, pressing <TAB><TAB> works fine, but subsequently pressing <SHIFT><TAB> does nothing, so it is not possible to "end up with the same text". That looks like a bug (in Apache NetBeans 11.2 at least). You can raise a bug report here.
It's also worth noting that <Shift> + <Tab> is actually defined as the keymap for "Delete TAB" rather "unindenting".
Is there a config in Netbeans that makes unindent via Shift+Tab work
when the cursor is inside the line?
I don't think so. All you can do, using Tools > Options > Keymap, is to change the shortcut keys from <Shift> + <Tab> to something else, but that won't change the behavior.
How can I get scrollbars with exact positioning?
To illustrate what I mean:
C-h C-f (Read the The GNU Emacs FAQ)
Now try to position the buffer content such that the paragraph starting with This is the version ... is on top. With the default scrollbar you need several redraws to do this. Or you left-click for cursor positioning then C-lC-l
Now go back to where you have been before. This is impossible with regular scrollbars.
What I would like to have is to just click in the scrollbar at the height of This is the version ... to position this line on top for step 2. And to go back where I came from, I rightclick (without having moved the mouse, indeed).
In the past, I have always installed Emacs with the Athena widgets-like option to get such scrollbars, see a description of them. But I wonder if there is now a better or more modern way to do this. After all, I'd rather like to use standard distributions.
Maybe, it is not even necessary to change the scrollbars at all but to use rather the left-fringe for it. After all, mouse clicking in the fringe is recognized as <left-fringe>
M-x emacs-version
GNU Emacs 23.3.1 (x86_64-pc-linux-gnu, GTK+ Version 2.24.10) of 2012-09-21 on batsu, modified by Debian
Maybe a change of usage habits could help? Some Emacs user recommend disabling the scrollbars completely and navigate Emacs exclusively with the keyboard. (This habit is also beneficial for using Emacs inside a shell.)
Emacs provides a large number of navigation shortcuts. For instance, for jumping up and down large amounts of buffer space, you have:
C-v scroll-up
M-v scroll-down
M-} forward-paragraph
M-{ backward-paragaph
C-x ] forward-page
C-x [ backward-page
However, I would argue that by far the most useful navigation commands are:
C-s isearch-forward
C-r isearch-backward
In Emacs, search is so cheap, it is such an integral part of the work flow that it's often times much faster to get to a different point in the buffer by using a reference word as an anchor for a quick search, rather than leaving the home row to reach for the mouse. Hitting C-s or C-r repeatedly will move the point to consecutive matches. (You can even switch to regular expression search by hitting M-r while searching to make search even more powerful.)
You already mentioned C-l C-l to view the current line at the top of the buffer.
Now, if you want to go back to the previous location, you could use
C-u C-x
which jumps back to the mark. All the above commands for navigation push their start position on a "mark-ring" which means you can not only jump back one position, repeatedly hitting C-u C-x will take you back to many previous positions.
For this task I press C-l once, twice, three times.They will switch between middle-top-bottom.
I have launched emacs (emacs -Q) in the console(Ctrl+Alt+F1). The "left Alt key" is
working whereas the "right Alt key" is not working. How to fix the problem. I am running emacs on archlinux
This behavior is controlled by the keyboard layout you are using. In the layout that you are using, the left alt is Meta, whereas the right alt is Alt-graphic which allows you to enter accentuated character. Change your keyboard layout to one not using the right alt as Alt-graphic
The solution is described here:
http://www.joshstaiger.org/archives/2005/04/fixing_the_righ.html
It needs some modifications though (see item 3.2 below).
Otherwise one would not be able to type anything in current console after the first press of [Right Alt].
If this happened to you, switch to other console (e.g. [Ctrl+Alt+F2]) and restore old keymap.
Here is the brief description of the modified solution:
Save current keymap to file:
dumpkeys >> mykmap
and make a backup of it:
cp mykmap oldkmap
Capture [Right Alt] keycode using showkey command. Let's assume it is 100.
Edit mykmap:
Find the corresponding line:
keycode 100 = AltGr
and change it to:
keycode 100 = Alt
If the next line (or one of the next lines) is:
alt keycode 100 = Compose
remove it.
Load new keymap:
loadkeys mykmap
Make the changes permanent (e.g. add the last command to ~/.bashrc).
Here's my problem - hopefully I can explain this well enough:
I use Putty on Windows, and then start a gnu screen session. I may run several shell commands in putty, and then in the same screen, run emacs -nw. The problem is that when I exit emacs, the scrollback buffer (in putty) is messed up. What was on the screen when I started emacs is gone, and if I scroll upward I see various artifacts of screen (e.g. the screen "bar" at the bottom, etc.).
If I don't use screen and just open emacs -nw directly from putty, all my history is still there in the buffer when I exit emacs.
Likewise, if I do use screen, and use vi within a screen instead of emacs, when I exit vi, everything is there.
Is this just some weird interaction with putty and emacs? Is there a way to fix it?
Have you tried setting scrollback buffer size to something else than default? scrollback
In .screenrc put this line:
defscrollback 10000
Here's my config .screenrc. Tried to reproduce this problem but no luck... you can try if it fixes for you:
termcapinfo xterm* ti#:te#
startup_message off
vbell off
autodetach on
altscreen on
shelltitle "$ |bash"
defscrollback 10000
defutf8 on
nonblock on
hardstatus alwayslastline
hardstatus string '%{= kw}[ %{= kb}%H%{= kw} ][%= %{= kw}%?%-Lw%?%{= kW}%n*%f %t%?%?%{= kw}%?%+Lw%?%?%= ][ %{r}%l%{w} ]%{w}[%{r} %d/%m/%y %C %A %{w}]%{w}'
bind 'q' quit
Just at the end I would as well suggest you getting familiar with tmux -> http://tmux.sourceforge.net/
BTW. hopefully you're using newest version of PuTTy right? :) - > http://puttytray.goeswhere.com/
This sounds like Emacs and Screen are stepping on each others toes over the alternate screen feature of your terminal.
I cannot reproduce this issue, but maybe putting the following in your ~/.screenrc would help:
altscreen on
Have you considered using tmux as an alternative to GNU screen?