I have multiple cursors on line with some content that is of variable length and some that's the same content. Due to the variable length content, the lines don't align with each other.
I start with a cursor on each line. I know that only by moving one word at a time to the right, I might not end up at the same spot on each line due to variable content.
How can I do an incremental find for each cursor on the same line and end up with multiple cursors that match my find expression?
Here's a possible solution:
Start with your multiple cursors (done manually, Alt+Enter after a search, etc.)
Select the whole line for each cursor (using Home then Shift+End; etc.)
Open up the search and enable the "In Selection" option (to the right of the "Wrap" option)
Perform your search on those lines, then Alt+Enter to select that match
This would work unless you have multiple matches on the same line. In this case you'll have multiple cursors on the same line
I have been using nano to write a bash script and I am at several times indenting various lines at once with Alt + }. The problem is that the following occurs:
Several lines without text in them get white-spaces by the amount that I indent the text and they are coloured green. They don't affect the program but they make it look bad. I have been deleting them one by one but it gets frustrating over time. Is there a way to get rid of all the white-spaces at once? maybe some way to select the text (short cut for selecting text in nano is Alt + a) and have a short cut do it?
Use global search and replace with the expression ^\s+$.
Switch to search and replace mode with C-\.
Switch to regex mode with Alt-R.
Type the expression ^\s+$.
Hit Enter to replace with an empty string.
On the match, hit A for All.
Following a nice advice, I was able to create a macro to "go to the first non-whitespace character" in TextMate 1.5.
Now I'd like to improve it further, in order to "select back from current point up until the first non-whitespace character", i.e. in this line if the cursor was just after the "§" here, it would select: Now I'd like to improve it further, in order to "select back from current point up until the first non-whitespace character", i.e. in this line if the cursor was just after the "§
The trick used in that advice doesn't help here, since once you "search" for the first non-whitespace character, you lose the selection. Any clue?
If you are using TextMate 2 then you can enable indent-aware movement, selection, and deletion.
For more info see https://github.com/textmate/textmate/wiki/Hidden-Settings#keybindings
I'm studying the ed text editor.
To exit from input mode, a user should enter a line a single period (.).
Let's say I want to enter the period as text.
I thought of a workaround: first, I insert something like ... Then, I replace .. with ..
But my approach is little unwieldy. Is there a better way to do this?
Reading through the C source for GNU ed(1), there is no escape character. On the occasions that I've wanted to do this, I tend to add a blank line and then use a quick substitution:
a↵
↵
.↵
s/^/.↵
or you can add a character then delete it (which, if you're playing ed(1) golf), is one character more than above)
a↵
x↵
.↵
s/./.↵
I didn't found magic escape sequence.
It seems it doesn't exist.
But this link offers 2 solutions. First I described in my question. Second one is closer to a solution with escape.
r ! echo .
I have a specific method for my bash prompt, let's say it looks like this:
CHAR="༇ "
my_function="
prompt=\" \[\$CHAR\]\"
echo -e \$prompt"
PS1="\$(${my_function}) \$ "
To explain the above, I'm builidng my bash prompt by executing a function stored in a string, which was a decision made as the result of this question. Let's pretend like it works fine, because it does, except when unicode characters get involved
I am trying to find the proper way to escape a unicode character, because right now it messes with the bash line length. An easy way to test if it's broken is to type a long command, execute it, press CTRL-R and type to find it, and then pressing CTRL-A CTRL-E to jump to the beginning / end of the line. If the text gets garbled then it's not working.
I have tried several things to properly escape the unicode character in the function string, but nothing seems to be working.
Special characters like this work:
COLOR_BLUE=$(tput sgr0 && tput setaf 6)
my_function="
prompt="\\[\$COLOR_BLUE\\] \"
echo -e \$prompt"
Which is the main reason I made the prompt a function string. That escape sequence does NOT mess with the line length, it's just the unicode character.
The \[...\] sequence says to ignore this part of the string completely, which is useful when your prompt contains a zero-length sequence, such as a control sequence which changes the text color or the title bar, say. But in this case, you are printing a character, so the length of it is not zero. Perhaps you could work around this by, say, using a no-op escape sequence to fool Bash into calculating the correct line length, but it sounds like that way lies madness.
The correct solution would be for the line length calculations in Bash to correctly grok UTF-8 (or whichever Unicode encoding it is that you are using). Uhm, have you tried without the \[...\] sequence?
Edit: The following implements the solution I propose in the comments below. The cursor position is saved, then two spaces are printed, outside of \[...\], then the cursor position is restored, and the Unicode character is printed on top of the two spaces. This assumes a fixed font width, with double width for the Unicode character.
PS1='\['"`tput sc`"'\] \['"`tput rc`"'༇ \] \$ '
At least in the OSX Terminal, Bash 3.2.17(1)-release, this passes cursory [sic] testing.
In the interest of transparency and legibility, I have ignored the requirement to have the prompt's functionality inside a function, and the color coding; this just changes the prompt to the character, space, dollar prompt, space. Adapt to suit your somewhat more complex needs.
#tripleee wins it, posting the final solution here because it's a pain to post code in comments:
CHAR="༇"
my_function="
prompt=\" \\[`tput sc`\\] \\[`tput rc`\\]\\[\$CHAR\\] \"
echo -e \$prompt"
PS1="\$(${my_function}) \$ "
The trick as pointed out in #tripleee's link is the use of the commands tput sc and tput rc which save and then restore the cursor position. The code is effectively saving the cursor position, printing two spaces for width, restoring the cursor position to before the spaces, then printing the special character so that the width of the line is from the two spaces, not the character.
(Not the answer to your problem, but some pointers and general experience related to your issue.)
I see the behaviour you describe about cmd-line editing (Ctrl-R, ... Cntrl-A Ctrl-E ...) all the time, even without unicode chars.
At one work-site, I spent the time to figure out the diff between the terminals interpretation of the TERM setting VS the TERM definition used by the OS (well, stty I suppose).
NOW, when I have this problem, I escape out of my current attempt to edit the line, bring the line up again, and then immediately go to the 'vi' mode, which opens the vi editor. (press just the 'v' char, right?). All the ease of use of a full-fledged session of vi; why go with less ;-)?
Looking again at your problem description, when you say
my_function="
prompt=\" \[\$CHAR\]\"
echo -e \$prompt"
That is just a string definition, right? and I'm assuming your simplifying the problem definition by assuming this is the output of your my_function. It seems very likely in the steps of creating the function definition, calling the function AND using the values returned are a lot of opportunities for shell-quoting to not work the way you want it to.
If you edit your question to include the my_function definition, and its complete use (reducing your function to just what is causing the problem), it may be easier for others to help with this too. Finally, do you use set -vx regularly? It can help show how/wnen/what of variable expansions, you may find something there.
Failing all of those, look at Orielly termcap & terminfo. You may need to look at the man page for your local systems stty and related cmds AND you may do well to look for user groups specific to you Linux system (I'm assuming you use a Linux variant).
I hope this helps.