That's true, and it is arguable that Lisp could be improved by making macro invocations have a distinguished syntax.
But in practice it's usually pretty clear what is a macro and what is a function because of naming conventions, and because macros commonly admit syntax that would be illegal in a function call e.g. (let ((x 1)) ...) But however bad this problem is in Lisp, it's much worse in Forth.
> Forth doesn't really have functions
That is debatable. If I write 1 2 + 3 * then I think of the + and the * as function invocations that take their arguments off the stack and leave their results on the stack. It's true that this is not exactly the same as a function call in Lisp, but it's similar. In any case, if I write:
a b c d e f g h i j
there is absolutely no way to tell what that is going to do without knowing what every letter means. By way of contrast, if I write:
(a (b c d) (e f) (g h (i j)))
then it's a pretty good bet that a is a function that takes three arguments, b and g are functions that takes two arguments, e and i are functions that take one argument, and c d f h and j are variables.
That's what I mean by Forth words not really being functions, they're subroutines for sure, and you can do some surprisingly powerful metaprogramming given that what you have is a glorified linked list, something a little more powerful than GOSUB, and two stacks, but functions?
When you compare it with a visually similar concatenative language like Factor or Joy, which inarguably have functions, Forth words look pretty different.
a b c d e f g h i j
(a (b c d) (e f) (g h (i j)))
To be fair, this is true of Common Lisp as well, macros aren't functions.
Forth doesn't really have functions, it has words, they're broadly useful like functions but are a differently-literal sort of memory object from a lisp function defined with cons cells.
So you can't know where the function calls are, there is no such animal, but you do know where the word boundaries are, it's the whitespace, and in Forth that's what you care about.