This snippet is moved fromjavascript.vim to here.

I am not sure if it is a good idea to filter Javascript-like files only. Because in web development, we could also use HTML, CSS, EJS beside Javascript.

Not to say that this behavior is not documented (which means it is unexpected to users), so should this be removed?

I am not sure if it is a good idea to filter Javascript-like files only. Because in web development, we could also use HTML, CSS, EJS beside Javascript.

I agree it's useful to include related files, and have a local copy adding HTML and CSS, but it was never clear where to stop with this. It seems reasonable to limit the filters to the actual filetype and utilise the "All Files" filter for anything else.

Are you suggesting the order should be changed to default to "All files"? That's the default behaviour but the filetype plugins have always put that last, I think.

Not to say that this behavior is not documented (which means it is unexpected to users), so should this be removed?

I'm not sure what needs to be documented as the filtering is discoverable simply by opening the file dialog. Rather than remove it, I think abrowsefilter value should be set for all filetypes.

I don't have a strong opinion on whether to keep it or remove it or add what, but I think this kind of behavior should be documented and consistent between different filetypes.

I'm not sure what needs to be documented as the filtering is discoverable simply by opening the file dialog.

I would never know what kind of filetypes it filters without trying it several times. That is bad UX.

You mean the(has("gui_win32") || has("gui_gtk")) ? Or what exactly should be documented? The browsefilter variable is defined for "Windows, GTK and the Motif UI". But although Motif GUI supports the browsefilter variable, there is no easy way to switch different filters. So restricting it togui_win32 orgui_gtk makes sense.

Does it make sense to set the omnifunc from Javascript also for Typescript? Similar for the 'define' option and matchit values?

For what it's worth, I came up with these settings for typescript, but@romainl surely has better founded ideas on their right values

setlocalinclude=^\\s*\\%(import\\|export\\).*\\<from\\>\\s*['\"]\\zs[^'\"\\r\\n]\\+\\ze['\"]\\|\\<require(\\s*['\"]\\zs[^'\"\\r\\n]\\+\\ze['\"]let &l:define='^\s*\('\..'\(export\s\)*\(default\s\)*\(var\|const\|let\|function\|class\|interface\)\s'\..'\|\(public\|private\|protected\|readonly\|static\)\s'\..'\|\(get\s\|set\s\)'\..'\|\(export\sdefault\s\|abstract\sclass\s\)'\..'\|\(async\s\)'\..'\|\(\ze\i\+([^)]*).*{$\)'\..'\)'ifexists('b:match_words')letb:match_words.=','elseletb:match_words=''endifletb:match_words='\<function\>:\<return\>,'\..'\<do\>:\<while\>,'\..'\<switch\>:\<case\>:\<default\>,'\..'\<if\>:\<else\>,'\..'\<try\>:\<catch\>:\<finally\>'

Just stumbled ontohttps://github.com/HerringtonDarkholme/yats.vim/blob/master/ftplugin/typescript.vim#L91 ; an include expression is also useful

I also have an includeexpr that can even jump to Node moduleshttps://github.com/brianhuster/dotfiles/blob/main/.config/nvim/after/ftplugin/javascript.vim

But I don't think it will be very useful because of#16707, and alsolanguage server covers this feature well.

language server covers this feature well.

Ctags and Language Servers take you further, but we're here to max out Vim's built-in functionalities. This reminds me ofzzzyxwvut/java-vim#4 (comment) ; even if&include sometimes breaks ongf, its principal use is including other files for grepping#16916 (comment)

but we're here to max out Vim's built-in functionalities

Just think how many people use the built-in omnifunc of JavaScript in 2025?

I will not add it to this PR, but if you want to do it for your own PR, you are free to do that.

noone even did anything, until I did.

That's commendable, keep up the good work

I will not add it to this PR, but if you want to do it for your own PR, you are free to do that.

Okay, one step after another.

Btw, a formatexpr forVimscript andhelp will be nice, I think these Vim's specific languages need "maximized Vim functionalities" the most.

Yes, makes sense, a separate issue. For help.vim, there'sHelpFormatExpr floating around