There is a deliberate reason why I made this change. This change allows omni-completion to be disabled independent of auto-completion. Previously, when auto-completion is disabled, omni-completion is enabled by default. There are use cases where a user needs to disable both auto-completion and omni-completion globally. With your change, these features cannot be independently enabled or disabled.

Can you describe what is the problem that you are facing with omni-completion?

you changed this several times, last time before latest one you modified it
to if auto-complete disabled then omnicompl enabled, the latest change you
recovered it to independent auto-complete and omnicompl which both can be
enabled, and added a vim session level omnicomplete option.

The changes I made didn't change the default behavior. The behavior previously
was:

1. Auto completion is enabled by default and omni-complete is not enabled.
2. If the autocomplete option is set to false, then omni-complete is enabled.
3. If autocomplete is set to false and the per-server omnicompl flag is
   set to false, then omni-completion is disabled for that server.

My changes added another option to enable or disable omni-completion.
If this broke something else, let me know.

now this/my
change kept it and same like the original design, but get default from vim
session level omnicomplete option too, however your latest change make that
default 'false' which server level omnicompl maybe false, which changed the
consistent default behavior, this change/my pr just to fix that to keept it
really default true, unless user changed vim session level omnicomplete
option value, and didnot change omnicompl for that server.

Currently to change the autocomplete and omnicomplete option values, the
Vim instance need to be restarted. This makes it difficult to test these
options. I am working on changes to dynamically enable or disable these
options. To support this, the default option value should be set to
null and not true. So we can detect whether the user specified the
option value or the default value is used.

r.i.p bram.

I can confirm the fact that omnicomplekion is broken for me in master branch (#380), this branch works like a charm tho.

What is the status of this ?
I find it kind of frustrating n 8000 ot being able to make omnicompletion work :O

What is the status of this ? I find it kind of frustrating not being able to make omnicompletion work :O

I will look into this over this weekend.

it actually didnot bother me, but how about just merging it? 😄
// your previous modification i felt perhaps was a bit too tricky,
// a.k.a making life easy, and your modification worked may on situation, but mine seems solid.

I'm not convinced this patch is actually necessary. AFAIK, the current version is behaving as the documentation says:

• If the server specifies omnicompl, that is used
• If the global config does, that is used.
• Otherwise, the value is !cfg.autoComplete

I struggled with issue #380 earlier tonight, and the actual problem (for both me and the OP of that issue) seems to be that LspAddServer was called before LspOptionSet, which prevents the value of cfg.omniComplete from being used (since LspAddServer is the function that inspects it).

this PR was to make it easy, tho not have to.
// and #475 (comment)