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.
Related
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!
I want auto-complete menu to show automatically while typing but never expand except if explicitly requested (return or M-tab or such). I type very fast and I only want to potentially expand if I don't know what I want or there's a very long completion. I cannot seem to be able to prevent expansion when a single option is available in the menu and this causes big problems when there are already characters on the line right of the cursor.
Auto-complete menu shows fine. With each character the options get more narrow. Problem shows when a single option is left - the menu disappears and the overlay expansion shows (obscuring existing characters to the right of the cursor). When I type one more character the expansion takes effect but it is broken up with the remaining characters of the expansion as a suffix to the existing line. If the one more character I typed was NOT the one in the suggested expansion things still break but without the rest of the suggestion.
This is very inconvenient as I usually type very fast and trigger broken completions. I would like to have the menu always show automatically but expansions NEVER take effect except explicitly (I slow down my typing when I'm unsure what I want to type.
I tried all the options I found in the documentation but I just cannot prevent expansions from taking effect. I want to completely disable expansions (except for explicit expansion).
It's not that convenient when you do a typo during an incremental search and the search string receives the wrongly typed character. Is there a way to prevent this. As if control-g was pressed automatically on error.
For example we have the following text:
keywords
keys
Default emacs behavior:
We start incremental search and search for "keyz"
The "keyz" is displayed in the search echo area and the "key" part in "keywords" is higlighted
We press s
"keys" won't be found, the cursor stays on the "keywords" line, search echo area displays "keyzs", which is not convenient
Needed behavior:
We start incremental search and search for "keyz"
The "key" is displayed in the search echo area and the "key" part in "keywords" is higlighted
We press s
"keys" is found and highlited
You could try something like
(defadvice isearch-printing-char (before drop-mismatches-on-next-char activate)
(while (or (not isearch-success) isearch-error)
(isearch-pop-state)))
Emacs keeps the incorrect part, because it happens very often that you search for a string and it is not found, but not because it's incorrect, only the search string is found before the cursor. In this case it is very convenient that you can press C-s and the search starts from the beginning of the file.
It is very useful behavior and it happens to me more often than mistyping the search string. If there is indeed an error in the search string then you can simply press C-g to go back to last good search string.
I think the problem is that you're not thinking about searching in a way that's congruent with the way isearch has been designed to work, and so your question doesn't really make sense within the context of isearch as it currently exists.
Isearch does already give you exactly the feature what you want, but you have to tell it that you want it to happen by typing that C-g you seem so vehemently opposed to typing. If you don't tell isearch what you want to do, and when you want it to do it, how is it supposed to know what to do?
As #Tom tried to explain, the default way isearch starts from the current position in the buffer, and can restart at the beginning of the buffer if you've typed some failed characters and then press C-s, is a very valuable feature. I'm sure many people rely on this behaviour. Your method of using a macro to always start an isearch at the beginning of the buffer would confound and confuse many of us, though of course it's not a bad thing for someone such as yourself who is accustomed to it. It does mean though that the rest of us are quite confused by your dislike for having to press C-g to delete the non-matching text.
Think also for a moment about what a second C-s does if you press it immediately after starting isearch (any time but the first time in a session) (i.e. before you type any other character). Note in particular what happens if your previous search string would only partly match something in the current buffer, and then you press C-g (and also note how the failed search string is presented, regardless of whether it would partly match something in the current buffer or not).
Think also about how your feature might adversely affect the use of multi-isearch-next-buffer-function.
Claiming that other editors can do what you want isearch to do in emacs doesn't really help your case much.
I think what you really want is some slightly different type of search function which only allows you to search for text that it is possible to find in the current buffer, instead of isearch's ability to search for anything whether that text happens to exist in the current buffer or not.
Perhaps isearch-mode could be adapted to do what you want it to do, but one way or another I think you'll have to write some elisp code. Perhaps you could implement your new search mode as an option within isearch-mode that can be toggled on and off in the same way case sensitivity can be toggled on and off; and that can be set by default, again in the same way that case sensitivity can be turned on or off by default.
If you make a typo during incremental search all you need to do it press backspace to correct the typo.
We start incremental search and search for "keyz"
The "keyz" is displayed in the search echo area and the "key" part in "keywords" is higlighted
We press backspace
We press s
"keys" is found and highlited
As with most of the other answers, I'm just pointing out another feature which helps mitigate the described problem. This one is particularly useful if you've continued to type several would-have-been-good characters after the bad one.
M-e is the binding for editing the isearch string, and in the case where there are no matches for the current string, it rather helpfully places point at the first non-matching character.
So if you have made a small typo, you can quickly type M-e, fix the mistake, and type RET to return to isearch using the corrected search string.
I am fairly new to working in a z\OS environment, I've tried Googling this but found no result.
I'm creating a data set member in the ISPF edit window. However, every time I exit out of the file, save it, try to submit it as a JCL job, it will convert all the characters to upper case.
How can I stop this happening?
While in ISPF Edit on a member, if you type PROFILE on the "Command===>" line and press Enter, you will likely see CAPS ON included in your current options. You can change this by doing the following...
PROFILE UNLOCK
CAPS OFF
PROFILE LOCK
...on the Command===> line, pressing Enter after each.
The ISPF documentation is quite extensive. The above are what ISPF calls primary commands. The ISPF editor is quite powerful, there are SHARE presentations on its features.
ISPF Edit also has line commands, entered by overtyping the line number for a given line. Two such are UC and LC, which correspond to Upper Case and Lower Case respectively. They do just what you'd think, the former folds all text to upper case and the latter folds all text to lower case. Numbers and special characters are unaffected.
When you enter the command C-/, Emacs undoes some part of your recent changes to a buffer. When you enter C-/ again, it undoes another chunk of work.
I have read the Emacs manual entry on Undo but it is vague about exactly how it works. The manual says "Consecutive character insertion commands are usually grouped together into a single undo record" but it does not explain how it decides the number of character insertion commands that constitute a group. The number of characters it puts in a group seems random.
Can anyone explain the algorithm Emacs uses to group characters into undo records?
The logic for setting undo boundaries is mostly in self-insert-command which is implemented in cmds.c. You'll have to read the code for the full story, but basically:
As long as you are just typing characters, there's an undo boundary every 20 characters you type.
But if you issue a different editing command (you kill a word, for example), this causes an undo boundary to be added immediately, resetting the character count.
Certain "hairy" insertions (as determined by internal_self_insert) cause an an undo boundary to be added immediately, and the character count to be reset. Reading the code, it looks as though these are: (1) in overwrite-mode, if you overwrote a character with one that has a different width, e.g. typing over a tab; (2) if the character you inserted caused an abbreviation to be expanded; (3) if the character you typed caused auto-fill-mode to insert indentation.
In addition, any editing command that decides it would be a good idea to have an undo boundary can request it by calling undo-boundary. This does not cause the character count to be reset.