Nicolas Goaziou <m...@nicolasgoaziou.fr> writes: >> The problem, I think, is the regexp construction in org-link-search. >> This was introduced back in August of 2015 with commit >> cfe5bc97f8b18ccbf49d0764746c7563ce8d29da. >> >> The problematic line in org.el is 10951: >> >> (s-multi-re (mapconcat #'regexp-quote words "[ \t]+\\(?:\n[ \t]*\\)?")) >> >> The constructed regexp fails because it assumes a newline will be >> preceded by whitespace. But often newlines are not preceded by >> whitespace. >> >> Is there a reason the following won't work? >> >> (s-multi-re (mapconcat #'regexp-quote words "[ \t\r\n]+")) >> >> This was the method org-link-search used prior to the commit above. Are >> we trying to avoid matching across blank lines? > > Yes, we are. > > Fixed, hopefully.
Thanks Nicolas. Yes, it now works with multi-line searches that do not contain blank lines. I think there are some instances in which one might want to search across blank lines, such as when one captures a region that contains one or more blank lines. E.g., let's say org-context-in-file-links is t (the default). If one captures a section in org.el containing a blank line, org-link-search will fail to locate the section. Here's a sample link to try it out. (It assumes an org-mode repository at ~/org-mode). [[file:~/org-mode/lisp/org.el::(defsubst%20org-uniquify%20(list)%0A%20"Non-destructively%20remove%20duplicate%20elements%20from%20LIST."%0A%20(let%20((res%20(copy-sequence%20list)))%20(delete-dups%20res)))%0A%0A(defsubst%20org-get-at-bol%20(property)%0A%20"Get%20text%20property%20PROPERTY%20at%20the%20beginning%20of%20line."%0A%20(get-text-property%20(point-at-bol)%20property))%0A]] Thanks, Matt