Yeah, I guess that instead of saying it was a small bug, I should have
said that it's a bug of small consequence (for most users, but matters
to me, least).
The ambiguity problem you mention could be solved by matching more than
one line. To keep the string stored in the org link short,
org-store-link could expand it to another line only when needed for a
unique match. Or, it could expand just enough _words_ to ensure
uniqueness, plus maybe one word on each end for some insurance against
future changes.
Future changes are the harder part. In speech recognition, there's an
analogous problem where there's a need to match a transcript to
recognized speech, which may have a lot of word errors, insertions and
deletions. The simplest solution commonly employed is a word-level
Levenshtein distance:
http://en.wikipedia.org/wiki/Levenshtein_distance
(this is for chars, but you get the idea)
Scott
Carsten Dominik wrote:
Hi Scott, this is not a small bug, but a problem that is really hard
to solve.
Supposed I used the exact line text to search, then you still have two
lines in the buffer
that would match.
This is really about what strategy should be used to find a location
in a file that has possibly changed.
I have no good answer to that. Do you?
- Carsten
_______________________________________________
Emacs-orgmode mailing list
Remember: use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
