[Lazarus] Auto indentation

[Hans-Peter Diettrich]

Martin schrieb:

>>> With the new synedit OnPaste event I will try to fix the indent on
>>> paste.
>>
>> IMO you should rethink the handling of insertion/deletion. A single 
>> Replace(start, delta, text) method can handle every case, with 
>> positive deltas meaning insertion and negative deltas meaning deletion 
>> or substitution of text. This single method knows about the range of 
>> the affected text, as required for the handling of all related 
>> attributes (line count, cursor position, syntax highlighting, blocks, 
>> folding, formatting, bookmarks...). All related objects should 
>> implement the same method for dealing with updates.
>>
> Maybe you can elaborate in which context you the above statement should 
> be interpreted?
> 
> We are talking here about specifically selected (and selected only) 
> events for which SynEdit is providing an interface for *external* 
> components.

And that interface IMO already is too bloated. What does any plug-in 
have to know about changes, other than the range affected?


> This is the same as a buttons OnClick, or OnFoo event that allows code 
> not known to the component to react to events occurring inside the 
> component.

In contrast to other components, changes to an text have only one single 
effect - parts of the text are changed. It's unimportant what caused 
that change (keyboard, clipboard, file load...).


> Inside the IDE OnPaste is going to be used by codetools, but in user 
> apps the programmer is free to use (and of course abuse) this on his/her 
> terms.
> Codetools does not need to know every edit/modification of the text. In 
> fact there are many edits/modifications that this part of codetool 
> should not react to.

It's up to every single tool to determine the impact of every modification.

> Clipboard interaction (for an editor component) is a generic event that 
> mat be of interest, in the same way as OnClick is on a button.

I see no need for special handling.


> Internally SynEdit has a small set of methods through which *all* 
> modifications to text are done.

Good.

> Agreed one would have been enough. But it is the same distinction  has 
> having 2 methods [cut and copy] or one [CutCopy(DeleteSelection:Boolean)].

That's a very different situation. Only Cut affects the text, no tool 
needs to know about a Copy.

> They do however not move the caret. This would have meant to add special 
> params.

The affected range is sufficient for the caret positioning management.

> After all not every text modification moves the caret.

Right, when the caret is outside the modified range :-)

> They do provide hooks, that are used by other editor feature to react to 
> the changes.

IMO a single hook would be sufficient. What does it make a difference, 
whether some text is deleted by DelChar, DelBlock, Cut or any other 
editing procedure?


> I am aware that you (IIRC) prefer a micro-controller scenario. But for 
> various features it is IMHO better to use generic hooks.
> Example: No micro controller is/should be needed to update bookmarks 
> (Except for the controlling element in the bookmark manager). The 
> bookmark manager hooks into synedit, observes any text change, and 
> adjusts all bookmarks.

That's my opinion as well - and it works with a single kind of notification.

> This is actually a pre-condition for having the same content in multiply 
> editor windows. Each SynEdit (using the same shared TextBuffer) can hook 
> into the textbuffer and adjust to any change that happens.

ACK.


>> A single Replace(start, delta, text) method 
> Can not deal (unless given a specialized argument) with the 
> differentiation between smNormal and smColum. smColumn is very specific 
> to Block-Selection and therefore translated there.
> the basic text modification only knows contineus/flowing text that can 
> be edited/replaced.
> 
> This again makes it a difference to an OnPaste event, which exposes the 
> speciality of smColumn. something that does not exist in other edit 
> actions.

Different how far? When a range of text is changed, it doesn't matter 
when some parts of it happen to stay unchanged. The *entire* range must 
be parsed again, tabs and bookmarks may need adjustment etc.

DoDi