How does the Ctrl + Z keyboard shortcut actually work in general? - keyboard

I mean, its not about some code or something, but how does that shortcut work in general, like when I am working on a something and accidentally, I delete a chunk of text, how does the shortcut, revert it back on to the screen, don't give me the code or something, but take instances of elements in the coding world like whiles, ifs etc. How did the creator get the idea that something like this should even exist?

There are multiple ways this can be achieved, the decision how, is up to the developer to decide.
One way is to make use of a stack, where the where the state of this program is stored in such a structure.
Another way is use a design pattern called the command pattern which is often used to implement undo redo functionality, this is very similar to a stack, but instead of storing the program state, you save the action done to the program together with a similar action to undo the executed one.

Related

Best workflow using Vim buffers

In the last 2-3 years that I started using Vim as my main editor, I've learned to use windows (splits) when working with multiple files (Because in every task, I need lots of files to work with)
But a few days ago, I ran into this question and it blow my mind (and my workflow :))
So I tried to use buffers and no windows and it's really hard. Imagine having multiple blocks (folders) and each one of them has a model.php and a controller.php in them.
So at the start of the task, I don't know which block I need, so after a few minutes, I'll open multiple model.phps and controller.phps.
Now, if I don't have every file that I need in my buffer, I must search buffer first and when I see that I didn't load it, now I have to use explorer and load the file into buffer. So it's something like this:
:ls<CR>
{If the file that I need is here then}
:b num<CR>
{else}
:FZF {and finding that file}
So it's a lot harder than just working with windows (Where I can see what files are loaded in front of me)
(And of course the overhead of finding buffers and searching them by name/number is like opening the file every time that you needed)
But as said in this question and lots of other places, buffers should make your workflow easier than windows and windows should be used only for diffs and etc.
So is there any better ways to use buffers or am I doing something wrong?
(BTW, I'm currently using :Buffers from fzf.vim)
So I tried to use buffers and no windows and it's really hard.
This means that you misunderstood both the spirit and the letter of the linked answer.
To recap, Vim's exact equivalent of "documents" in regular document-based applications is buffers. Vim also gives you a first layer of abstraction on top of buffers: windows, and another one on top of windows: tab pages in order to give you more flexibility with building your workflow.
Forcing oneself to use buffers instead of windows or instead of tab pages or whatever makes no sense as there is value in all three and such an attitude would only decrease the overall value of your editor. Use the interaction model that best suits your needs, not the interaction model that you convinced yourself is the purest.
As for the confusion between files and buffers, how about the confusion between files and tab pages or between buffers and windows? When you are dealing with abstractions built on top of other abstractions you have to have commands specific to one layer or another and learning how that layered cake works gives you the necessary intuition for deciding what command to use and when.
Basically, you have 3 cases:
Case #
Is a buffer
Is a file
1
Y
Y
2
Y
N
3
N
Y
In case #1, the buffer is associated with a file so you can use both file-centric and buffer-centric commands to reach your target.
In case #2, the buffer is not associated with a file so you can only use buffer-centric commands to reach your target.
In case #3, there is no buffer so yo can only use file-related commands to reach your target.
Another way to think about it is to ask the question "Have I already been there?". If the answer is "no", then use file-centric commands, if the answer is "yes", use buffer-centric commands. If you have no idea or if you don't want to think about any of this, just use file-centric commands as a fallback.
Note that the context of that answer was "buffers vs windows vs tab pages". Abstracting yourself away from the notions of files or documents is the real deal.
When speaking of "best workflow" we inevitably speak of our personal habits and tastes. So just remember that it's your editor, your workflow and your "best practices". Not someone else's.
Windows/tabs and buffers do not prohibit using each other. It is not a problem to open buffer in current window/tab even if it was already opened in another one (or even in dozen ones).
If you feel uncomfortable searching through the buffers list then try doing it with some alternative tools. For example, you like clicking with mouse then run GVim and browse through "Buffers" menu; or you are good at memorizing numbers then make all buffers numbers to show in status line and switch buffers by typing NN<Ctrl-^> directly; or you like reading file contents then find some plugin that shows also "a buffer preview" etc.etc.

Delete everything AFTER the cursor (or delete everything after the current word)

I find myself in this situation quite often in vim:
response.status == 404
^
My cursor is on the r character and I want to delete everything after the current WORD. I can do ElD to move to the end of the word, shift the cursor, delete until EOL. Alternatively I could do something like WDx to move to the next WORD, delete the whole line, and delete the extra space.
Additionally it would be nice to keep my cursor in relatively the same position as I started (I guess I could use marks for that)
Are there any shortcuts that might make this easier (e.g. less capitals, less strokes)? I'm also just trying to not use h, l, and x as much. I could add something custom, but I'd prefer to use the native keybinds
Vim golfing
Now it is common practice in Vim to try and reduce keystrokes for certain tasks, commonly referred to as golfing. Often this practice uses the following general techniques:
Use lesser used motions or commands. e.g. ZZ, ]), gi
Use an operator and motion instead of a count. 2dd vs dj
Using counts to do more at a time. e.g. 4j
Use repeatable motions. e.g. fX and use ,/; to repeat the f motion
Reuse patterns via //
Take advantage of given text. This often fails with more generalized solutions.
Use ex-commands with clever ranges. e.g. v/./,//-j
Use marks, but especially use marks that are vim set for you. e.g '`, '^.
Premature optimization is the root of all evil
Now Vim golfing is a "good thing" as it typically helps the vimmer to find new motions or techniques, but it only so helpful in the average day-to-day workflow as golfing usually require a decent amount of forethought. One cannot worry about every single keystroke for every task all-day every day (aka premature optimization).
Instead focus on optimizing the common or lengthy tasks. Do this by creating a custom mapping or command to make such task quick and painless as possible and get on with your day.
Typically I use WDD for that purpose, which will avoid pressing a third key.
Obviously, you lose the relevant part of the deleted code, so you can't use this for cut&paste.
I don't know if you'd want this, but - if you do it, this use-case becomes easier, and uses only 'native' keybindings. So - you can add, for your desired FileType, this:
:setlocal iskeyword+=.
Then, you can use elD instead of ElD, (easier on the wrist).
But, frankly, if it bothers you enough to ask about it, it means it happens often enough that it should really be accessible from an even easier/shorter, custom key binding ;)

Inefficiency in Vim

I consider myself somewhat familiar with Vim,
hate the arrow keys (let alone the mouse),
regularly look up tips and plugins to get the most out of this tool,
use it daily to manage my cloud servers, etc.
However, I always find myself doing the same mistakes probably inherited from the GUI-world:
too often switching to visual mode to see what piece of code I'm about to manipulate,
undoing changes to retrieve lost statements because I forget to utilize registers (and pasting code on temporary lines just to grab it after other edits),
relying on Ctrl-C & Ctrl-V when working with operating system's clipboard,
keep pressing j button to browse through lengthy files to find certain functions.
Probably my Hungarian keyboard layout prevents me from being faster as most of the special characters (/, [, etc.) are only available as a key combination (with Shift or Alt Gr).
Given this specific situation, what pieces of advice could you give me? Have you faced similar bad habits when you were a Vim-novice? I'd like to see my productivity skyrocket (who wouldn't?). Thanks in advance.
I've found a simple, effective strategy. Choose one action, one task or one set of keys that you think is unnecessarily slow. Figure out a better way of doing this using the vim manual or googling or a plugin etc. Force yourself to use this every time. Rinse, and repeat. The path to efficiency is one-by-one elimination of the slow parts.
I'd also recommend just reading the vim manual from time to time - even if you don't remember everything, knowing something's out there is very helpful.
This probably applies well beyond vim, but
something that worked for me was finding a specific feature that I knew would
be more efficient and concentrate on using that for a week or two.
Just one feature at a time, and possibly using it excessively.
After a couple of weeks it becomes automatic and you can move on to the
next thing.
I learn programming tricks the same way. eg. I'll have a month of using lambda expressions for everything, then a month of mapping and filtering.
(not on production code though)
Probably my Hungarian keyboard layout prevents me from being faster as most of the special > characters (/, [, etc.) are only available as a key combination (with Shift or Alt Gr).
I'm sitting in front of german keyboards all day long and know this problem very well. Some keyboard layouts are simply not very suited for programming / using vim. I think its safe to assume that most programming languages and keyboard shortcuts were designed with the us-layout in mind.
My advice: reset your keyboard layout to us-english and practive touch-typing on that layout (typing without looking at the keys). It won't matter that the keyboard labels are wrong and you'll be much more comfortable using vim hotkeys.
The only problem that still remains for me is to produce language specific characters (german umlauts such as ä,ö,ü) wich i assume will also be a problem for hungarian. For that I use a combination of vim-digraphs, linux window manager digraph-key and windows layout-switching hotkeys.
just keep using it. The more you use it, the better you become at it. VIM isn't too bad. The main thing is you just have to remember that it isn't always in edit mode.

How do I tell if a button is being held down in OpenGL/Glut? (linux)

This is a similar problem: Link
Which was solved by calling GetAsyncKeyState(). While all fine and dandy, I need a Linux alternative. I need to know if a button is being held down, not just being pressed (because of the keyboard buffer delay). Does anything like this exist in the OpenGL/Glut libraries, or will I have to look elsewhere?
I have never used Glut, but I know that many people will say SDL is better. I have used SDL and I like it a lot. It does everything Glut does and a lot more. In SDL, you can use SDL_PollEvent() to get key state without the keyboard buffer delay.
Edit: I know almost nothing about Glut, but it looks like you can use glutKeyboardFunc to detect normal keys, and glutSpecialFunc for keys that do not generate ASCII characters (such as shift). I'm not sure if there is a better way, as this doesn't seem very nice.
You can detect when a keypress event occurs, record that state, and then listen for a key release event.
As said, you will have to make your own state machine, which is easy. But you also need to use this callback method I think.
http://pyopengl.sourceforge.net/documentation/manual/glutKeyboardUpFunc.3GLUT.xml

Map keyboard for common paste operation

I want to program a key on my keyboard to paste certain static text when pressed.
For instance, I'd like to program the F12 key so, when pressed, it pastes my email address every time. Is there an easy way to do this?
There are some excellent free software products that allow you to remap keys and create macros. For Windows, you can use AutoHotKey. I've used it before and it can be quite handy for this sort of thing.
It's a very powerful tool and can be a little intimidating to use at first but it's worth taking the time to get to know it. The Quick Start guide is quite helpful.
If you mean instead, the ability to do this within your own program using C++ or .NET or something, give some more details.

Resources