Ticket #9 (closed defect: fixed)

Opened 6 years ago

Last modified 6 years ago

don't change completopt settings

Reported by: sol Owned by: claus
Priority: major Milestone:
Component: --- Version:
Keywords: Cc:

Description

When there is only one math in CTRL-X mode, CTRL-E wont revert the completion.

Change History

follow-up: ↓ 2   Changed 6 years ago by sol

I guess this is due to

:completeopt=menu,menuone,longest

Maybe it is just a good idea to not set &completeopt at all. Users may have settings, that they are used to.

in reply to: ↑ 1 ; follow-up: ↓ 3   Changed 6 years ago by claus

Replying to sol:

I guess this is due to :completeopt=menu,menuone,longest

Indeed. :set completeopt-=longest undoes. I don't see this effect documented, though, nor does longest seem to do what it says. Curious.

Maybe it is just a good idea to not set &completeopt at all. Users may have settings, that they are used to.

That is a good point. It should have been setlocal anyway.

Unfortunately, without at least menu in there, the behaviour tends to be confusing, as one cannot see the alternatives, only a count, and less experienced users will not search for the option, while experienced users who don't like the setting can change it easily (and automatically, using Vim's after-directorys).

Unless I can figure out the odd behaviour of longest, I'm tempted to switch to setlocal completeopt=menu,menuone. Ideally, I could check whether the user has set the option, and leave it alone then, but I don't know how to do that in this case (the setting alone doesn't tell me where it came from).

in reply to: ↑ 2   Changed 6 years ago by sol

Maybe it is just a good idea to not set &completeopt at all. Users may have settings, that they are used to.

Unfortunately, without at least menu in there, the behaviour tends to be confusing

The default value of 'completeopt' is "menu,preview". Do you think that would work?

less experienced users will not search for the option, while experienced users who don't like the setting can change it easily (and automatically, using Vim's after-directorys).

In respect to 'completeopt', I was a less "experienced user" and I was completely happy with the default value of 'completeopt', so I never cared to learn about it. It was only due to the "haskellmode-vim does something, that I do not want it to do" feeling, that I finally figured out what the actual reason of that behavior was. At first, I thought it is some annoying bug in "haskellmode-vim";)

Unless I can figure out the odd behaviour of longest, I'm tempted to switch to setlocal completeopt=menu,menuone.

Maybe we just suggest this in the documentation. My assumption is, that people tend to use the same settings for say Haskell and C. This is at least what I prefer. Effective editing is all about consistency, right?

  Changed 6 years ago by claus

  • status changed from new to closed
  • resolution set to fixed
  • summary changed from CTRL-E does not work as expected in CTRL-X mode (:help ins-completion) to don't change completopt settings

Okay, I've never been in favour of changing user-preferences without need, and the current default seems to do. longest doesn't seem to work anyway atm. So I've made that change (no setting of completeopt).

Glad to hear that you learned more about Vim by using haskellmode-vim!-)

I still recommend adding menuone, so that one can check before anything happens. This is more relevant for other menus, where some users have also asked for a way to avoid singleton menus (only implemented for _?, so far). I'll try to make those menus follow the presence/absence of menuone in completeopt, for consistency.

Note: See TracTickets for help on using tickets.