I'm working on my undo chain in my project. I want to avoid that each letter gets undo'd separately, but rather that it undo's chunks of text. So i'm working with a debounce.
Is there a standard waiting time or a best practice to follow? I see that browsers and Word all work approximately the same so i thought there maybe was a standard way of doing this.
Thanks
Related
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.
Is there a way to get Vim to tell you what it did so you can look things up?
For example, I am trying to get better at navigating with vim and I noticed that when I press j I go down a row, but if I press shift+j it removes the line break at the end of the current line (or something like that).
shift+k however has no such behavior and shift+h seems to take me to the top of the current window while shift+l takes me to the bottom.
What I'm looking for is some way to understand what these movements are called so that I might be able to understand how to configure them / learn more about their behavior.
Thanks!
What I'm looking for is some way to understand what these movements are called so that I might be able to understand how to configure them / learn more about their behavior.
You are attacking the problem from the wrong end.
Learn Vim instead of trying random stuff:
If you didn't already, do $ vimtutor as many times as needed to get the basics right.
As instructed at the end of vimtutor, level up to the user manual :help user-manual. It's a hands-on tutorial that will guide you progressively through every feature, from basic to advanced. This is not a novel, go at your own pace and, most importantly, experiment along the way.
Keep an eye on anti-patterns and inefficient actions, find improvements, practice. Rinse. Repeat.
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.
I'm trying to program a Webpage, which allows to edit a text document simultaneously.
To program something like a Chat in Node.js is not very difficult, but working on the same text makes it kinda tricky.
I thought about sending the char position and the changes characters, but if someone types something previous to the change, the change would be placed on the wrong position.
What's the best way to exchange Modifications between my clients?
You should use Socket.io to have make your Real-Time application.
I just founded a nice blog article which speaks about real time edition, see here.
It's also providing a link to the github project and to an open source online editor project.
Take a look and try to understand how they do stuff like this, good luck !
Two people cannot be manipulating the same object at the same time from a different place. You basically have two choices.
1. Let them take turns with the object
2. duplicate it if they both want it, but that doesnt sound like it would end well
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.