[crabbone]

> 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

> 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. It's like if you were trying to use Photoshop to run unit tests for some JavaScript code you wrote for Web browser. Yeah, it has a built-in JavaScript interpreter, but really, it's not meant to be used as a JavaScript runtime.

> 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 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).

Freedom and being a noob are orthogonal to each other. I didn't say you should never use scrollbars. I said that if you are a noob, that's what you will likely end up using... I don't say you shouldn't be a noob, I just say that being a noob sucks.

> For someone disabled

And for some who don't have hands, it's even worse... what's your point? There's the reality of text editors: if you have two functioning hands, you are in a very advantageous situation compared to someone who doesn't. Comparing the two doesn't make sense in the same way how it doesn't make sense to let super-heavy-weight boxers compete with light-weight boxers.That's why those categories were created in the first place.

[rajishx]

Clearly you are not understanding what tabs in emacs are... it's pretty much a visual way to identify windows-configuration-to-register, and instead of doing C-x r w REG / C-x r j REG all the time you have a nice automatic way...

(please read the emacs manual the other post of this thread as posted)

[ParetoOptimal]

> it's pretty much a visual way to identify windows-configuration-to-register, and instead of doing C-x r w REG / C-x r j REG all the time you have a nice automatic way...

That's a great succinct way to put my longer elaborate example that's a sibling to this response.

[ParetoOptimal]

>> 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.