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 .
Related
What I am trying to do:
For example, I have a line in my code that looks like this
something.something()
I would like to add print() around it:
print(something.something())
How I am doing it:
I type in vim: ^c$print()<Esc>P meaning:
put cursor to the beginning of the line,
change entire line,
type in print(),
paste entire line back before print's ).
The Problem:
Unfortunately the c$ part cut the EOL character as well. so the subsequent P operation will just paste the line on top of print(). So the end result will look like this:
something.something()
print()
My Thoughts:
Right now the work around is using v mode to highlight entire line except for the EOL character first, then do the above.
I am looking for something akin to ct$ ci$, but none of them works. my line doesn't always end with (), it could be __dict__ or just plain text, so cf) is handy but I am looking for something more universal. Thanks.
Of course it's doable out of the box.
Assuming your description of what you are doing is exact, the reason what you are doing doesn't work is most likely caused by something in your config because c$ (or its better alternative C) should never yank the EOL.
Here is a demonstration using your method as described in your question:
^c$print()<Esc>P
and the method I would use:
^Cprint(<C-r>")<Esc>
I don't think you want to be going into edit mode at all. Just do:
:s/something.something()/print(&)/g
Note that you can do this pretty easily interactively (eg, you don't have to type 'something.something()') by yanking something.something into the unnamed register (eg, put your cursor on the text and hit 'yiw', but what gets yanked exactly will depend on the current setting of iskeyword), and typing :s/<ctrl>r"/...
Or, as Christian Gibbons points out in the comments, if you want to replace the entire line you can simply do:
:s/.*/print(&)
Try ^cg_print()<Esc>P.
The g_ movement means "to the last non-blank character of the line", and since in Windows it appears the carriage return is part of the line if you yank/delete, using _g instead of $ on Windows may be advisable.
If you find yourself almost never needing $, you can swap the two commands in your .vimrc:
onoremap g_ $
onoremap $ g_
Notepad++ obviously recognizes all comments as such. Is there a way to simply delete all?
Edit: Stat-R's bookmark method has helped greatly, not only for removing comments but for conditionally removing lines in general.
For a general file, first of all you need to know the comment operator of the language you are writing the file in. For example, in java script the comment operator is //.
For the following code...
In NP++, you need to
Mark the lines that contains '//'. Make sure the bookmark option is enabled.
Then, choose from NP++ menu Search>Bookmark>Remove Bookmarked lines
EDIT:
Another solution after #Chris Mirno 's suggestion is as follows:
Use regular expression. See the image below. It is self explanatory
To understand it better, refer to these
In the Find & Replace Dialog, put the following regex and adjust the search options as depicted.
/\*.*?\*/
Replace with: (empty)
Select Mode: Regular Expression AND .(dot) matches newline
This should remove all your C style comments spanned across lines.
Star-R and Chris Mirno Answer are also Correct and Good.
But For Line Comment:
//.*?(?=\r?$)
Explanation:
// will be the Starting Position
.*? Will be any character
(?=\r?$) will search to the end of the line (as it is required in line comment)
Note:
But Still check each of the line because for example if your code contains soap format like
//www.w3.org/2001/XMLSchema-instance\x2......");
it will capture this line because the starting is // and it goes to end of the line so watch out for this :)
Warning to all using Stat-R's solution:
This method will remove lines of code if formatted like this:
echo "hello"; //This comment will be detected
Following his method, the entire line will be removed.
Therefore make sure to go through and make these comments, their own line before doing this method.
I have had some luck running a macro for the above. Basically:
search for // (F3)
select to end of line (shift+end)
delete (delete)
Put // into the search dialog by just searching for it once. Then record the three steps in a macro, then play it back until EOF.
The first time I did it I had a problem, but then it worked, not sure what I did differently.
Anton Largiader's answer was the most reliable one, including complex inline comments.
However, it will leave many empty lines, including ones with empty characters (space, tabs...) so I would just add another step to make it almost perfect:
After running the macro, just do:
Edit > Line Operations > Remove Empty Lines
OR
Edit > Line Operations > Remove Empty Lines (Containing Blank Characters)
1st option is good if you wish to remove only really empty lines
2nd options will remove every empty line even containing space etc. so there will be no more actual spacing left between code blocks. 1st option might be the safest with some manual cleanup afterwards.
As someone suggested in another post, the simplest and most reliable is maybe to export the all text in .RTF format using Menu Plugin-->NppExport-->Export to RTF and then:
-Open the newly created file in Word
-Select any part of any comment
-On the top-right side of Word clic Select--> Select all texts with similar formatting
-Remove the selected comments all at once (del or cut if doesn't work)
To remove Powershell comments if someone find it handy:
Removing Comment in a Powershell using Notepad ++
To find just lines beginning with # (and not with # elsewhere in the line).
Notepad++ SEARCH Menu > Find
‘Mark‘ Tab – fill in as below.
Select ‘Mark All’ (clear all marks if used previously).
Regex ^[#}
enter image description here
SEARCH Menu > bookmark > Remove (or do anything on the list with
them)
Clear all marks to reset
You can select no comments just code by doing the following:
Regex ^[^#}
enter image description here
Enter ctrl+shift+K to remove comment
I'm having problems about a regexp.
I'm trying to implement a regex to select just the tab indent blocks, but i cant find a way of make it work:
Example:
INDENT(1)
INDENT(2)
CONTENT(a)
CONTENT(b)
INDENT(3)
CONTENT(c)
So I need blocks like:
INDENT(2)
CONTENT(a)
CONTENT(b)
AND
INDENT(3)
CONTENT(c)
How I can do this?
really tks, its almost that, here is my original need:
table
tr
td
"joao"
"joao"
td
"marcos"
I need separated "td" blocks, could i adapt your example to that?
It depends on exactly what you are trying to do, but maybe something like this:
^(\t+)(\S.*)\n(?:\1\t.*\n)*
Working example: http://www.rubular.com/r/qj3WSWK9JR
The pattern searches for:
^(\t+)(\S.*)\n - a line that begins with a tab (I've also captured the first line in a group, just to see the effect), followed by
(?:\1\t.*\n)* - lines with more tabs.
Similarly, you can use ^( +)(\S.*)\n(?:\1 .*\n)* for spaces (example). Mixing spaces and tabs may be a little problematic though.
For the updated question, consider using ^(\t{2,})(\S.*)\n(?:\1\t.*\n)*, for at least 2 tabs at the beginning of the line.
You could use the following regex to get the groups...
[^\s]*.*\r\n(?:\s+.*\r*\n*)*
this requires that your lines not begin with white space for the beginning of the blocks.
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.
I know that you can use this to remove blank lines
sed /^$/d
and this to remove comments starting with #
sed /^#/d
but how to you do delete all the comments starting with // ?
You just need to "escape" the slashes with the backslash.
/\/\//
the ^ operator binds it to the front of the line, so your example will only affect comments starting in the first column. You could try adding spaces and tabs in there, too, and then use the alternation operator | to choose between two comment identifiers.
/^[ \t]*(\/\/|$)/
Edit:
If you simply want to remove comments from the file, then you can do something like:
/(\/\/|$).*/
I don't know what the 'd' operator at the end does, but the above expression should match for you modulo having to escape the parentheses or the alternation operator (the '|' character)
Edit 2:
I just realized that using a Mac you may be "shelling" that command and using the system sed. In that case, you could try putting quotation marks around the search pattern so that the shell doesn't do anything crazy to all of your magic characters. :) In this case, 'd' means "delete the pattern space," so just stick a 'd' after the last example I gave and you should be set.
Edit 3:
Oh I just realized, you'll want to beware that if you don't catch things inside of quotes (i.e. you don't want to delete from # to end of line if it's in a string!). The regexp becomes quite a bit more complicated in that case, unfortunately, unless you just forgo checking lines with strings for comments. ...but then you'd need to use the substitution operation to sed rather than search-and-delete-match. ...and you'd need to put in more escapes, and it becomes madness. I suggest searching for an online sed helper (there are good regex testers out there, maybe there's one for sed?).
Sorry to sort of abandon the project at this point. This "problem" is one that sed can do but it becomes substantially more complex at every stage, as opposed to just whipping up a bit of Python to do it.