Can't delete function call using `dsf`.

[tmalsburg]

Since it's possible to wrap a text object in a function call with, e.g., yssf, I would expect dsf to delete that function call. Seems like a very useful feature.

[tmalsburg]

Similarly, it's not possible to change a function call to something else using csf.

[HalimNaim]

I have pushed a first attempt at removing a function. It will not change it though. The problem with deleting functions, is that it will try to get an outer and inner overlay from evil using f as the char argument, for which evil has not text-objects. I added a test case in the cond for ?f And implemented a function that will delete it. It will cause problems if called outside the parens of the function call however. I don't know if I should limit it to a single line or not. commit

[HalimNaim]

I've re-written evil-surround-delete-function, so it uses evil procedures. I have tested and it works pretty well. I have commited it to my test branch. Please review and test it. And let me know if you find anything wrong with it.

[tmalsburg]

Thanks for working on this! I'm testing it right now. It works in Python and R scripts but for some reason not in the scratch buffer. There it is doing weird things, deleting wrong characters. As you say, it only works correctly when the cursor is in the parenthesis. Perhaps, you could change it to do nothing at all when the cursor is outside? That would be much better than the erratic behaviour that we get with the current code when the point is outside.

Here is an interesting case:

funB(funA((arg))

When you place the cursor on arg and enter dsf it deletes funA. It would be extremely usefule if it was also possible to delete funB instead of funA. (If I delete a function, it's most of the time the most outer function.) Would it be possible to reuse (or rather abuse) Vim's inner and outer semantics for that? I'm thinking of using dsif for deleting funA and dsaf for deleting funB.

[HalimNaim]

You mean emacs' scratch buffer? Thats wierd. Do you have a test case? It should do nothing when it is outside. I'm relying on '[ (' Which doesn't move unless it's inside the function. In the test case you post, you have unbalanced parens. I don't know how to handle that case. If the parens where balanced, you could delete funB, by placing point on any of 'funA('.

[tmalsburg]

Sorry, there was a typo in the test case. What I meant was of course this:

funB(funA(arg))

I can't reproduce the erratic behaviour in the scratch buffer, so forget that. However, when I place the cursor on "u" in the following example

funA(arg)

and enter dsf, it deletes "fun" and the final ")" and leaves me with:

A(arg

This happens in the scratch buffer and in other buffers as well.

[HalimNaim]

Are you sure you are using the version in my test branch? I'm not getting the behavior you describe. If I place the point anywhere in funA( I get funB(arg) And if I have funA(arg) placing point in arg) gets me just arg

[tmalsburg]

I'm using ac3017c from the test branch. I think I found the problem: in line 171, you assume that evil-previous-open-paren returns nil when there is no opening parenthesis but that's not the case. At least in my setup (current development Emacs, current Evil from MELPA), I get -1 if there is no opening parenthesis. So the body of the when clause is always executed, irrespective of whether there is an opening parenthesis or not.

[HalimNaim]

Thats strange.

(evil-define-motion evil-previous-open-paren (count)
   "Go to [count] previous unmatched '('."
   :type exclusive
   (let ((range (save-excursion
                        (backward-char)
                        (evil-paren-range count nil nil nil ?\( ?\)))))
       (when range
            (goto-char (evil-range-beginning range)))))

Here is the code of the function. If range is nil, when should return nil. And that should be the return value of the procedure in that case. The debugger confirms that. I have Emacs 24.3.1 M-x evil-version returns 1.0-dev.

[tmalsburg]

On my system, I have this definition:

(evil-define-motion evil-previous-open-paren (count)
  "Go to [count] previous unmatched '('."
  :type exclusive
  (evil-up-paren ?( ?) (- (or count 1))))

This is also the version in the current development version of Evil. Git blame says that this function was changed in January by Frank Fischer. See here.

[HalimNaim]

Oops. I have pulled evil master. And updated the function to test for -1 first, then thought it would be better to test for 0. So I made another commit to fix that. Should work now.

[tmalsburg]

Works, nice. The question is whether we can rely on the return value of evil-previous-open-paren. The documentation doesn't specify return values and future changes may therefore break your code. A safer way to test for an opening parenthesis would be to test:

(= (point) (save-excursion (evil-previous-open-paren) (point)))

[HalimNaim]

Good Idea. Done!. Just changed save-excursion with progn becuase I need point to be at the paren.

[tmalsburg]

Ah, right.