Hi all,
On 09/17/14 22:12, ale rimoldi wrote:
>
>> Could some vim expert on the list tell me whether it is possible to
>> indent the next n lines by m levels in vim?
>
> the simplest one already works in vis. indent n lines (or better a
> "{" inner area) and repeat the action with dots (eventually correcting
> the exceeding indenting with u).
> this is in my experience faster than wondering which of n or m comes
> before the > and which after.
Disclaimer: What follows is just my point of view, and definitely *not*
a feature request!
I would like to raise a point on the level of abstraction a text editor
offers, when editing code in particular.
1. The basic editing commands are really *text* oriented, and they do
not depend on what kind of text your are editing: go to a position in
the file, insert a character, find a sequence of characters, and the like.
2. Other commands begin to be on a higher level, and introduce concepts
that may depend on the nature of the text, e.g. "erase a word":
- how a word is defined ? sequence of characters between "whitespace?
(e.g. in japanese there is no whitespace between words)
- how do you define: newline, line, whitespace, paragraph, word
separators? (e.g. is underscore a word separator?)
I guess most editors have a common ground on such definitions, and/or
offers a way to define them. For instance in AWK one can redefine the
"field separator" (FS) to control how a line is split.
3. When you edit code, you work on structured text with code-related
abstractions: the code may contain comments, function definitions, etc.
The editor may know about this to alter the editing interface, the most
prominent example being syntax highlighting. Such information may also
be useful for editing commands, as you can use new abstractions such as
"comments", "function", "block" in the editing commands.
My point is that some of these abstractions can be defined independently
of the programming language code under edition. For instance, a comment
is a comment, be it in C, Shell Script or LaTeX sources, each with their
particular comment syntax. I think using such programming-language
agnostic abstractions is useful to define uniform editing commands.
Let me give an example:
- we want to comment a block of code
- we edit C-like code, i.e.:
- let's say a block of code is defined by text between the next "{"
and its matching "}"
- comment means add "//" at the beginning of the line
To realize this on "level 2" commands, we may use these commands:
- select text between "{" and next "}"
- add "//" at the beginning of all lines of text selection
(and I feel this is how most vi users work, but I might be wrong)
To realize this on "level 3" commands, we may use these commands:
- select "block of code"
- comment current selection
==> Level 3 commands do not depend on the actual syntax ("{", "//"
characters), but on code abstractions.
==> We can use *the very same commands* for LaTeX sources for instance,
where "{" would be "\begin", "}" would be "\end" and "//" would be "%".
However, such abstractions require the editor to know the structure of
language being edited. If this means having a parser for each language
under edition, then I think it's better to not have such abstractions.
Still, the information needed for syntax highlighting may be enough to
offer some basic abstractions, which may be obtained using regexp (maybe
regexps are already too heavy?):
- comments
- block of codes
- beginning and end of function definitions
- text between two matching "parenthesis" (same abstraction for
"(...)", "[...]", "{...}", etc)
=== TL;DR ===
- editing command could use abstractions that are independent from the
actual source code syntax
- e.g., say "comment this line" rather than "add <comment chars> at the
beginning of the line"
- pro: offer uniform commands to edit different prog languages.
- cons: requires knowledge of the prog language that is being edited
PS: first real post for me, I happily read the list since months!
--
Hugues Evrard
