| >> What do you use for managing multiple buffers? > Ibuffer > Some people use Helm or Projectile. There's a whole section in the Wiki about it: https://wikemacs.org/wiki/Buffer_management I'm familiar with and have used Helm, Projectile, and project.el. I've also read that Wiki quite a few times :) >> The tabs in emacs are different than the ones in vscode. > Just forget tabs exist in Emacs. Like I said, they are for people who are used to have tabs, but serve no purpose if you use Emacs. That's not true. I use both Ibuffer and tabs. I effectively use tabs to hold window configurations and project buffers. That means instead of having to pick related buffers out of ibuffer I just switch to tab `proj1` and things are probably how I need them already. I suppose I could use registers, but that seems like more steps. I'll use this ibuffer state with two projects open as reference for my next example: MRL Name Size Mode Filename/Process
--- ---- ---- ---- ----------------
[ Default ]
% *Help* 506 Help
* *proj1-eshell* 41 Eshell /tmp/proj1/
% proj1 212 Dired by name /tmp/proj1/
*% *Completions* 134 Completion List
* *proj2-eshell* 41 Eshell /tmp/proj2/
% proj2 212 Dired by name /tmp/proj2/
foo 0 Fundamental /tmp/proj1/foo
bar 0 Fundamental /tmp/proj2/bar
*scratch* 145 Lisp Interaction
*% *Messages* 1697 Messages
*% *Async-native-c... 228 Fundamental
With ibuffer if I wanted to start working on `proj1` I'd need to replace `tab-bar-select-tab` with:- `C-s foo RET` to open the foo buffer
- `C-x p e` to open the eshell buffer I don't have to do that if I use tabs because the window configuration was already in that form. If I had many source files open or some other more elaborate window configuration it's even more unwieldy to not use tabs. Imagine this example scaled up to with `proj1` and `proj2` having `foo2` through `foo6` and `bar2` through `bar6` each visible in a window split 3x3. Each time I switch projects I wouldn't want to manually recreate that split. I may not even remember it. Even if I created a register I may not remember that I created a register. However if there is a tab that already contains that window configuration it is unavoidable because that tab holds the context for me. I don't see any other way to get this functionality without tabs or without me "just remembering". In case you have some counter-example in mind, it'd be good to work from a common example. Here's the bash snippet I used for the example above: cd /tmp && mkdir proj1 && cd proj1 && git init && touch foo && cd .. && mkdir proj2 && cd proj2 && git init && touch bar
>> tab == buffer in vscode> Not sure what you are trying to say... Do you mean a "tab" in VSCode terminology is equivalent to "buffer" in Emacs terminology? -- If so, that's not true. VSCode has a number of fixed windows, which cannot have interchangeable contents. It has a window dedicated to showing text files, it has a window dedicated to interaction with shells, it has a window dedicated to interaction with filesystem etc. While this is really inconvenient and the lack of generic approach is really hurting due to inconsistencies between these windows, that's how they chose to do it. I meant to express that vscode tabs are more limited than emacs tabs. >> I used to think this, but my mind was changed after seeing many experienced emacs users that do prefer using scrollbars > I haven't met a single Emacs user who'd use scrollbars. I probably met about 2-3 dozens. Most wouldn't even know what they look like. Scrollbars aren't well-integrated into the rest of interaction with the program. It's a handicap if you use them. I cannot think about a single reason, a single situation in which scrollbars would be preferable to other methods of navigation. They are less precise, slower and in some cases impossible to implement (eg. infinite buffers). Scrollbars are the least convincing example of my point. The menu-bar and context menu are much more compelling I'd say. FWIW I don't actually use visual elements at all and just use the keyboard. |