Could commands and environments be made text objects?

[thomasahle]

If commands and environments were text objects, we could still have dsc/dse and csc/cse, but would also be able to do die/dae/dic/dac and likewise for changes.
Would this conflict with anything?

[lervag]

Environments are also text objects, so die and similar works already. And you are right, it seems a good idea to add commands as text objects as well. The question is how this should work, especially for commands that take several arguments. I guess:

ac should be the entire command, including (all) arguments

ic should be only the content of the arguments, perhaps from (but excluding) the first { and to (excluding) the last }

[thomasahle]

Ah right, sorry about the environments.

Your approach to multi-argument commands sounds like the right solution to me.

I guess [] arguments could be handled the same way.

[lervag]

Hmm. [] arguments make things difficult. That is, provided we have the following:

\includegraphics[width=\textwidth]{my_fig.png}

What do we expect if we do dic in this case? Perhaps the best option is to remove the arguments, both optional and mandatory? That is, we would get this:

\includegraphics

We have to have a very clear definition of the text object. It is difficult, because we don't know how many arguments a command takes. I think we have to make an assumption that a command looks like this:

\command[optarg]{arg1}{arg2}...{argn}

Where the arguments follow directly, with no spaces in between. The inner part would then match all arguments, whereas the outer part matches everything.

[Rmano]

Just to add a bit of brainstorming... arguments can be quite complex --- especially with the new LaTeX3 syntax; but even without this, there is the case of, for example

 \verb!One{verbatim}! 

(even with unmatched braces) or

  \newcommand{\mycommand}[3][defaultfor1]{blah blah blah}  

... I think it would be difficult just to safely identify which command is applied to the argument the cursor is on... ;-)

[lervag]

Yes. I think it is very difficult to parse the command. However, I see it might be relatively useful to have such a text object, even if it only works for "simple" commands. That is, I propose to add a simple text object for commands of the form

 \command[...]{arg}
%              ---   ic
%------------------  ac

For commands with no argument, I propose that ic matches nothing and ac matches everything.

This will work for many or perhaps even most cases, although not all. I.e., the text object will not work for:

1. Commands with more than one argument, such as \frac{...}{...}.
2. Verbatims, i.e. \verb|...|.
3. Other similarly complex commands, e.g. \newcommand.

[nomeata]

In general, there is no way to determine how many arguments a command has, and it just doesn’t fit TeX’s execution model. But here is an alternative:

Maybe a notion of tokens would be useful. So that if if I have

\cmd{arg1}{arg2}{arg3}

and my cursor is on m, then v3at would select the three tokens, where a token is something like \abc, or {...}, or a single character.

An it would then be abc or the ... of {...}, or simply the character in case of a single character.

[lervag]

Hi @nomeata, sorry for taking so long to come back to you on this!

I like your idea. I think you are right that the "command text object" does not really fit TeX's execution model. Just to be clear: You mean that in \cm|d{arg}, vit would select cmd, right? And you propose that a count will select additional and following tokens?

How aboue the command text object, do you guys agree with my proposal for a "simple" version? I think it would work for many/most commands, but obviously not all. It seems to me a pragmatic solution.

[nomeata]

You mean that in \cm|d{arg}, vit would select cmd, right? And you propose that a count will select additional and following tokens?

Correct. I would guess, though, the other form (at) would be more useful in general (e.g. dat to delete a command, or d2at do delete a command with one argument).

[lervag]

Ok, I've started to think about this again now. I want to implement parsing of commands that work like this:

1. First match the command name \\name
2. Optionally match the following [...]
3. Then match all succeding { ... }

This will match all of the following examples:

\test [ ... ] { a } { b }
\test
  [ asd ]
  { asd }
\test {a}
\test{b}
\emph{test} {\small ...}

The last example implies that the matching will sometimes be erroneous. However, I think this is relatively rare, and that it can be considered an acceptable fault.

With this, I can define the command text object and command mappings accordingly. What do you guys think?

[Rmano]

I think it could be nice. Especially to change command (like a \textbf to \emph or something similar). Great if it can be made so that . works... ;-)

[lervag]

I've added text objects ic and ac for commands. I think it should work pretty well. I'll also update the csc command so that it works more like expected.

Curious: csc is obvious, but what should be the behaviour for dsc.

[lervag]

I think the updates solves this issue. Feel free to reopen.