You should try walk_towards() (or even better, step_towards()). walk_to() trying to walk to the spot but it's not going to bump into it. It'll just keep trying until it can land on the same location as the target.
walk_towards() however will just go towards the target (reguardless of whether it can or can not land successfully on the target's location).

Also, here's a better version of your Move().



The first change is atom/A. The proc no longer uses it and you can remove it safely, however you've got to remember that A) the value of Move()'s first argument can be any sort of atom, not just a turf, and B) just because you create the variable to hold a turf (or any other path) doesn't mean it will be set to one.
In your original version a could have been anything, and although it wouldn't cause a problem it could later on if you expand on it.
You should go into your Bump() proc and do the same (with a check to see if it's a mob before you try and check it's client), because it could be an obj in that case as well (so you should set it to /atom/movable).

The most notible change is the adition of . This is what the proc will return if you exit without a return. It works just like a normal var and is important, because Move() returns a value and some things rely on it returning 1 when you move.

The next addition is if(.). This is just seeing if you successfully moved, and if not returning. I'm not sure why you want to stop before it gets to the for(), but you've probably got your reason.

Now for probably the most important change. I put src in the viewers() proc. This would have left you with errors that make you want to tear your hair out.
By default, procs like view(), range(), input and alert() usr as their referance (or target).
You'll probably find it works like a dream, provided the /mob/evil is within viewers(5) of the usr. So you've never seen it mess up.



Heh, I bet you didn't expect such a long reply. =P