[Feature Request]: Pinned buffers persist scrolling

[ttytm]

What?

I wondered that pinning a buffer won't make them scroll persistent. Or that there isn't an option for it.

I know this might be an opinionated issue opening, but maybe you can also see a point in this.

Also, I might just be doing something wrong with my config that it doesn't behave that way?

Why?

• Improve UX.
• Pinning buffers gets a more distinct functionality and its own use case: When sorting buffers first is all there is to pinning-a-buffer, it is something that can also be achieved by other functionalities.

An example use case for this feature:
Keeping buffers in focus where the main work is concentrated even when having a number of buffers open that exceeds the bufferline length.

[akinsho]

Hi @tobealive,

This is an interesting idea 🤔, the thing with something like this or other feature requests like this that are suggested as options e.g. #413 is that rather than being good candidates for options they are better implemented as refactoring in one direction or another i.e. it'll have to change for everyone. In this specific case, pinned buffers are just a type of group and there's no concept of sticky groups or sticky components really. It would take some thinking, but might be doable. Will leave this open as a reminder. One for the future, maybe.

NOTE to self/posterity: I'm currently thinking that maybe if groups had a configurable property like sticky then when doing the truncation logic we could always leave sticky tabs and remove everything else until there was nothing non-sticky left. That would basically stop sticky buffers from being removed from view 🤔 💭

[metalelf0]

Hi @akinsho ! Another interesting feature for pinned buffers would be to have commands to close all unpinned buffers, or modify existing ones to do so. What do you think?

[akinsho]

@metalelf0 a user can already do this by using the :BufferlineGroupClose pinned command.
EDIT: saw you meant unpinned, you can do the same but use the ungrouped but that won't close things in other groups.

Tbh I'm pretty against adding more buffer manipulation commands they increase the surface area for bugs and additional feature requests even more, making this plugin increasingly hard to maintain

[akinsho]

I'd prefer to provide or tweak APIs so users can create their own commands rather than add more going forwards, I largely regret most of the ones I added like close left/right since I now just get issues about things like that

[ttytm]

I use the close left / right quiet often. Which hindrance is created with such functionalities if I may ask?

Of course giving a nice api is a developers loved freedom. Sometimes too it's much freedom :P

[akinsho]

they increase the surface area for bugs and additional feature requests even more, making this plugin increasingly hard to maintain

I think this is the answer to your question @tobealive , as we speak there is 1 PR needing my involvement and review to change the behaviour of close left and right and have been about 3 issues relating to those (i.e. the issues are about force closing and modified buffers), but the point I'm getting at is that I don't have the bandwidth to deal with lots of small features that generate cumulatively a bunch of issues. It would be easier for me if users hand an API they could use to create their own commands

In either case, I'd love to keep this specific issue focused on the original feature request and not delve into other stuff here

[jackielii]

I'm trying to use this to implement my own "harpoon" like functionality. My use case:

I have important files I always want to jump to with a single shortcut without thinking. Harpoon does this for me, but when have both harpoon and bufferline together, I can't reason what to press... See my integration ThePrimeagen/harpoon#352 (comment) of the two. I tried to different keys for each at first, but quickly realised when I see top bar, I want to press <M-1 to 9> to switch anything in the tabline. I then tried to give <M-1> to <M-4> to harpoon and the rest to bufferline, but got overwhelmed by having to think about where it comes from...

So my idea solution is to keep the pinned buffer always visible on the left area of tabline, so I don't loose context which is what the OP is asking.

I tried digging into the source code to find:

1. hide pinned group
2. make sure numbering is always consistent after pinning. I.e. always show absolute numbering [Bug]: buffer jumping using ordinal numbers #652 (comment)
3. retrieve pinned group and render it in the left custom_area

So far I'm not successful in none of tasks. Maybe if these APIs are made accessible, users can just configure them instead of increase the setup configuration.

Update: for item 2, I found a solution, albeit not very clean:

  {
        ...
        options = {
          numbers = function(opts)
            local state = require("bufferline.state")
            for i, buf in ipairs(state.components) do
              if buf.id == opts.id then return i end
            end
            return opts.ordinal
          end,
       }
  }

[jackielii]

I made https://github.com/jackielii/neo-tree-bufferline.nvim and been using it for a few weeks now. It works well for me. Maybe you can give it a try if you're using neo-tree already