[vim/vim] Setting both autocomplete and complete=o makes SQL buffers almost unusable (Issue #21421)

10 views
Skip to first unread message

kinemato

unread,
Oct 1, 2026, 11:13:06 AM (3 days ago) Oct 1
to vim/vim, Subscribed
kinemato created an issue (vim/vim#21421)

Steps to reproduce

  1. Start Vim with the following commands, setting autocomplete and complete=o in this order:

    vim --clean
:set autocomplete
:set complete=o

  2. Set the buffer's filetype to SQL and enter Insert mode:

    :set ft=sql
i

  3. Input becomes unresponsive. Specifically, after pressing a key, nothing appears in the buffer for approximately two seconds. Instead, the following error message is displayed in the message area. Only after those two seconds does the typed text appear in the buffer.

    SQLComplete:The dbext plugin must be loaded for dynamic SQL completion

Expected behaviour

Under normal circumstances, even though the documentation explicitly states that the SQL ftplugin depends on the dbext plugin, the ftplugin should not prevent users from entering text into a buffer simply because certain built-in options are enabled.

Ideally, it should do one of the following:

  • Silently fall back to the default omnifunc.
  • Set omnifunc, but fail gracefully and without blocking when completion is triggered without dbext being installed. It should also respect any omnifunc explicitly set by the user rather than forcibly overriding it.
  • At the very least, document the potential consequences of enabling both autocomplete and complete=o.

First, regarding the cause of the input delay: in $VIMRUNTIME/autoload/sqlcomplete.vim, around line 695, the function s:SQLCCheck4dbext() contains two instances of :sleep 2.

I would not recommend simply removing these sleep commands as a fix. Although doing so would prevent input from being blocked, it would cause the error message to appear repeatedly and at a high frequency, which would be quite annoying in practice.

In fact, a similar issue was reported last year. One of the comments also pointed out that autocomplete could cause breakage. Although that issue was marked as fixed, the underlying problem described here has not actually been resolved.

More specifically:

  • The commit associated with that issue added a check for dbext during initialization in sqlcomplete.vim. This avoids one attempt to set omnifunc.

  • However, there are still two other places where omnifunc can be set while loading or using an SQL buffer:

    1. Around line 497 in $VIMRUNTIME/ftplugin/sql.vim, where omnifunc is set when an SQL buffer is loaded.
    2. Around line 607 in $VIMRUNTIME/autoload/sqlcomplete.vim, where the function is triggered by a key mapping defined by the ftplugin. If omnifunc is not sqlcomplete#Complete, it forcibly overrides the current value.

This leads to some rather undesirable behavior.

For example, when users discover that the SQL omnifunc depends on dbext, a natural workaround would be to use the following configuration:

" In after/ftplugin/sql.vim
setlocal omnifunc=syntaxcomplete#Complete

However, this does not fully work. When the user presses the key mapped by the ftplugin, omnifunc is still forcibly overridden. This is particularly problematic because the default mappings can be triggered accidentally and involve a frequently used key combination, <C-c>.

Some workarounds that actually work are:

" Workaround 1

" Set this before $VIMRUNTIME/ftplugin/sql.vim is loaded
let g:omni_sql_no_default_maps = 1

" Then override omnifunc in after/ftplugin/sql.vim
setlocal omnifunc=syntaxcomplete#Complete

Or:

" Workaround 2

" Set the completion mode used internally by sqlcomplete
" before $VIMRUNTIME/ftplugin/sql.vim is loaded
let g:omni_sql_default_compl_type = 'syntax'

However, neither of these workarounds is adequately documented.

The documentation only mentions that let g:omni_sql_no_default_maps = 1 disables the default mappings. It does not explain the relationship between these mappings and omnifunc, making it difficult for users to understand why their custom omnifunc configuration is being overridden.

Finally, I apologize for raising this runtime-related issue here on GitHub.

I checked the MAINTAINERS file beforehand, but could not find any maintainer information for the relevant files.

I then tried contacting David Fishburn (dfishb...@gmail.com), whose name appears in the headers of these files, directly via email. However, I have not received a response after a week.

I am not sure whether David Fishburn is still maintaining these files. If he is no longer responsible for them, it would be helpful to identify the correct contact person in the relevant files.

Finally, English is not my first language, and I used AI to help translate this issue. Please excuse any awkward or inappropriate wording.

Version of Vim

9.2.1046

Environment

System:
Kernel: 7.0.14-arch1-1 arch: x86_64 bits: 64
Console: pty pts/2 Distro: Arch Linux
Term: xterm-256color
Shell: GNU bash, version 5.3.20(1)-release (x86_64-pc-linux-gnu)

Logs and stack traces




—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/21421@github.com>




Guillaume CANAT
unread,
Oct 1, 2026, 6:33:28 PM (3 days ago) Oct 1
to vim/vim, Subscribed
gcanat left a comment (vim/vim#21421)


Guess we missed a spot the previous time.

This should solve it no ?


diff --git a/runtime/ftplugin/sql.vim b/runtime/ftplugin/sql.vim
index 3b56acd67..12a46473e 100644
--- a/runtime/ftplugin/sql.vim
+++ b/runtime/ftplugin/sql.vim
@@ -482,7 +482,7 @@ exec 'xnoremap <silent><buffer> [" :<C-U>exec "normal! gv"<Bar>call search('."'"
 setlocal comments=s1:/*,mb:*,ex:*/,:--,://
 
 " Set completion with CTRL-X CTRL-O to autoloaded function.
-if exists('&omnifunc')
+if exists('&omnifunc') && exists('g:loaded_dbext')
     " Since the SQL completion plugin can be used in conjunction
     " with other completion filetypes it must record the previous
     " OMNI function prior to setting up the SQL OMNI function



—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/21421/5942000511@github.com>




chenrenfei-ymsl
unread,
Oct 1, 2026, 8:50:15 PM (3 days ago) Oct 1
to vim/vim, Subscribed
chenrenfei-ymsl left a comment (vim/vim#21421)




Guess we missed a spot the previous time. This should solve it no ?


diff --git a/runtime/ftplugin/sql.vim b/runtime/ftplugin/sql.vim

index 3b56acd67..12a46473e 100644

--- a/runtime/ftplugin/sql.vim

+++ b/runtime/ftplugin/sql.vim

@@ -482,7 +482,7 @@ exec 'xnoremap  [" :exec "normal! gv"call search('."'"

setlocal comments=s1:/,mb:,ex:*/,:--,://


" Set completion with CTRL-X CTRL-O to autoloaded function.

-if exists('&omnifunc')

+if exists('&omnifunc') && exists('g:loaded_dbext')

" Since the SQL completion plugin can be used in conjunction

" with other completion filetypes it must record the previous

" OMNI function prior to setting up the SQL OMNI function






This should fix the issue, but it would also cause some default mappings that do not depend on dbext to be skipped. Although this appears harmless, it would still introduce changes to the default behavior.


A fix that minimizes changes to the default behavior might look like this. It still does not address the issue where a user-defined omnifunc is overridden after pressing the default key binding, but at least it would make completion work out of the box.


diff --git a/runtime/autoload/sqlcomplete.vim b/runtime/autoload/sqlcomplete.vim
index 4017ae9b0..30fba3e5c 100644
--- a/runtime/autoload/sqlcomplete.vim
+++ b/runtime/autoload/sqlcomplete.vim
@@ -175,7 +175,11 @@ if !exists('g:omni_sql_include_owner')
 endif
 " Default type of completion used when <C-X><C-O> is pressed
 if !exists('g:omni_sql_default_compl_type')
-    let g:omni_sql_default_compl_type = 'table'
+    if exists('g:loaded_dbext')
+        let g:omni_sql_default_compl_type = 'table'
+    else
+        let g:omni_sql_default_compl_type = 'syntax'
+    endif
 endif
 
 " This function is used for the 'omnifunc' option.




That said, personally, I do not think the default mappings are particularly sensible in the first place, so I am sympathetic to your simpler and more effective fix.



—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/21421/5943486777@github.com>




kinemato
unread,
Oct 1, 2026, 8:52:51 PM (3 days ago) Oct 1
to vim/vim, Subscribed
kinemato left a comment (vim/vim#21421)




Guess we missed a spot the previous time. This should solve it no ?

...






This should fix the issue, but it would also cause some default mappings that do not depend on dbext to be skipped. Although this appears harmless, it would still introduce changes to the default behavior.


A fix that minimizes changes to the default behavior might look like this. It still does not address the issue where a user-defined omnifunc is overridden after pressing the default key binding, but at least it would make completion work out of the box.


diff --git a/runtime/autoload/sqlcomplete.vim b/runtime/autoload/sqlcomplete.vim
index 4017ae9b0..30fba3e5c 100644
--- a/runtime/autoload/sqlcomplete.vim
+++ b/runtime/autoload/sqlcomplete.vim
@@ -175,7 +175,11 @@ if !exists('g:omni_sql_include_owner')
 endif
 " Default type of completion used when <C-X><C-O> is pressed
 if !exists('g:omni_sql_default_compl_type')
-    let g:omni_sql_default_compl_type = 'table'
+    if exists('g:loaded_dbext')
+        let g:omni_sql_default_compl_type = 'table'
+    else
+        let g:omni_sql_default_compl_type = 'syntax'
+    endif
 endif
 
 " This function is used for the 'omnifunc' option.




That said, personally, I do not think the default mappings are particularly sensible in the first place, so I am sympathetic to your simpler and more effective fix.



—

Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/21421/5943512392@github.com>




Reply all
Reply to author
Forward
0 new messages