On Wed, Mar 02, 2016 at 03:17:49PM +0100, Marc André Tanner wrote:
> On Wed, Mar 02, 2016 at 10:40:51AM +0000, Maxime Coste wrote:
> > On Wed, Mar 02, 2016 at 10:14:48AM +0000, Raphaël Proust wrote:
> > > On 1 March 2016 at 17:12, Marc André Tanner <mat_AT_brain-dump.org> wrote:
> > > > I think structural regexp will integrate nicely with multiple selections.
> > > >
> > > > […]
> > >
> > > Yes! Interactive structural regexp would definitely be a Killer
> > > Feature™ IMO. I would probably use an editor like that almost
> > > exclusively.
> >
> > That has been provided by Kakoune for a looong time, you get structural
> > regex interactively as you can subselect matches in current selections,
> > keep only selections matching/not matching a regex, and push/pop a set
> > of selections.
>
> But (as far as I know) you don't get a consistent command language.
> In this case Kakoune is in a way too interactive.
Thats true, although I'd say its not the consistency of the language but its
minimalism what was lost to interactivity. With many shortcuts for very common
operations (<a-s> is basically s[^\n]+\n<ret>). I did try my best to stay
consistent.
> I want the possibility to store my most freqently used commands
> in a regular "favorites" file where they can be exexcuted from. I
> guess you could kind of hack something together with macros but that
> is not the same.
thats the whole point of the :exec <keys> command, which gets used for
auto indentation for example.
> Also something like sam's /X/ /x/ combination where you can modify
> multiple files is not possible.
You'd have to use :exec -buffer <list> <keys>, or a macro.
> > > On 1 March 2016 at 20:35, Marc André Tanner <mat_AT_brain-dump.org> wrote:
> > > > On Tue, Mar 01, 2016 at 05:41:00PM +0000, Connor Lane Smith wrote:
> > > >> On 1 March 2016 at 17:12, Marc André Tanner <mat_AT_brain-dump.org> wrote:
> > > >> > All commands of a group should operate on the original state of the text.
> > > >>
> > > >> Is that strictly necessary? I know that's how sam and acme behave, but
> > > >
> > > > I haven't yet made my mind up. It obviously changes the semantics of the
> > > > command language.
> > >
> > > Why not have both? A parallel grouping mechanism ({} to keep
> > > compatibility with sam) and a sequential one ([], or <>, or (), or
> > > whatever).
> >
> > That can be nicely implemented interactively by just providing a save/restore
> > selections mechanism.
>
> I don't think this is the case. Unless you mean you actually save
> the selection content not just their position.
Good point, it sort of work for the name swapping because the changed names
will get restored as a single char selection (as the previously selected range
disappeared). But yeah, thats not robust at all.
How does sam handles parallel grouping when we get multiple incompatible changes
to the same range of text ?
Regards,
Maxime.
Received on Wed Mar 02 2016 - 16:45:10 CET