[ParetoOptimal]

> adding so many customized code lines to my .emacs to reassemble the modern editors

I feel like trying to recreate vscode in emacs could be a suboptimal approach to say "add a directory sidebar and lsp-mode, but get used to emacs buffer and tab handling"

[crabbone]

Why would anyone want to recreate VSCode in Emacs? It's like asking a philharmonic orchestra to play Country Roads... Yeah, they probably can do a very good job at it, but they are there to play some more interesting music, wouldn't you think?

> get used to emacs buffer and tab handling

This clearly shows you've never used the program you are so confidently talking about... What tabs?

[ParetoOptimal]

> This clearly shows you've never used the program you are so confidently talking about... What tabs?

lol, quick to go for the jab mister crab.

https://www.gnu.org/software/emacs/manual/html_node/emacs/Ta...

Specifically I use https://github.com/mclear-tools/tabspaces

[crabbone]

What's the connection?

There are plenty of ways of managing multiple buffers, and tabs is... just one of them, and, it's just not good... Complaining about it just means you don't understand how to use the editor you are complaining about. These tabs are for people who come from another editor and think they need tabs. Similar to how you can have scrollbars or panels with buttons to do things in Emacs, but they aren't there to improve editing experience, they are there to help the inexperienced to transfer their experience from other editors onto the new one.

[ParetoOptimal]

There are plenty of ways of managing multiple buffers, and tabs is... just one of them, and, it's just not good... Complaining about it just means you don't understand how to use the editor you are complaining about. These tabs are for people who come from another editor and think they need tabs. Similar to how you can have scrollbars or panels with buttons to do things in Emacs, but they aren't there to improve editing experience, they are there to help the inexperienced to transfer their experience from other editors onto the new one.

> What's the connection? > Complaining about it just means you don't understand how to use the editor you are complaining about.

I must admit, I'm pretty confused here.

I'm not complaining about tabs?

> There are plenty of ways of managing multiple buffers, and tabs is... just one of them, and, it's just not good

What do you use for managing multiple buffers? Do you not care about distinguishing one projects buffers from any other project?

> These tabs are for people who come from another editor and think they need tabs.

The tabs in emacs are different than the ones in vscode. In emacs terms there is only one window containing one buffer you cannot change per tab.

tab == buffer in vscode

> Similar to how you can have scrollbars or panels with buttons to do things in Emacs, but they aren't there to improve editing experience, they are there to help the inexperienced to transfer their experience from other editors onto the new one.

I used to think this, but my mind was changed after seeing many experienced emacs users that do prefer using scrollbars, buttons, or the new context-menu-mode.

emacs is about freedom in a lot of ways including how you use emacs, not some "ur a noob if you use the mouse" type thing.

> they are there to help the inexperienced to transfer their experience from other editors onto the new one.

People vary. For someone disabled, it's possible that in many scenarios using the mouse is faster for them than the keyboard. So the fact they use the mouse doesn't make them inexperienced.

There is utility in these features and they don't purely exist to bridge the gap for new users coming into emacs.

[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]

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