normally in favor of ternaries but in this case, is this clearer?

I agree the ternary is dense. I also didn't write it, and it looks like you've merged the PR :)

This change causes the first buffer opened by Neovim to not get a filetype if a user has the following configuration

{
			"neovim/nvim-lspconfig",
			event = "BufReadPost",
			config = function()
					vim.lsp.enable({ "lua_ls" })
			end,
		},

If the call above is vim.scheduled or vim.api.nvim_command('doautoall nvim.lsp.enable FileType') is vim.scheduled, then it works correctly. I'm not sure what the desired behavior should be, that's why I'm asking here first instead of just creating an issue.

cc @justinmk (apologies for the ping, I just saw that you were mainly involved in this PR from Neovim core team). I'm just asking for how this should be dealt.

This change causes the first buffer opened by Neovim to not get a filetype if a user has the following configuration

Have you been able to root cause why this is?

@dpetka2001, you shouldn't be calling vim.lsp.enable in a BufReadPost. It's meant to happen once early on when your neovim starts up.

The previous commit fae4abd does not have this problem. The problem was introduced because of calling directly vim.api.nvim_command('doautoall nvim.lsp.enable FileType').

From its help it mentions

enable({name}, {enable}) vim.lsp.enable()
Auto-starts LSP when a buffer is opened, based on the |lsp-config|
filetypes, root_markers, and root_dir fields.

BufReadPost gets emitted when a buffer is opened. The problem is that the filetype detection fails with the first buffer, whereas that wasn't the case previously.

In the previous commit the autocmd would still get created and left up to Neovim when it would execute.

From its help it mentions

enable({name}, {enable}) vim.lsp.enable()
Auto-starts LSP when a buffer is opened, based on the |lsp-config|
filetypes, root_markers, and root_dir fields.

That help doc is explaining that enable() sets up the filetype-detection.

The problem is that the filetype detection fails with the first buffer,

That doesn't sound related to enable() in particular.

AFAICT, your setup expects BufReadPost to happen after 'filetype' is set. But on startup for buffer 1, that isn't the case:

nvim --clean --cmd "au BufReadPost * echom 'ft=' &filetype" .tmux.conf

That has nothing to do with vim.lsp.enable(). The fact that your setup accidentally worked before seems irrelevant. The core issue is that the ordering of BufReadPost and FileType are different during startup vs after startup.

With the following repro

vim.api.nvim_create_autocmd("BufReadPost", {
	callback = function()
		vim.lsp.enable({ "lua_ls" })
	end,
})

The problem occurs when you do nvim --clean -u repro.lua and then from the Neovim startup page you do :e repro.lua to open the buffer. If you then do set ft? you will see it prints out filetype=.

If you do nvim --clean -u repro.lua repro.lua directly and then you do set ft? you will see it prints filetype=lua. So, no problem if you open Neovim with a file argument.

If you comment out that specific line that does doautocmdall (or even vim.schedule the doautocmdall) the first case where you do nvim --clean -u repro.lua will also detect correctly the filetype.

The line that was added vim.api.nvim_command('doautoall nvim.lsp.enable FileType') causes a different behavior for the filetype detection of the first buffer in the 2 cases above.

You can verify what I said with the repro.lua provided and the steps mentioned. I also vim.scheduled the call to vim.api.nvim_command('doautoall nvim.lsp.enable FileType') and the filetype detection occurred correctly in the first case with nvim --clean -u repro.lua and then :e repro.lua and :set ft?.

Is the behavior in the 2 aforementioned cases expected? With commit fae4abd this didn't happen.

That's not how it's supposed to be used, so no wonder this doesn't work.

Yes, I'm trying to understand why this happens. I did not insinuate this is an issue. I myself wasn't sure if this was an issue or not, that's why I did not create an unnecessary issue and instead preferred to ask here.

Why does the line vim.api.nvim_command('doautoall nvim.lsp.enable FileType') affect the filetype detection as opposed to how it used to work.

I used a Vimscript script to log the execution of the events when Neovim opens. The script is available in this gist. I'm not saying someone should check it.

But with the above script and opening Neovim with nvim -c "LogAutocmds" I can see that the FileType event occurs before BufReadPost. Whereas if I open Neovim with nvim -c "LogAutocmds" some_file.lua I can see that there's only a FileType event after a BufNew event and no BufReadPost event in this case.
This is just to show how I tried to understand how the order of the 2 events gets executed when you open Neovim with a file argument or not.

Again my question here is why does the addition of line vim.api.nvim_command('doautoall nvim.lsp.enable FileType') cause different behavior with regards to filetype detection.

I would appreciate if someone can shed some light. I'm genuinely asking for information to understand. I totally understand that I'm asking for some of your personal time, so if nobody can give additional info that's totally acceptable as you can only interact with so many Neovim users.

Totally appreciate the curiosity here, @dpetka2001. I do not know what's going on here.

@jfly If you do

vim.schedule(function()
  vim.api.nvim_command('doautoall nvim.lsp.enable FileType')
end)

Does it have any negative effect for the reason that you created this PR? Because if you use vim.schedule then the filetype detection works as expected.

we can try that change, feel free to send a pr. with a concise and clear Problem/Solution explanation. not the wall of text above.