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.
Related
I am using my keyboard to run an application in MATLAB, where each keypress is handled differently depending on the number or letter pressed. To recognize keypresses I'm using the HebiRobotics library discussed here:
Detect Keyboard Input Matlab
While running the program, hundreds of keypresses are required, each of which types a character in the command line, after the >>. Is there any way to delete these characters as they are typed so the command line remains clear? I've tried fprintf('%c',8) to backspace, but this applies to the previous executed command, not the characters on the current line.
To be honest, this isn't terribly important, but having the characters appear is ugly, takes a few extra clicks to delete, and is one of those little things that is driving me crazy.
This answer by 'Oleg Komarov' seems to be relevant -Clearing text typed with input() from command history
I am slightly confused by the difference between keys and key-bindings in emacs after reading the first chapter of "Writing GNU Emacs Extensions" (O'Reilly book).
The chapter starts by noting that in some emacs version the keys backspace and DEL, invoke the help menu instead of deleting. In other words, they invoke what is invoked by C-h.
The chapter then goes on to show how to change this behaviour using Lisp code. This is done by binding the keystroke C-h to the delete command.
This is a bit confusing to me. In my mind DEL, Backspace and C-h are three different keystrokes (the first two consisting of a single key).
Why does remapping C-h effect what DEL and Backspace does?
I would have thought to change what backspace does for example, you would remap backspace to another command, not the keystroke C-h.
Unless remapped by a low-level keybord driver, the effect of the Backspace key is to send the character with numeric code 8, which, in certain operating systems, is exactly the same code generated by pressing Control-h. You can verify this fact by simply writing anything on a unix (or linux) shell and then pressing Backspace and Control-h: both of them have the effect of erasing the previous character, since the character with numeric code 8 is interpreted by the operating system as the control character BS, backspace, used either to erase the last character printed or to overprint it (see wikipedia). Analogously, Control-J is equivalent to the RETURN key, etc.
The same Wikipedia page describe DEL as “originally intended to be an ignored character, but now used in some systems to erase a character”.
So, when you assign a command to a keystroke you are actually assigning a command to a character code, and if two or more keys generate the same code, by pressing them you are invoking the same command.
#Renzo answered your question about how these keys are related and how binding one can seem to affect another. Here is some more information about what's going on in this particular case.
See the Emacs manual, node DEL Does Not Delete.
There you will see this, following an explanation of the problem/confusion:
To fix the problem in every Emacs session, put one of the following
lines into your initialization file (*note Init File::). For the first
case above, where BACKSPACE deletes forwards instead of backwards, use
this line to make BACKSPACE act as DEL:
(normal-erase-is-backspace-mode 0)
For the other two cases, use this line:
(normal-erase-is-backspace-mode 1)
Another way to fix the problem for every Emacs session is to
customize the variable normal-erase-is-backspace: the value t
specifies the mode where BS or BACKSPACE is DEL, and nil
specifies the other mode. *Note Easy Customization::.
See also the GNU Emacs FAQ question about Backspace invoking help. There you will see, in addition to information similar to that above, information about how to remap DEL on UNIX - use this:
stty erase '^?'
Wrt C-j and RET (not mentioned in the question, but mentioned in #Renzo's answer): The default behavior of Emacs changed in most programming modes, in Emacs 24.4.
Starting with that release, electric--indent-mode is turned on by default, which means that RET inserts a newline character and indents, whereas C-j just inserts a newline character. Prior to that release, these keys had the opposite behaviors. If you prefer the old behavior then do this, to turn off electric-indent-mode:
(when (fboundp 'electric-indent-mode)
(electric-indent-mode -1)) ; Use classic `C-j' and `RET'.
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.
Which setting needs to be done in init.el file, which allows completing the rest of command if one hit M-x and initial letter of the command.
Infact in need something similar as ido-mode for minibuffer too
The ido-mode for the "M-x minifuffer" is called smex (smex use ido).
Available on the main package repos of Emacs. Homepage here
I think you are talking about incremental completion, i.e., having Emacs automatically complete what you type in the minibuffer, without your having to explicitly request completion (e.g., using TAB).
Incremental completion is available in Icicles, as well as Ido and IswitchB. And icomplete-mode shows you completion candidates in a similar way to Ido and IswitchB.
Icicles incremental completion has two aspects:
When buffer *Completions* is displayed and updated, showing you the candidates matching your input -- how soon that happens and what triggers updating
Whether and how much your minibuffer input is expanded (completed) to reflect the set of matching completions
Wrt *Completions* display (#1):
You can use C-# to cycle among the levels (normal, eager, off) at any time.
Normal means that *Completions* is not displayed until you ask for it, but thereafter it is automatically updated as you type/edit your input.
Eager means that *Completions* is displayed as soon as you type something that matches at least two candidates.
(There is also an option to show *Completions* from the outset, before you type anything -- useful as a kind of menu.) You can also specify how long to wait after you type or delete a character before updating *Completions*.
Wrt input expansion (#2):
Icicles is unique in expanding your input to (typically) the longest common match among all completions, even when completion uses apropos matching (that is, regexp or substring -- S-TAB), not just prefix matching (TAB).
There are 4 levels/behaviors for this expansion, plus off (no expansion):
Off -- this is like Ido and IswitchB: completions are shown, but your input is not completed
On request -- expand your input only when requested (TAB or S-TAB)
On request or sole candidate -- on request or when there is only one match
Always for TAB, on request for S-TAB -- TAB expands whenever possible; S-TAB is like previous
Always -- expand input whenever possible
C-" toggles between two of the input-expansion behaviors that you choose (a user option), and C-M-" cycles among all of the behaviors.
In an 80 column wide terminal emacs wraps 80 column lines, putting a backslash in the 80th column. Is there a way to tell emacs to use all 80 columns of my terminal and not wrap lines until they reach 81 characters?
If I understand this question correctly, this is not about logical line
wrapping (how lines are segmented in your file), but about visual wrapping
(how lines are displayed with respect to window width).
If you just want the display to visually wrap more than zero characters before
window boundary, and thus avoid the backslash everywhere, however long your logical lines really are, you can use longlines-mode
:
Unlike Visual Line mode, Long Lines mode breaks long lines at the fill column (see Fill Commands), rather than the right window edge. To enable Long Lines mode, type M-x longlines-mode. If the text is full of long lines, this also immediately “wraps” them all.
Then, it's only a matter of setting the fill-column appropriately, using
either global settings (.emacs, though you probably want to use a
specific mode-hook for that particular case), local settings (file
variable, dir-locals) or C-u 79 C-uC-x
f to set variable fill-column to 79. This way, lines 79
characters or higher will wrap, but before touching the right edge of the
80-char window (and thus never leaving an ugly backslash character). Your
file will be untouched.
If you simply want no visual wrapping to occur on 80-character lines, and thus do not want the 80th logical character visually displayed below the first, there are two
possible answers:
either you work in an environment where you don't necessarily wrap
logically at or before 80 characters, and you want to see the end of
those 81+ lines somewhere in your screen (i.e. you do want visual wrap, but at a number of chars above the window width), then I don't know how to do
it.
or you want to stop your lines at 80 chars logically (e.g. you
have auto-fill on and fill-column at 80), and if you do happen to have
lines 81 characters or more, you don't care about seeing their ending.
In that case, activate truncate-mode (toggle-truncate-lines).
If the issue is about the last character of your window, and what you really want is the 80th logical character of your line to be displayed on the 80th visual character of your window, though, I'm afraid I don't know how. Either you are truncating lines (as above), and the last character of your window will be a $, or you let emacs do its thing, and the last character will be a backslash.
Note when testing that auto-fill's wrapping (but also longlines-mode's, since it is its visual equivalent) will occur only at word boundaries.
One option is to set the wrapping to happen at 81, instead of 80.
M-x set-fill-column RET 81
Another option, maybe the best choice, is to define the variable overflow-newline-into-fringe as t. Try this once, manually:
M-x set-variable RET overflow-newline-into-fringe RET t
Either of these could be set by default. You can do that through M-x customize or by editing your .emacs file. Post again if you need help.
BTW, do you use emacs in a graphical or terminal environment? In a graphical environment, I often just make the window larger if I have long lines. Or I may turn on line truncation with a horizontal scrollbar.
added later
With the added information that you are running emacs in terminal mode, as you discovered, none of those options work. I tried an example running emacs in putty, where I can change the size of the window and emacs picks it right up. So, I could size to 81 columns and my 80-column lines remain intact without continuation. I am not sure which TERM value you have assigned with tmux, but you could consider creating a custom terminal type (termcap or terminfo) which supports 81 columns. I only took a brief glance at tmux but I noticed that you can resize panes within a terminal.
Now, out of curiosity, what is the primary motivator for you using tmux? I would think that the resume capability would be valuable. I would find however, that the other features are not that useful because in an X-Window environment it is cheap & easy to open more terminals or if I am using putty, I can create more of those. As far as using emacs, whether I am running under X-Window or MS-Windows, I just create as many frames as I would like and can work quite easily with that. So, is there something else that makes you interested in using tmux?
Six years after the previous answers and the workaround I still use is to use 81 character-wide windows.
Unfortunately 80-wide windows that wrap 'correctly' are not possible because of evil fringe characters. Emacs requires the last (fringe) character to have exclusive use of the final column. The argument for this is an optional fringe character is ambiguous. I dream of the day someone will submit a patch to make the fringe character optional, and perhaps solving the ambiguity with a background color.
I don't think that is prossible in general, because emacs needs at least one character to indicate that the line continues in the next line (wraps), although I'm not sure, because emacs has so many options... You could maybe instead select "Word Wrap (Visual Line Mode)" in the "Options" menu (or keyboard):
M-x visual-line-modeRET
This makes the flow more natural, without showing (at least in text modes) the indication of wrapping.