Make title matching a bit smarter (#23)

Signed-off-by: Hofi <hofione@gmail.com>

Author: HofiOne

_plugins/generate_tooltips.rb

@@ -126,7 +126,7 @@ def process_markdown_parts(page, markdown)
 
               # Search for known link titles
               # NOTE: Using multi line matching here will not help either if the pattern itself is in the middle broken/spaned to multiple lines, so using whitespace replacements now inside the patter to handle this, see above!
-			  full_pattern = /(^|[\s.,;:&'"\-(])(#{pattern})([\s.,;:&'"\-)]|\z)(?![^<]*?<\/a>)/
+			  full_pattern = /(^|[\s.,;:&'"(])(#{pattern})([\s.,;:&'")]|\z)(?![^<]*?<\/a>)/
               markdown_part = process_markdown_part(page, markdown_part, page_links, full_pattern, id, url, needs_tooltip, true)
             else
               # Content inside of special Markdown blocks
@@ -232,7 +232,11 @@ def page_links_ids_sorted_by_title(page_links)
           end
         end
 
-        sorted_arr.sort_by { |page| page["title"].downcase }.reverse
+        # With this reversed length sort order we try to guarantie that
+        # the autolink/tooltip title pattern matching finds titles like
+        # 'Soft macros' before 'macros'
+        # In most of the cases matching the longer titles first will eliminate such issues
+        sorted_arr.sort_by { |page| page["title"].length }.reverse
       end
 
       def gen_page_link_data(links_dir, link_files_pattern)
@@ -287,16 +291,15 @@ def gen_page_link_data(links_dir, link_files_pattern)
             puts "Unknow ID (#{alias_id}) in alias definition"
             exit 4
           end
-          _, aliases = alias_data.first
-          page_link_data["title"] = aliases.concat(page_link_data["title"])
-          #puts "page_link_data: #{page_link_data}"
+          page_link_data["title"].concat(alias_data["aliases"])
+          # puts "page_link_data: #{page_link_data}"
         end
 
         # Just for debugging
         # pp page_links_dictionary
-        page_links_ids_sorted_by_title(page_links_dictionary).each do |data|
-          #puts data
-        end
+        # page_links_ids_sorted_by_title(page_links_dictionary).each do |data|
+        #   puts data
+        # end
 
         #pp page_links_dictionary
         return page_links_dictionary

doc/site-internal/lunr_search_help.md

@@ -13,15 +13,15 @@ Please visit the original Lunar site for more information.
 The simplest way to start is to pass the text on which you want to search into the search field:
 
 ``` javascript
-'foo'
+foo
 ```
 
 The above will return details of all documents that match the term “foo”. Although it looks like a string, the search method parses the string into a search query. This supports special syntax for defining more complex queries.
 
 Searches for multiple terms are also supported. If a document matches at least one of the search terms, it will show in the results. The search terms are combined with OR.
 
 ``` javascript
-'foo bar'
+foo bar
 ```
 
 The above example will match documents that contain either “foo” or “bar”. Documents that contain both will score more highly and will be returned first.
@@ -37,21 +37,21 @@ For example, let’s say you’re indexing a collection of documents about JavaS
 Lunr supports wildcards when performing searches. A wildcard is represented as an asterisk (*) and can appear anywhere in a search term. For example, the following will match all documents with words beginning with “foo”:
 
 ``` javascript
-'foo*'
+foo*
 ```
 
 This will match all documents that end with ‘oo’:
 
 ``` javascript
-'*oo'
+*oo
 ```
 
 Leading wildcards, as in the above example, should be used sparingly. They can have a negative impact on the performance of a search, especially in large indexes.
 
 Finally, a wildcard can be in the middle of a term. The following will match any documents that contain a term that begins with “f” and ends in “o”:
 
 ``` javascript
-'f*o'
+f*o
 ```
 
 It is also worth noting that, when a search term contains a wildcard, no stemming is performed on the search term.
@@ -65,51 +65,51 @@ To indicate that a term must be present in matching documents the term should be
 The below example searches for documents that must contain “foo”, might contain “bar” and must not contain “baz”:
 
 ``` javascript
-'+foo bar -baz'
++foo bar -baz
 ```
 
 To simulate a logical AND search of “foo AND bar” mark both terms as required:
 
 ``` javascript
-'+foo +bar'
++foo +bar
 ```
 
 ## Fields
 
 By default, Lunr will search all fields in a document for the query term, and it is possible to restrict a term to a specific field. The following example searches for the term “foo” in the field title:
 
 ``` javascript
-'title:foo'
+title:foo
 ```
 
 The search term is prefixed with the name of the field, followed by a colon (:). The field must be one of the fields defined when building the index. Unrecognised fields will lead to an error.
 
 Field-based searches can be combined with all other term modifiers and wildcards, as well as other terms. For example, to search for words beginning with “foo” in the title or with “bar” in any field the following query can be used:
 
 ``` javascript
-'title:foo* bar'
+title:foo* bar
 ```
 
 ## Boosts
 
 In multi-term searches, a single term may be important than others. For these cases Lunr supports term level boosts. Any document that matches a boosted term will get a higher relevance score, and appear higher up in the results. A boost is applied by appending a caret (^) and then a positive integer to a term.
 
 ``` javascript
-'foo^10 bar'
+foo^10 bar
 ```
 
 The above example weights the term “foo” 10 times higher than the term “bar”. The boost value can be any positive integer, and different terms can have different boosts:
 
 ``` javascript
-'foo^10 bar^5 baz'
+foo^10 bar^5 baz
 ```
 
 ## Fuzzy Matches
 
 Lunr supports fuzzy matching search terms in documents, which can be helpful if the spelling of a term is unclear, or to increase the number of search results that are returned. The amount of fuzziness to allow when searching can also be controlled. Fuzziness is applied by appending a tilde (~) and then a positive integer to a term. The following search matches all documents that have a word within 1 edit distance of “foo”:
 
 ``` javascript
-'foo~1'
+foo~1
 ```
 
 An edit distance of 1 allows words to match if either adding, removing, changing or transposing a character in the word would lead to a match. For example “boo” requires a single edit (replacing “f” with “b”) and would match, but “boot” would not as it also requires an additional “t” at the end.