nvim -d does not work as expected

[mcctuxic]

Steps to reproduce:
Install doomnvim from the repo (development branch), do not change anything.

Call nvim several time to make all needed installations possible.

Call nvim -d .

In both tabs only file2 will be displayed.

(Previously I mapped this behaviour to changes I made to the configuration. But
this problem "works out of the box".)

[osamuaoki]

I tried:

$ nvim -d file1 file2

For main branch, I can confirm both windows show file2.

$ nvim -u NONE -d file1 file2

I can confirm both file1 and file2 are shown.

So this is a real bug in custom start up ... probably bug in bufferline I guess.

Since you can press TAB and get functioning DIFF, this is minor issue. So let"s see how dependency packages evolve for few more weeks or so.

Funny thing is bufferline is changing highlight things only recently. Do you know when this started?

[mcctuxic]

Hi, how can I help in fixing this bug instead of waiting "a few more weeks" for an guessed external root (bufferline) to be fixed by its authors?

…

On 09/25 07:52, Osamu Aoki wrote: I tried: ``` $ nvim -d file1 file2 ``` For main branch, I can confirm both windows show file2. ``` $ nvim -u NONE -d file1 file2 ``` I can confirm both file1 and file2 are shown. So this is a real bug in custom start up ... probably bug in bufferline I guess. Since you can press TAB and get functioning DIFF, this is minor issue. So let"s see how dependency packages evolve for few more weeks or so. Funny thing is bufferline is changing highlight things only recently. Do you know when this started? -- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: #127 (comment)

[osamuaoki]

Well,,,, you can help not asking tutoring like questions but dig in to the problem by yourself and coming out with solution (or at least hunting down root cause). For me, this seems tough problem beyond my time and skill. I am taking relaxed attitudes since I don't suffer much.

[NTBBloodbath]

Hi, sorry for the late reply. I was a bit occupied lately haha

I think that maybe it has something to do with our last executed command in our init file, which calls bufdo e. I'll dig on it so I can determine if the bufdo e is really needed or not so we can remove it from our init file.

[NTBBloodbath]

Should be fixed now, please update and feel free to reopen this issue if this still happens to you.

Regards

[mcctuxic]

Fixed! Thank you!

…

On 09/26 01:38, Alejandro wrote: Should be fixed now, please update and feel free to reopen this issue if this still happens to you. Regards -- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: #127 (comment)