Hello
On Fri, Sep 19, 2014 at 02:45:37PM +0200, Hugues Evrard wrote:
> === 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
I have spent quite some time thinking about this syntax object problem,
and I think it is mostly attainable with a layered approach:
Most language syntax objects are easy to express in term to generic text
objects:
- A C function is a { } block preceded by a parenthesis block and a few words
whose last is not a control flow keyword
- A python function is an indent block preceded by a parenthesis block
preceded
by a word and 'def'
- A lisp function is a parenthesis block whose first word is defun
That wont be 100% correct, but good enough for most use case.
Based on this, I think that with an expressive enough editing language you
can easily define that from basic builtin blocks.
That was one of the motivations for swapping selection and operation order in
Kakoune (haters gonna hate...), by decoupling selections from the operator, you
can express arbitrarily complex selection operations, you have a (rather
limited)
version of that with vim visual mode.
Once you have that, you can provide the upper level operations by defining them
by language in term of basic operations.
The advantages (IMHO) of defining higher level constructs like that are the
following:
- It keeps the language specific ones out of the core
- It force for an expressive set of general purpose core commands
The hard part being finding that expressive set of core commands.
The problem with parsers is that besides being quite slow if data driven, they
are not very good at analysing invalid code, which is the most common state of
code being edited.
Cheers,
Maxime Coste.
