Trim Trailing Whitespace from ALL files in workspace - visual-studio-code

I know about the Trim Trailing Whitespace command in the pallette, and I know I can run this on save.
Is there a way to trim trailing whitespace on ALL files in a workspace (either with some command combo, or a way to run "save" on every file)
I have seen other answers on how to trim trailing whitespaces using Unix tools, but I would rather use the built in tool from VSCode specifically. (I would accept an answer that shows how to do this in another GUI text editor like Sublime Text also).
I would prefer not to have answers that use Terminal or other Regex matching--I would prefer to use the exact algorithm that is used by GUI tools already, since I trust that they will do the thing I expect. I will be running this on potentially thousands of files, so mistakes could easily go through even after audit.
I am basically trying not to open every file and ⌘+S it manually.
I am on macOS if that changes anything (but I doubt it matters)

This can be done using the search-and-replace function (keyboard shortcuts given below are for Linux, likely similar to what exists on a Mac):
Ctrl-Shift-H (open the search-and-replace side panel)
Type +$ in the Search field (that is a space, a plus and a dollar, meaning one or more spaces anchored at the end of the line)
Click the .* regular expression button next to the Search field
Leave the Replace field empty
Press Ctrl-Alt-Enter (or press the Replace All button next to the Replace field)
Click Replace (or Alt-R) in the confirmation pop up which also tells you the number of occurrences and files that will be touched
Be careful, as a wrong search or replace argument can mess up many files all at once!

Related

Copy/move rest of the current line to the end of next line

I have Googled a lot but cannot find one feature in VScode that I would appreciate greatly:
Copy (or move) rest of the current line (i.e. not the entire line) to the end of next line
Example:
What I have - note the cursor
What I need - again note the cursor
So ideally, with a single keyboard shortcut, I would copy (or move) the remainder of the current line (= "ABC1" in the example) to the end of the next line. Any ideas how to do that? Is it available within VScode, or is there a relevant extension? Thanks!
Since you're asking if there's an extension for it, the vim extensions should at least be mentioned. I have no intention or desire to start an(other) editor war, though.
What you're asking would be trivial in vim (y$, yank to end of line) and there are at least two very popular vim extensions for vscode that will bring the vim keybindings as well as the power of configurable commands and bindings in vim to vscode.
Yes, it would require some effort to learn the "vim way" of doing things, but the upside is that you'll probably never have to re-learn the bindings if you move between editors/IDEs since they are available in pretty much every editor and they make editing very fast and precise.
Drag and drop by mouse
Why are you not using mouse drag and drop text?
Select the text and drag it by mouse where you need
Otherwise, if you have multiple times then you can solve it in two steps.
Step1:
Replace all Name by Name(ctrl+enter)SecretCode
Step2:
Replace all "(ctrl+enter)SecretCode by "
Done

how could I using query-replace like isearch-forward while typing something

while isearch-forward run as a command, the context I had typed will hightlight in the current buffer, but while run query-replace don't hightlight that, how can i make it hightlight?
Use isearch-query-replace. It highlights the string to be replaced.
It sounds like you are saying that query-replace does not highlight all of the matching occurrences. Is that right? It should highlight them. If it does not, then try starting Emacs without your init file: emacs -Q. If that shows no lack of highlighting then recursively bisect your init file to find the culprit.
#Rocky mentioned isearch-query-replace. That doesn't change highlighting (which should already be turned on), but what it does do is let you start query-replacing while you are isearching, using the last search string as the pattern for the text to be matched by query-replace.
An alternative to query-replace, useful especially if you have relatively few replacements you want to make and there are lots of matches, is to use on-demand replacement while isearching. For that you need library Isearch+.
To replace any given search hit on demand, just hit C-M-RET. With a prefix arg, C-M-RET prompts you for the replacement text (the default is to replace with no text, which means to delete the hit). You can thus change the replacement text anytime, within the same Isearch invocation.
After replacing the search hit, C-M-RET moves to the next one. So you can just use it repeatedly if you want to replace several successive search hits. Or use C-s to skip replacing the current hit and move to the next one.
On-demand Isearch replacement works also for regexp searching, and just as for query-replacing, the replacement text can be either inserted literally, as is, or interpreted as in query-replace-regexp. In the latter case, you can use \&, \=\N, \#, \, and \?. You can use C-M-` anytime during Isearch to toggle whether replacement text is used literally or interpreted per the special regexp-replacement constructs.
The following packages provide live highlighting and replacement previewing for query replacing, as well as additional features:
https://github.com/syohex/emacs-anzu
https://github.com/benma/visual-regexp.el
https://github.com/benma/visual-regexp-steroids.el
I currently use visual-regexp-steroids.el.
All three packages can be installed from MELPA.

Is there a way to disable all indentation and other automatic insertion in eclipse?

Is there any way to globally configure all text editors in Eclipse to insert only the user's actual keystrokes into the file, and zero additional characters?
In particular, is there a way to ensure that typing ENTER always inserts exactly ENTER, no more, no less, and never inserts ENTER SPACE SPACE...SPACE for some context-dependent number of spaces?
The behavior will have several desirable (to me) consequences:
typing ENTER BACKSPACE would restore the file to its exact state prior to ENTER. Currently, roundtripping the state (e.g. to revert an accidental keypress) requires ENTER BACKSPACE BACKSPACE BACKSPACE ... BACKSPACE.
typing ENTER ENTER ENTER ENTER at any location in the file would produce three completely empty lines and leave the cursor at the extreme left of the fourth line, versus four lines prefixed by SPACE SPACE...SPACE which demand further cleanup.
Multi-line copy-paste will be 100% predictable and consistent irrespective of context.
This is how every other basic editor behaves (or at least can behave), so it seems plausible that this would be achievable in Eclipse, somehow. But although I have found ways to disable every other 'smart' intervention Eclipse throws across my path, I have never found a way to disable the ENTER SPACE SPACE...SPACE behavior.
The solution needn't be a built-in configuration parameter (and by this point I doubt such exists). Plugins or other one-time hacks of moderate complexity are acceptable, provided the result is an always-on type-one-key-get-one-character behavior.
Note, importantly, that invoking an auto-format operation after the fact to clean up unwanted whitespace is a non-solution. I know that works; it's not what I'm looking for.

Ansi-coloured file editing

Context
Have some transcript files from terminal interaction, obtained using traditional Unix command "script".
Those transcripts contain lots of control character (like backspace when editing shell commands), and lots of color code sequences as result of running various commands. Occasionally, even colorful full-terminal (ncurses-based) applications like "emacs -nw" or "aptitude" were run.
At program runtime, TERM environment variable was set as "xterm".
Need 1: read (more or less solved)
I need to read those files again and sometimes copy-paste some small parts.
The trouble is : while one color change here and there is not so much of a problem, their actual density makes the output barely readable. Worse, edited command lines (with cursor jumps and edited words) are completely unreadable.
"Okay" solution
Browse through files using e.g. "less -r". Paging forward in the same terminal setup reproduces the various color and character style.
But many other features come out more or less broken, e.g. search backwards produces jumbled terminal output, often have to pres "Ctrl-L" to clean thing up.
Need 2: editing
My preferred editor is emacs. Some people have had a similar situation when running the shell inside emacs, e.g. Something wrong with Emacs shell.
Here is not the same situation. Examples of differences: here we don't have to run an actual shell, but we need to move cursor freely like in usual editing.
Editing here means easily open such a transcript file in editor and then:
at all times through editing, see character changes (color, attributes) as conveyed by the terminal codes
(optional) some character that are neighbour on the terminal grid but are separated in file by some control characters would have a visual hint about this
ability to insert some text,
delete sections,
use all editor features like search/replace etc.
copy & paste to & from file (including to external programs, which would receive just plain text)
in my wildest dreams, some kind of "flatten" action, like select a sequence with a heavily edited command line and replace it with a simple series of characters as if it was typed in one run. "Visual hints" mentioned above would disappear.
Type Alt-: to evaluate something in the minibuffer. Evaluate (ansi-color-apply-on-region (point-min) (point-max)) and it will convert ansi color codes to be font colors.

Tab in Emacs-helm (anything) does not autocomplete with current best match

While trying to autocomplete a file (e.g. to open a file with C-x C-f) Emacs-helm shows a list of possible candidates.
If I then press Tab (which I would hope it would help me choose the first/closest match), I get the following in the minibuffer:
It looks like the minibuffer gets confused with escape characters, and it does not choose the file that I actually want to open (the top choice).
Helm requires this conceptual jump from the default Emacs completion, which is not so obvious:
You don't need to press a key to complete. The completion buffer refreshes
with new results after every input.
This is called "incremental" completion.
The normal tab functionality is not needed in "incremental"
completion. So tab was rebound to helm-select-action, which allows you to
choose an alternative action with the selection. But there is only one action
in read-file-name.
The error you're seeing could be clearer though, I've filed this issue on github.
Additionally, note Helm treats each space separated term as a filtering
regular expression. So, pressing space foo will filter
the current list down to those that contain foo in the name.