i would like to take a look at your isolated movement part of the code if possible.
what my suggestion is if is not possible to be shared, is that you could try instead of using X or Y as prerequisite for line of sight and instead use movement direction +distance from where it should stop.
for example if enemy is moving only in a foward type of patern or clockwise lets say in a square or round pattern, u can say that is "front_movement" if he moves any other direction then is not forward... with that logic in mind, adding additionally a distance to stop from objective point reached.
so enemy is moving_forward
and
distance(enemy.x,enemy.y, player.x,player.y) less or equal with 32 pixels lets say don't know ur grid size but lets assume u have a 32 by 32 grid movement block that means he is on a block adjacent to another meaning he needs to stop at a 32 pixels distance from players XY.
hope it makes sense to you and helps you achieve a new solution.
if it doesn't i could demonstrate it to you on ur tilebased movement i guess.
also the movement should be general for all enemys, not just 1 type of mob... with little tweaks for type of mobs of course but the core movement system should be the same for all enemy (ex distance+movement forward has to be basic rules, what is considered additional ruling based on class is up to you to decide being it speed movement, waiting time etc), otherwise you will cause long run development conflicts.
Try refresh the page using shift+f5 or ctrl+f5 to force clear the website memory cache... i tend to edit a lot of times my posts.
Edit ~5: the problem i see with using x enemy = player x or y is that the enemy if is a large patch of grid movements, then the enemy can be at 10-20 grid spaces distance but on same X or Y and that would might be true for the logic of the system, but it would look glitchy as hell, as won't be near the player at all.