Which map is active when I overwrite text with R

[Titus von der Malsburg]

Thanks, Frank, for explaining.  This problem is more difficult than I
expected.  I thought of a quick a dirty hack (see below) but that
works only in the default case.  When I cycle through alternative
expansions it breaks as you pointed out.  Currently, I can only think
of relatively ugly solutions.  Hm ...

  Titus


(defun my-expand-replace-wrapper ()
  (interactive)
  (let ((pos (point)))
    (my-expand)
    (delete-region (point) (+ (point) (- (point) pos)))))


On Mon, Mar 12, 2012 at 10:33 AM, Frank Fischer
<frank.fischer at mathematik.tu-chemnitz.de> wrote:
> On Fri, Mar 09, 2012 at 04:11:29PM +0100, Titus von der Malsburg wrote:
>> On Fri, Mar 9, 2012 at 9:14 AM, Frank Fischer
>> <frank.fischer at mathematik.tu-chemnitz.de> wrote:
>> > On Wed, Mar 07, 2012 at 03:45:41PM +0100, Titus von der Malsburg wrote:
>> >> In insert mode, I bind TAB to a custom expand function that is based
>> >> on hippie-expand.
>
>> The thing is now that when I bind TAB to my expand function and hit
>> TAB in replace state it doesn't overwrite the existing text with the
>> expansion but inserts the expansion.  I think I would fix that by
>> binding TAB in replace state to a wrapper of my expand-function that
>> first determines the expansion, inserts it, and then deletes a string
>> that is as long as the expansion following the expansion.  While this
>> should work, I'm wondering: is there a better way to do this?
>> Specifically, I'm wondering if evil has a way to make the overwriting
>> transparent for the expansion function.
>
> Currently not. The problem is that the expansion function probably
> calls something like (insert ...) which does not obey whether
> overwrite-mode is enabled or not. The problem is that it's hard to
> judge whether command does real overwriting or plain insertion, so
> it's not clear what to do in all situations. Some commands like
> `dabbrev-expand' may only insert text (the first expansion) or remove
> and replace with other text (on successive invokations). This gets
> more interesting if the second candidate is shorter than the first
> one. Evil has already some magic to restore overwritten text when
> removing the newly inserted text with [backspace], so this problem may
> be solvable. Nevertheless I think there is at least no trivial
> solution for this problem that works in general.
>
> Frank
>
> _______________________________________________
> implementations-list mailing list
> implementations-list at lists.ourproject.org
> https://lists.ourproject.org/cgi-bin/mailman/listinfo/implementations-list



-- 
Titus von der Malsburg
DFG Research Group 868: Mind and Brain Dynamics
Dept. of Linguistics, University of Potsdam
http://www.ling.uni-potsdam.de/~malsburg/