An implementation of simple, intuitive tabs in Emacs.

The problem with assigning buffers to tabs is that it doesn't scale. I usually have dozens of buffers open before I have a typical emacs session running for very long. So I don't understand how anyone could find assigning a tab to each buffer usable at all. I find that the ability to rotate among the N most recently viewed buffers to be a thing that I need to be able to use buffers effectively. I have bindings for doing just this up to N = 5. When I need an older buffer, ivy or similar works just fine. If someone came along with a way to assign the most recently used buffers (to some configurable number) to tabs, that might be something I could actually use.

I think this is how many people use Emacs, ergo why this is not a popular option. Might I assume you are a programmer? I am not a programmer, I use Emacs for org-mode, and I'd rarely have more than 5 buffers I am actively working on.

I can only see tabs useful with Emacs on phones or so. Elsewhere, tabs encourage mouse usage over keyboards and muscle memory. It’s an invite to be less efficient.

I can assure you I never use the mouse in Emacs. Am I allowed to prefer tabs yet?

Part of what makes Emacs so great is that it’s possible to make it behave anyway you want. Your project here is a good example of this. It wouldn’t work for me, as I often have hundreds of buffers. But that’s fine, cause it’s not meant to solve an issue in my workflow, it’s meant to solve an issue in your workflow :) Out of curiosity, did you try [centaur-tabs](https://github.com/ema2159/centaur-tabs) before making your own mode? It might have gotten you reasonably close to what you were after. Though I know from personal experience, that “close” might as well be light years sometimes… lol Edit: Fixed a typo and minor rewording.

> Part of what makes Emacs so great is that it’s possible to make it behave anyway you want. Exactly. :) > did you try centaur-tabs before making your own mode? Good question. I certainly remember coming across it - I can't exactly remember why I discounted it though... Looking over it now though, and you're right, it certainly seems like a contender. I'll have to test it out I think. :)

Sarcasm is unnecessary, if you don’t want opinions, then you shouldn’t post.

Greatest thing about emacs is, that you can use it however you like. And if you can’t you go hack on some elisp and then you can. If people want to use the mouse in emacs, so be it.

This is really great, what really interests me and I would really like to ready about is how as a non-programmer - as you stated - managed to write such a package, what steps have you followed and form where did you start. I would really love to know more.

Ohh, for sure! I wouldn't call it a package, but it has met my needs very well. No secret formula as to how I did it, a lot of trial and error, a good amount of frustration and a lot of time spent going down rabbit-holes. But here are some resources I found helpful: - This article is a great, complete beginner intro: https://harryrschwartz.com/2014/04/08/an-introduction-to-emacs-lisp.html - System Crafters makes amazing videos, his intro to elisp playlist is no exception: https://www.youtube.com/watch?v=RQK_DaaX34Q&list=PLEoMzSkcN8oPQtn7FQEF3D7sroZbXuPZ7 - The exercises on exercism were also a great way to get some handson experience: https://exercism.org/tracks/common-lisp - The internal documentation for Emacs is exceptional. I used describe-variable and describe-function constantly throughout this. Other than that, as I mentioned something I relied on significantly was online help. Stack Overflow, Stack Exchange and even this subreddit has been very helpful. Finally, this was my most ambitious project in Emacs so far. Starting with smaller things definitely helped give me some experience. :)

I feel like finding what you want is often just as hard as making it yourself. I was proud of a function I made just to find it was a core feature.

Very true. Out of curiosity, in the end did you go with your custom function or the out-of-the-box feature?

I use my own, but I don’t know why.

If you are confusing sarcasm with honest opinion, perhaps you ought to reconsider your willingness to share your precious opinions? A less combative attitude would be better. I could see myself using tabs to keep tabs on (pun intended) the few buffers that I have open. I generally close any buffer I am not currently working on, so a simple and intuitive package like this could be a good addition to help my workflow. I never use the mouse in Emacs, I have set avoidance mode to 'banish' ... Visual tabs does not require you to mouse around. If you don't want to, that is. ​ Since it is obvious that you haven't bothered to visit the project and read the motivation, allow me to quote it here: ​ >I know many don't feel this way, but I like using tabs. And more than this, I like the simplicity of having one buffer per tab. > >I tried doing things The Emacs Way (TM) of having buffers managed invisibly in the background, but I could never get a good mental model for this. I needed a visual representation of what buffers were open and their order. ​ Visual representation. That's what it's about. A mental model.

I really like this! I have also been on a quest for the Holy Grail - in my case creative writing environment - and finally been able to have my Holy Grail and drink from it too, by means of Emacs :) I am definitely going to try your package, as it sounds like something I could use. I also like to have a visual representation of the few buffers that I have open.

I use keybindings to select tabs by number and I scroll through tabs using key bindings very similar as to how i3wm works. No mouse needed at all.

> describe-variable and describe-function I don't usually suggest going with an external package over a built-in one that works... BUT: [helpful](https://github.com/Wilfred/helpful) The more you do in elisp, the more you'll appreciate the enhancements it provides. Think of it as "consult" for the help system. Drop-in replacements for most help commands that give you more immediate access to the information you want.

You can make the tabbar only show the last 5 buffers, with each bound to a key bind, this way your workflow wouldn't change at all beyond 5 buffers, but now you can interact faster with last 5 recent buffers. I basically do the same, but found using recentf with ivy instead of keeping a list of buffers opened is sufficient 99% of the time. For the last 1%, I also have a key bind to save the file path into an org file under appropriate headings if I decided I that I need a faster way to get back to it, which is usually when I found myself spending more than half a second to reach the file with recentf. I would argue most of the time we should only work with around 4,5 files. If we need more, then we should break the task down into smaller chunks. Personally, I found having too many buffers open make me confuse more than it helps. This is after I took a great deal of time making a fancy ibuffer configuration for grouping buffers. TLDR: I use tabs to further optimize access time for the few most recent files, while maintain the same access time for older files using a combo of recentf + ivy + an auto grouping functionality inspired by ibuffer, compared to the popular way of keeping many buffers open.

Yes. I see your point though and realize different people have different needs. I should have added “for me” to the first sentence.

Interesting thanks for the info. ~~I may try it.~~ I ended up using tab-line-mode with a small amount of advice to limit it to the first 5 buffers, in reverse order (so MRU on left). This works quite well and fits perfectly with my existing buffer rotation key bindings (M-<n> rotates the nth MRU buffer to be first). It was a little hard to keep the current order of buffers in my head and I would sometimes rotate with the wrong buffer. Now the order is visible and I think it will be an improvement.

The PO comment was sarcastic, it was unnecessary, and I pointed this out without disrespect. That is not being combative IMH. Now, I haven’t said tabs “require” you to use a mouse neither, I said tabs “encourage” mouse usage. The same applies to menu-bar-mode, tool-bar-mode, scroll-bar-mode and so, yet Emacs ships with them. Obviously, some people like to have weird tools displayed, like neotree. I just point out that there are much more efficient ways of doing the same stuff without giving up space that way. The comment mentioning Ivy is a good example. I prefer Helm’s approach. Both are highly efficient and just disappear if you are not selecting buffers.

I do something similar. I keep a handful of buffers open and then I speed up access to other files with a combination of recentf + find-files-anywhere. I'm glad emacs allows many different ways of working.

Yes, but those the modes you mention are designed to be operated by the mouse. This package offers a visual representation of the buffers, like the tabs in a browser. There is a difference :) And, unlike browser tabs, there's no need to grab the rodent (if you don't want to) Even though I prefer highly efficient methods of interacting with Emacs, like Ivy or Helm, and I generally don't use Neotree/Treemacs, I could see myself using this package as a very lightweight, and non intrusive, way of visualizing the buffers (and their relationship) I am working on. Emacs is all about making it do exactly what you want it to do, how you want to do it. I just wanted to point out that what this package provides has very little to do with mouse usage.

Kudos for working this out and taking the time to learn more about `Emacs` and `elisp`. I use `centaur-tabs` via `doom emacs` but recently I've been grappling with a specific bug involving tabs, mouse-events, and dired-mode. I'm adding this to my queue for the next time I play around with my config.

I mainly use Emacs for creative writing in org-mode, and I rarely have more than just a couple buffers open. My novels are in one single org-file, so any other open buffer is going to be auxiliary, and very often short-lived. I am overzealous about killing any buffer I don't use :) In my web browser, however, ... hundreds of tabs running :P

Well, we have very different ways of seeing things. See: The menu bar can be operated with the keyboard actually, but it invites users not to, so you assume it needs a mouse. It’s a matter of UX. It’s just counter intuitive to most of the users to have such a GUI element and use it through the keyboard. The scroll bar may be just a visual representation. The tabs in browsers can be operated with the keyboard, like `C-TAB` and `M-1` to `M-9`, `C-w` and more, so, you don’t need a mouse either. You didn’t know, you assume they were designed to need a mouse because GUIs invite users to grab a mouse so hardly. That’s what I was saying about tabs in Emacs: tabs encourage mouse usage.

The same happens with tabs in Firefox. I don’t say you need a mouse, I say it invites users to use it. Tabs as a UI element work that way in the user’s mind.

For sure - please let me know if you need any help with it, there may be some idiosyncracies.

Made me smile >this has been a goal of mine ever since I started using Emacs. I would love if you can also address the following [issue](https://www.reddit.com/r/emacs/comments/epu38u/tabs_for_perspective_perspel/). Perspective has become a big part of my workflow along with KDE activities and having a tab line of the current perspective would be great. Thanks.

It doesn't look like a package, but a bunch of functions from someone's config. The biggest part of programming is not writing code itself, but the maintenance. Think of other people who will want to use your code, read it, fix bugs, or maybe even try to learn Elisp. So if you want your code to be more usable for others, I'd advice you to read https://github.com/bbatsov/emacs-lisp-style-guide. And another simple thing, to help you write better code, https://github.com/purcell/flycheck-package. Also, out of curiosity, why README isn't in org format?

some more things (I purposely don't speak about issues which covered in the Style Guide): - several functions you use are just wrappers around standard ones (like `kill-buffer`), why don't use advices instead? - things like (append (seq-take my/current-tab-list (- n 1)) (list (elt my/current-tab-list n)) (list (elt my/current-tab-list (- n 1))) (seq-drop my/current-tab-list (+ n 1))) I would put into separate named functions, they contain pure transformations, yet a bit complex to read. - (this one is a matter of taste, though) (if buffer-file-name (ido-find-file-in-dir (file-name-directory buffer-file-name)) (ido-find-file-in-dir "~/")) I would rewrite as (let ((dir (if buffer-file-name (file-name-directory buffer-file-name) "~/"))) (ido-find-file-in-dir dir)) - I see that you use `ido`, but not everyone does (actually, according to a survey, there's only 11% ido users). So some generic solution is more preferable. But even if you want to use `ido`, you have to `require` it explicitly. - you use `(seq-position my/current-tab-list (current-buffer))` a lot, why don't put it into a separate function? - make the whole thing a minor mode

I use tabs for jira stories that have related org and compilation buffers. Before that, switching between things meant manually setting up my window layout and that was quite annoying. So I use tabs to manage window layouts and projects I guess.

As it happens, I already use helpful, and you're right, it's great. Thanks for the tip though. :)

> It doesn't look like a package, but a bunch of functions from someone's config. I definitely do not consider it a package, a bunch of functions from my config is precisely what it is. I just wanted to share it to get feedback and on the remote chance anyone else was also looking to fix this problem. >So if you want your code to be more usable for others, I'd advice you to read https://github.com/bbatsov/emacs-lisp-style-guide. And another simple thing, to help you write better code, https://github.com/purcell/flycheck-package. This is *exactly* the type of tips I was hoping to get - thanks! I'll check those out now. :) > Also, out of curiosity, why README isn't in org format? No good reason. Github just recently started rendering org-mode files didn't they?

Once again - this is precisely the kind of feedback I was hoping to get! Thanks so much for reading over it all. :) > several functions you use are just wrappers around standard ones (like kill-buffer), why don't use advices instead? You know I'm not rightly sure, particularly since I draw upon advice so heavily elsewhere. I *think* maybe I was worried about generating strange behaviour elsewhere `kill-buffer` is used? But I'll give it a shot and see how it goes. :) > I would put into separate named functions, they contain pure transformations, yet a bit complex to read. That makes sense for sure. Those functions in particular I felt were very inelegant: it seems like far too much work to perform such a simple task. But it worked so... It's getting late where I am right now, so I'll come back to the rest of your thoughts later. But again, thank you for reviewing it. As a hobbyist, I can hours upon hours getting stuck in rabbit-holes and spinning my wheels on simple problems. So getting considered, experienced feedback like this is just gold. :)

Thanks for the feedback. I can say I'm not likely to get onto this - I haven't had any experience with Perspective - it's a bit outside my wheelhouse. Good luck though!

> Github just recently started rendering org-mode files didn't they? I dunno, if 10 yrs sounds recent enough for you