This is a weird one as everything I have read seems to indicated the opposite, that Prettier will always add a newline and there's nothing the user can do about this.
However, somehow my install of Prettier does the opposite. I save a file with a new line ending and exit. Running yarn prettier 'src/**' --write shows that this new line then gets removed in my file.
I'm not running any sort of automatic code formatting tools, so this isn't my editor or anything. I just use a plain Vim install.
This is really frustrating as I do need those new lines but have to avoid using Prettier as it removes them for some reason.
I guess it doesn't remove the newlines, even though I can't find a single tool that actually displays it properly.
I am seeing the $ as mentioned in this comment which seems to mean it's working.
Related
When working in vscode on Linux how do you insert a newline after running a c++ file in the integrated terminal? In the photo the first run is run as normal and the second run I inserted a newline at the end of the code.
I'd like it so after testing something in the terminal the terminal starts at the next line instead of on top of my code.
I am rewriting the answer by #Tyler:
If you mean making your prompt appear on a new line regardless of
whether your program output ended with a newline character, then
that's a shell-specific thing. Some shells such as fish and (IIRC) zsh
do this by default. If you want to do it for bash, you can probably
use https://www.unix.stackexchange.com/a/60469
Beside this. Some IDE also provide configurabl built-in output panel.
I'm using Git to version prose and have been trying git diff --word-diff to see changes within lines. I want to use the results generated in a script.
But the default way that --word-diff identifies a word seems flawed. So I've been experimenting with --word-diff-regex= options.
Problem
Here are the two main flaws I'm trying to deal with:
Added whitespace seems to be ignored. But whitespace can be quite important if trying to use the results programmatically.
For example, take this header from a Markdown (.md) file:
# Test file
Now, let's add some text to the end of it:
# Test file in Markdown
If I run git diff --word-diff on this:
# Test file {+in Markdown+}
But the space before the word "in" has not been included as part of the diff.
Empty lines are completely ignored.
Here's a standard git diff for the content of a file where I've removed a line and also added a couple of new lines -- one empty, the other with the text "Here's a new line."
This is a test file to see how word diff responds in certain situations.
-
I'll try removing lines and adding them to see what happens.
Here's another line so we can see what happens with line removals and additions. I want to see how `git diff --word-diff` handles it all!
+
+Here's a new line.
But here's git diff --word-diff for the same content:
This is a test file to see how word diff responds in certain situations.
I'll try removing lines and adding them to see what happens.
Here's another line so we can see what happens with line removals and additions. I want to see how `git diff --word-diff` handles it all!
{+Here's a new line.+}
The removed and added empty lines are completely ignored.
Desired results
Putting the two examples above together. Here's what I'd like to see:
# Test file{+ in Markdown+}
This is a test file to see how word diff responds in certain situations.
{--}
I'll try removing lines and adding them to see what happens.
Here's another line so we can see what happens with line removals and additions. I want to see how `git diff --word-diff` handles it all!
{++}
{+Here's a new line.+}
Things I've tried:
git diff --word-diff-regex='.' seems too granular for when new words share characters with existing words
git diff --word-diff-regex='[^ ]+|[ ]' seems to solve the first problem but, to be honest, I'm not actually sure why.
git diff --word-diff-regex='[^ ]+|[ ]|^$' -- I was hoping the ^$ on the end would help capture empty lines -- but it doesn't and, worse, it then seems to ignore the change that follows.
git diff --word-diff-regex='[^ ]+|[ ]|.{0}' creates same problem as the one before.
I'd be grateful if anyone could shed any light on how to do this, or at least share some knowledge on what's going on under the hood with --word-diff-regex.
The main thing that you're running into that's stopping you from having what you want, from https://git-scm.com/docs/diff-options, is:
A match that contains a newline is silently truncated(!) at the newline.
This is going to mean that word diffs are always going to ignore line diffs. I don't think you're going to achieve the results you want short of a custom diff generator.
Just as title says, I want matchpairs option to work with with the signs '¿' and '?'. It works with other signs, for example after setting:
I'm able to jump between spanish exclamation marks ('¡' and '!') with just pressing '%'. The problem comes when doing the same with questions marks by:'
I will obtain a error message explaining some kind of function failing dealing with regex:
At first sight, the function would seem to come from one of my plugins so I tried to find which by replacing my .vimrc with a blank file but vim continued showing the same error so my personal plugins are not the problem.
As far as I know, when using nocompatible mode in vim several integrated plugins are charged. I think some of those plugins is the guilty, because when I call vim without any config fail by "vim -u NONE" the problem disappears. However, anyone here would be with me in that using no config file would be a little unpleasant.
Then my questions are:
What is the easiest way to solve this problem?
What is causing it? Is really something related with regular expressions (I have tried placing a '\' before the '?' without results)'?
You could use matchit plugin (which most likely is already installed in your computer as the function causing the error, Match_wrapper(), is defined on matchit.vim. To check if matchit.vim is loaded, use the command :scriptnames in Vim). Then add this auto command to .vimrc:
autocmd! BufWinEnter,BufEnter * if exists("b:match_words") |
\ let b:match_words=b:match_words.',¿:?' |
\ endif
To keep .vimrc clean you may want to follow the advice on help :matchit:
... you can add autocommands to the script or to your vimrc file, but the recommended method is to add a line such as
let b:match_words = '\<foo\>:\<bar\>'
to the filetype-plugin for your language.
I have looked at the following question:
How to comment out a block of Python code in Vim
But that does not seem to work for me. How do I comment code easily without resorting to plugins/scripts?
Use ctrl-V to do a block selection and then hit I followed by //[ESC].
Alternatively, use shift-V to do a line-based select and then type :s:^://[Enter]. The latter part could easily go into a mapping. eg:
:vmap // :s:^://<CR>
Then you just shift-V, select the range, and type // (or whatever you bind it to).
You can add this to your .vimrc file
map <C-c> :s/^/\/\//<Enter>
Then when you need to comment a section just select all lines (Shift-V + movement) and then press CtrlC.
To un-comment you can define in a similar way
map <C-u> :s/^\/\///<Enter>
that removes a // at begin of line from the selected range when pressing CtrlU.
You can use the NERD commenter plugin for vim, which has support for a whole bunch of languages (I'm sure C++ is one of them). With this installed, to comment/uncomment any line, use <Leader>ci. To do the same for a block of text, select text by entering the visual mode and use the same command as above.
There are other features in this such as comment n lines by supplying a count before the command, yank before comment with <Leader>cy, comment to end of line with <Leader>c$, and many others, which you can read about in the link. I've found this plugin to be extremely useful and is one of my 'must have' plugins.
There's always #ifdef CHECK_THIS_LATER ... #endif which has the advantage of not causing problems with nested C-style comments (if you use them) and is easy to find and either uncomment or remove completely later.
Is there a way to run a regexp-string replace on the current line in the bash?
I find myself rather often in the situation, where I have typed a long commandline and then realize, that I would like to change a word somewhere in the line.
My current approach is to finish the line, press Ctrl+A (to get to the start of the line), insert a # (to comment out the line), press enter and then use the ^oldword^newword syntax (^oldword^newword executes the previous command after substituting oldword by newword).
But there has to be a better (faster) way to achieve this. (The mouse is not possible, since I am in an ssh-sessions most of the time).
Probably there is some emacs-like key-command for this, that I don't know about.
Edit: I have tried using vi-mode. Something strange happened. Although I am a loving vim-user, I had serious trouble using my beloved bash. All those finger-movements, that have been burned into my subconscious suddenly stopped working. I quickly returned to emacs-mode and considered, giving emacs a try as my favorite editor (although I guess, the same thing might happen again).
in ksh, in vi mode, if you hit 'v' while in command mode it will spawn a full vi session on the contents of your current command line. You can then edit using the full range of vi commands (global search and replace in your case). When :wq from vi, the edited command is executed. I'm sure something similar exists for bash. Since bash tends to extend its predecessors, there's probably something similar.
G'day,
What about using vi mode instead? Just enter set -o vi
Then you can go to the word you want to change and just do a cw or cW depending on what's in the word?
Oops, forgot to add you enter a ESC k to o to the previous line in the command history.
What do you normally use for an editor?
cheers,
Rob
Edit: What I forgot to say in my original reply was that you need to think of the vi command line in bash using the commands you enter when you are in "ex" mode in vi, i.e. after you've entered the colon.
Worst thing is that you need to move around through your command history using the ancient vi commands of h (to the left) and l (to the right). You can use w (or W) to bounce across words though.
Once you get used to it though, you have all sorts of commands available, e.g. entering ESC / my_command will look back through you r history, most recent first, to find the first occurrance of the command line containing the text my_command. Once it has found that, you can then use n to find the next occurrance, etc. And N to reverse the direction of the search.
I'd go have a read of the man page for bash to see what's available under vi mode. Once you get over the fact that up-arrow and down-arrow are replaced by ESC k, and then j, you'll see that vi mode offers more than emacs mode for command line editing in bash.
IMHO natchurly! (-:
Emacs? Eighty megs and constantly swapping!
cheers,
Rob
Unfortunately, no, there's not really a better way. If you're just tired of making the keystrokes, you can use macros to trim them down. Add the following to your ~/.inputrc:
"\C-x6": "\C-a#\C-m^"
"\C-x7": "\C-m\C-P\C-a\C-d\C-m"
Now, in a new bash instance (or after reloading .inputrc in your current shell by pressing C-x C-r), you can do the following:
Type a bogus command (e.g., ls abcxyz).
Press Ctrl-x, then 6. The macro inserts a # at the beginning of the line, executes the commented line, and types your first ^.
Type your correction (e.g., xyz^def).
Press Ctrl-x, then 7. The macro completes your substitution, then goes up to the previous (commented) line, removes the comment character, and executes it again.
It's not exactly elegant, but I think it's the best you're going to get with readline.