'cse' mapping should pre-populate with existing command ready to be edited

[krishnakumarg1984]

Presently the 'cse' (change surrounding environment) mapping presents a blank line to the user. I think, perhaps vimtex can go further and pre-populate the command-line with the existing environment ready to be edited by the user with the desired environment name.

Let me explain the rationale behind this.

In most cases, authors have a reasonable starting point of the environments they would like to use. It is extremely rare that a drastic change is to be effected, for example not many need to change a figure environment to table environment. In most cases, the user thinks of changing the environment typically after having written the content partially before realising that the environment was simply a bit inadequate, a classic example is tabular, when after writing part of the content, the user realises that one column needs to have an adaptable width and therefore need to do tabularx instead. So, it would be convenient if cse already populated the edit line with the existing environment name i.e. tabular and place the cursor at the end of the line, so that we can simply type x. There are a lot of such environments provided by many packages which are small modifiers. (I am not talking about the starred version at all, for which the tse mapping already exists).

Now, in the other extreme, let us say the user is typing a list of stuff, and decides that enumerate should be replaced with itemise instead. Here also, pre-populating the edit line with the existing environment is completely benign. The user would simply need to do Ctrl-U (built-in vim command) to clear until the start of the line, and begin typing the desired command.

In my 5 months of using vimtex for my Phd thesis, I realise that I am changing environments ever so slightly is the more common use-case than a complete switching of environments. It is so much inefficient to type in tabularx in entirety, given that most of the content was already there!

Hope you will consider this.

[lervag]

Thank you for the suggestion, but I'm sorry to say that I disagree. I often change e.g. equation to multline or similar. And if I need to change tabular to tabularx, it is not so often that typing it out is a problem.

Now, I could make an option, but I am reluctant because there are so many options. I therefore think I want to reject this suggestion.

[krishnakumarg1984]

Alright. No issues.

[andymass]

What if tab complete just put the existing environment name first? BTW, it's slightly strange to me that \[ is the first suggestion.

[lervag]

I moved \[ to the end and added current env to first candidate. I think this makes sense.

[kiryph]

When I had read this issue, I remembered that we had already a discussion on this matter:

I suggested this as a possibility to remove the ts mappings which add a delay to move before the next s. See point 4 in my comment https://github.com/lervag/vimtex/issues/933#issuecomment-320432623 in issue #933.

@lervag your response at that moment in time was actually more open than now:

I think your idea about letting cse and csc start with the current name inserted is interesting. I am inclined to think it would make the tse and tsc unnecessary. To make it easier for me to keep track of things, perhaps you could separate this as a feature request in a new issue? (https://github.com/lervag/vimtex/issues/933#issuecomment-320432623)

So there is the issue 😃.

My response to your interest was

I think this is a sensible thing to do. However, I am not sure whether everyone likes it.

Apparently, @clason does not like: he gave a 👎 . Well, to give you my opinion: I would definitely be open or more clearly positive. I would not consider typing <C-u> as cumbersome.

I see a few advantages

• deleting is faster than retyping of a common name (toggling star, tabularx/y, align/alignat, gather/gathered). Also ctrl-a works to prepend something likefl to align, x/xx to alignat in amsmath.
• I could actually disable the commands tsc and tse. I would still have tsd. I think I would consider using vim-sandwich for this.
• the prompt could become a one-liner: because it is obvious which environment is changed.

Of course, I also have quite often the situation where I have to clear the prompt because the new environment is completely different.

The tab-completion is nice. However, I was wondering about the line

let l:cands = [s:env_name] + l:cands + ['\[']

When I want to change center to something else, it is strange that \[ is a tab-completion option.

Could we add by default for a math environment all math environments (incl. amsmath environments if loaded)?

Also it would be nice when the wildmenu is already visible after pressing cse.

[kiryph]

Tab-Completion with Sensible Candidates

I actually could see the tab-completion menu filled with similar candidates:

• itemize, enumerate, description
• math environments: equation, eqnarray (however, eqnarray should not be used but amsmath; see l2tabu.pdf)
• tabular, tabularx, tabulary, ...
• ...

This could also apply to csc:

• font sizes
• section commands
• citation commands (biblatex, natbib)

Maybe @krishnakumarg1984 could suggest default completion candidates he encountered and motivated him to raise the issue here.

bootleq/vim-cycle

In this context I also want to point out the plugin https://github.com/bootleq/vim-cycle. It supports to cycle through word lists but also through pairs with <C-a> and <C-x>. This could possibly be used to change environments through predefined set of environments.

I have configured it for latex as following

call cycle#add_b_groups([
        \   [['tiny', 'scriptsize', 'footnotesize', 'small', 'normalsize', 'large', 'Large', 'LARGE', 'huge', 'Huge'], 'hard_case', 'match_case'],
        \   [['displaystyle', 'scriptstyle', 'scriptscriptstyle', 'textstyle']],
        \   [['part', 'chapter', 'section', 'subsection', 'subsubsection', 'paragraph', 'subparagraph']],
        \   [['article', 'report', 'book', 'letter', 'slides']],
        \   [['a4paper', 'a5paper', 'b5paper', 'executivepaper', 'legalpaper', 'letterpaper']],
        \   [['scrbook', 'scrreprt', 'scrartcl', 'scrlttr2']],
        \   [['oneside', 'twoside']],
        \   [['onecolumn', 'twocolumn']],
        \   [['draft', 'final']],
        \ ])

I have also configured it for math delimiters:

call cycle#add_b_groups([
        \   [['(:)',   '\left(:\right)',   '\mleft(:\mright)',   '\bigl(:\bigr)',   '\Bigl(:\Bigr)',   '\biggl(:\biggr)',   '\Biggl(:\Biggr)'],   'sub_pairs', 'hard_case', 'match_case'],
        \   [['[:]',   '\left[:\right]',   '\mleft[:\mright]',   '\bigl[:\bigr]',   '\Bigl[:\Bigr]',   '\biggl[:\biggr]',   '\Biggl[:\Biggr]'],   'sub_pairs', 'hard_case', 'match_case'],
        \   [['\{:\}', '\left\{:\right\}', '\mleft\{:\mright\}', '\bigl\{:\bigr\}', '\Bigl\{:\Bigr\}', '\biggl\{:\biggr\}', '\Biggl\{:\Biggr\}'], 'sub_pairs', 'hard_case', 'match_case'],
        \   [['\left|:\right|', '\mleft|:\mright|', '\bigl|:\bigr|', '\Bigl|:\Bigr|', '\biggl|:\biggr|', '\Biggl|:\Biggr|'], 'sub_pairs', 'hard_case', 'match_case'],
        \   [['\lvert:\rvert',   '\left\lvert:\right\rvert', '\mleft\lvert:\mright\rvert', '\bigl\lvert:\bigr\rvert', '\Bigl\lvert:\Bigr\rvert', '\biggl\lvert:\biggr\rvert', '\Biggl\lvert:\Biggr\rvert'], 'sub_pairs', 'hard_case', 'match_case'],
        \   [['\lVert:\rVert',   '\left\lVert:\right\rVert', '\mleft\lVert:\mright\rVert', '\bigl\lVert:\bigr\rVert', '\Bigl\lVert:\Bigr\rVert', '\biggl\lVert:\biggr\rVert', '\Biggl\lVert:\Biggr\rVert'], 'sub_pairs', 'hard_case', 'match_case'],
        \   [['\lfloor:\rfloor', '\left\lfloor:\right\rfloor', '\mleft\lfloor:\mright\rfloor', '\bigl\lfloor:\bigr\rfloor', '\Bigl\lfloor:\Bigr\rfloor', '\biggl\lfloor:\biggr\rfloor', '\Biggl\lfloor:\Biggr\rfloor'], 'sub_pairs', 'hard_case', 'match_case'],
        \   [['\lceil:\rceil',   '\left\lceil:\right\rceil', '\mleft\lceil:\mright\rceil', '\bigl\lceil:\bigr\rceil', '\Bigl\lceil:\Bigr\rceil', '\biggl\lceil:\biggr\rceil', '\Biggl\lceil:\Biggr\rceil'], 'sub_pairs', 'hard_case', 'match_case'],
        \   [['\langle:\rangle', '\left\langle:\right\rangle', '\mleft\langle:\mright\rangle', '\bigl\langle:\bigr\rangle', '\Bigl\langle:\Bigr\rangle', '\biggl\langle:\biggr\rangle', '\Biggl\langle:\Biggr\rangle'], 'sub_pairs', 'hard_case', 'match_case'],
        \   [['\left:\right', '\mleft:\mright', '\bigl:\bigr', '\Bigl:\Bigr', '\biggl:\biggr', '\Biggl:\Biggr'], 'sub_pairs', 'hard_case', 'match_case'],
        \   [['\big', '\Big', '\bigg', '\Bigg'], 'hard_case', 'match_case'],
        \ ])

[lervag]

@kiryph Thank you for your thoughts! I'm convinced to test how it works with prepopulating with the current env. However, I do think that making this smarter and more complicated is to overengineer this feature. I use cse a lot, and I find it very good the way it is. Making it "aware" of the current environment wrt. completion candidates would be nice, but it would also add a lot of (unnecessary, IMHO) complexity. That is, I don't think the gain is worth the pain.

[clason]

Just to comment on my thumbs: I agree with @lervag that the current versions of cse and tse is fine as is, and I would be very sad to see tse removed and folded into cse. I mainly need to do the following:

1. Toggle stars: here tse is three keystrokes, cse*<return> five, one of which (on my keyboard) involving a modifier. That's significantly less convenient.
2. Replace itemize by enumerate, equation by align, split by aligned etc. Here the proposed change would be one keystroke more, again involving a modifier.

So I personally have nothing to gain and quite a bit to lose from this proposal. (Of course, that's just one data point. Also, I learned from this that you can tab-complete the menu, which is useful to know!)

[lervag]

Ok, I've pushed an update now. This is a test, and I might revert it. In particular, I'm curious what @clason thinks, since he's, like me, skeptical in the first place. That is, do you find the updated cse to be a nuisance, or is it OK?

[clason]

Yes, I have to admit that (in my admittedly brief test now) I found it quite annoying. I tried to come up with a scenario where this would save me a single keystroke, and couldn't come up with any.

(In particular when considering that with se wildmode=full -- the default -- the current environment is now only a single (modifier-free!) keystroke away...)

[lervag]

Thanks, @clason.

Well, @kiryph @krishnakumarg1984: Is this important enough that we should add an option?

[krishnakumarg1984]

@lervag thank you trialling this feature. I just tested it and it works as expected satisfying the issue raised originally.

From the discussion here, I can clearly see that some users find the change too intrusive, so making it the default behavior might surprise many and is therefore, may not be a good idea.

In my opinion, for effecting a larger change to the surrounding environment's name, using the Ctrl-U modifier is not such a big issue. This is because

• This is a vim built-in requiring no plugins and therefore will work on every machine identically
• Using modifier keys at vim's command-line is a natural way to use it. Vim's built-in documentation on the command-mode extensively recommends the use of modifier keys.
• If the environment to be changed to is a longer form of the current environment (as is the case with many latex packages), the tab-completion gets cleverer and the first candidate usually is the desired one!

For this feature, if the user-base is polarised in the middle, I do not see any harm in providing a user-settable option (with the default turned off, i.e. without pre-population). In that case, do you expect that if a user turns the feature on, it shall affect vimtex's responsiveness in any way? I looked at your commit and it seems only like a couple of lines of code. Ultimately @lervag , it is your call :)

[clason]

@krishnakumarg1984 By the same argument, using <tab> to fill in the old environment is not such a big issue. (The second bullet point is true but beside the point, and your third point has no basis in fact.)

Of course, if the behavior can be configured, that's a different matter.

[krishnakumarg1984]

@clason No issues. I think all that lervag is interested is on feedback about whether this is important enough to make it a user-configurable option. I just offered my 2 cents, that's all.

[lervag]

Yes, thank you, @krishnakumarg1984, that's exactly what I want feedback on. I think there are a lot of options, and so I am trying to avoid adding more options unless they are called for.

If I added an option, what would be a good name for it? Perhaps g:vimtex_env_change_autofill? E.g.:

*g:vimtex_env_change_autofill*
  Whether or not to autofill the input for |<plug>(vimtex-env-change)| and
  |<plug>(vimtex-env-change-math)|. If enabled, the current environment value
  is used as a default input, which some people may find useful in order to
  quickly change from things like `align` to `aligned`.

  Default: 0

[kiryph]

My 2 cents:

1. Option for filling or not filling the prompt of cse/csc
   IMHO pressing <c-u> to clear or <tab> to fill the prompt should be acceptable for both sides. Hence, this option seems unnecessary. However, it should be documented that <tab> can be used at the prompt of cse/csc. Afaik, this is not the case yet.
2. Importance of tse/tsc
   IMHO toggling the star of an environment/command is not done very often in the lifetime of a manuscript, in contrast, e.g., to commenting or changing the delimiter type with tsd. Also, if I know that an equation is intended to be unnumbered, I usually create the math environment already with a *. I suppose @clason creates environments in general without a star and adds it if needed with tse. Maybe someone can point out an environment where the star is toggled more often than once?
3. Tab-completion for cse/csc with candidates from the current project
   IMHO the tab-completion as it stands appears a little bit unpredictable. The reason for this is that candidates must already exist in the current document (except for \[). However, it is great that the candidates are drawn not only from the current file but also from other files of a multi-file latex manuscript. This actually makes tab-completion quite useful as it is for a manuscript which has reached a certain progress. For a new manuscript tab-completion is less useful (except we go with an empty default prompt).
4. Tab-completion with configured candidates (latex-suite inspired)
   A pre-configured list of lists of environments to narrow down but also offer candidates would make it more predictable but also would remove candidates which some might find useful. I certainly understand being reluctant to add a new option. However, I think this list of lists would be a more useful option than adding one for filling or not filling the prompt. Since I discovered that candidates are drawn from the full project, I do not mind that this feature request is ignored.
   BTW, this feature request is similar to the latex-suite option g:Tex_PromptedEnvironments with the limitation of being a single list not a list of lists.

As always thank you @lervag for this great latex vim-plugin and everyone who takes the effort in contributing.

[clason]

@kiryph Just a cent to your two cents:

1. As I wrote, pressing <c-u> is not acceptable to me; if this is not an option, I will have to fork vimtex (which I'd rather not; @lervag is doing a too great job maintaining it). Others may feel differently, of course. (And <tab> completion at the wildmenu is a standard vim feature.)

2. Actually, it's the opposite: I create (math) environments in general without star and toggle it when I want to reference it. So I use tse very frequently (since I do change my mind over the course of writing).

3. Would it be possible to fill the list from the tab-completion list from the same source as the \begin{ omnicomplete? Also, the \[ is indeed a bit odd since you can cse, e.g., equation to \[ but not the other way around (cse doesn't work inside \[ \]).

[kiryph]

@clason

1. IMHO you are exaggerating the <c-u> matter. However, I do not want to upset or troll you on this. I think we are all interested in finding a solution which is acceptable for everyone. There should be no real reason to fork. It appears to me that you are used to it and prefer to keep it as it is. Understandable but as I said pressing <c-u> is in my opinion not a real efficiency killer. BTW: I have mapped capslock to ctrl. If you have not done this yet, I would suggest you to try this. This means almost no hand movement for <c-u>.

   The environments which I change more often are math environments which provide examples for both sides. Changing tabular or itemize happens not that often. Which environments do you change often where pressing <c-u> would slow you down and presumably disturb you in your writing zone? I think this would clarify your point of view.

   As a side note: I forked vim-unimpaired when tpope changed co to =o. I really hated the right hand movement of the pinky finger to = and then with another weak finger of the same hand to o. Now he switched to yo which I am fine with and requires minimal hand movement.

2. I am pretty confident about following in contradiction what you have written

   I create (math) environments in general without star and toggle it when I want to reference it.

   Math environments without a star have an equation number and can be referenced. If you do not want to reference it, you have to add the star, ie. toggle. This is the opposite of what you have written. Did you redefine math environments? I think in your workflow you should create them with stars and then if you want to reference it, you toggle i.e. remove the star. What I do not like about your workflow is: it would annoy me to move from somewhere else to the desired equation, toggle the star and then jump back. By default my equations get a number, just those which are obvious intermediate steps and only relevant for this paragraph do not. Of course there might be situations where this changes, but this is the exception. An intermediate step involves a previous equation and a subsequent equation(s). I agree that I end up with more equation numbers than necessary but an equation number also stresses for me the role of the equation. Also may I point you to following question: https://tex.stackexchange.com/questions/4728/how-do-i-number-equations-only-if-they-are-referred-to-in-the-text and the mentioned packages mathtools or autonum. IMHO they could really be helpful for your workflow. For general thoughts on equation numbering see https://tex.stackexchange.com/questions/29267/which-equations-should-be-numbered

3. Good point. This would be indeed a nice way to have many possible tab completion candidates regardless of whether they have already been used. And I totally agree with your \[comment.

[clason]

@kiryph The point is that presuming that a change does not disturb somebody else's workflow and even dismissing their explanations that it does as "exaggerated" is rather rude and tends to put people on the defensive. (And we're not talking about space bar heating here.) Please just take it for what it is: Anecdotal data that some really prefer the current setup and a plea to make the proposed change optional.

1. I have mapped capslock to <esc>, which I hit even more often. (I have short fingers, what can I say.)

2. That was a typo, I meant *with* star. And please don't tell me how to write mathematical texts; I've been doing that for more than 25 years. (I know autonum, but it's incompatible with cleveref, and of the two I'd rather have the latter.)

[krishnakumarg1984]

@clason All that we are talking about is adding a user-settable option. The default behaviour would be just like what you are used to. Therefore, you are not forced to use <C-u> at all ! What's the problem then?

@lervag the text you wrote for the user-configurable setting sounds perfect. The only minor nitpick shall be to consider changing "people" to "users".

[clason]

@krishnakumarg1984 If there's a user-settable option, no problem at all (and I don't care about the default). I just resent being told that my concerns are (or should be) of little consequence. Let's leave it at that.

[kiryph]

@clason

Sorry to have upset you. I am very sorry about this!

I do not want to get into a longer discussion as well. Only two points with no answer necessary.

• The documentation of autonum explicitly said that it is compatible with cleverref and this was one of the reasons why the package was written. I am sorry that I took this as it was true.

• How should I know that you have experience for 25 years on writing mathematics? I cannot claim this for myself. I am actually happy that someone with a much longer experience than vimtex existed shares interest in this plugin. I think this stresses the usefulnes of vimtex. I could have imagined that someone who has written for 25 years latex manuscripts would use emacs-auctex or vim-latex-suite. Anyhow, what I want to say is that I did not want to lecture you but only be helpful. Apparently, I wasn't. Too bad.

I simply hope you can accept my apology.

Also I will leave this conversation to avoid that this conversation looses track. I am anyway confident that lervag makes a sensible decision. BTW it sounded anyway like lervag shares your opinion. Since I learned that I can press <tab> to fill in the current environment, this is really not an issue for me.

[clason]

@kiryph Apologies (as far as they are even necessary) accepted; no hard feelings. Just to follow up:

1. autonum is mostly, but not fully, compatible; there are enough edge cases (e.g., with \qedhere) that made me abandon it after trying it for a while.

2. How should you know that I didn't? Never assume anything on the internet :wink: (That's why I try hard to formulate my comments such that they merely present my experience and not make statements about someone else.) For what it's worth, especially after so many years I'm happy to have found vimtex since it provides a lot of (for me) convenient support but is lightweight and doesn't get in my way (as vim-latex-suite and emacs-auctex do).

[lervag]

Thank you all for the good input! I appreciate that you are all constructive and that you keep it civil, even when the discussions build some heat. I find it a good sign of a healthy community. :)

So, I've now settled the autofill feature with an option and some updates to the docs. I think this makes sense, and I think it settles the issue with a good compromise.

It remains to settle on the completion candidates. Personally, I actually like to keep the candidates to the set of environments that I use in my manuscript, but I can see that this is not so useful in an early manuscript. I see three good alternatives here:

1. Keep it as it is.

2. Use same candidates as insert mode completion for \begin{... (based on a relatively large hardcoded, but package aware, list).

3. Some combination of these. E.g. use 2, but sort according to most used.

I'm tempted to go for solution 2 first, and then possible update with some minor modifications to make it even more useful.

[lervag]

By the way, I would prefer to continue the discussion on completion candidates in #1222. New comments here should keep the topic of pre-populating/autofilling. Thanks!

[kiryph]

@clason since you responded directly and I feel like it is good manner to respond 😃:

Apologies (as far as they are even necessary) accepted; no hard feelings.

This is great to hear. Often you simply do not know how the other person perceives a conversation on the internet. In person this is easier.

1. I never tried autonum. Getting your experience on this package was actually good despite that I do not intend to use it right now. I only use cleverref.