Re: [el-search] How to search string excluding docstring?

[Emanuel Berg <moasen@zoho.com>]

YT wrote:

>>> Is this really what you mean? Surly that
>>> isn't implemented as mere regexps?!
>>
>> I'd be very surprised if it were.
>
> So why did you bring it up to begin with?

OK, so now I understand how regexps entered
this discussion! "You can't use grep with
regexps", because it isn't a Lisp parser so it
can't answer the kind of questions that require
you to crunch it down token by token!"

And that's true! Regexps are sometimes
underestimated. Because they cannot do
everything, it doesn't mean they cannot do
a lot, still. But it will never be a perfect
fallout and the result may also be confusing as
semantically the same Lisp, and the same
regexp, can still yield different results.

So you can use grep to search your Elisp, but
not to query your Elisp and expect 100%
consistent/correct/complete answers. If this is
the goal, even to use font lock, which probably
itself uses some half baked method to find out,
to use font lock would be a clever hack
at best.

The reason you can still use grep or font lock
or any other such method is that in the world
of editing code, these are just tools to do
things. An imperfect tool can still help you do
things. And a perfect tool, which is 100 times
more advanced than the imperfect tool, will not
be 100 times more helpful to you.

If we then switch worlds from the
practical/editing to the abstract/theoretical,
to parse the code, or eval it like Lisp does,
this is already capable of telling if something
is a docstring or not. Just do C-h
f forward-char RET !

However here there is a collision between the
two worlds. Because where is point?
Over which element to begin with, when the
query is executed? If one knows that, one could
simply get the defun as a list (which it
already is) and ask, "is the 4th element
a string?". If it is, and if point's at it in
the buffer, then yes it is a docstring.

-- 
underground experts united
http://user.it.uu.se/~embe8573