> cannot be sure what to look at. Could you please specify, for each
> spot you analyzed, the node name and the text surrounding the regexp
> match? I'd like to go over all the places you found, but I need a
Sure Eli. Sorry for not thinking about that before.
In the following, navigate to the mentioned node of the respective
manual, and either search for the string in "Search for", or just search
for the string in "Old match". The string in "Search for" is the text
just before the spot analyzed.
* Emacs (‘C-h r’):
1) Node: Inserting Text (‘m Inserting Text’)
Search for: For example, ‘C-x 8 [’ inserts
Old match: which is Unicode code-point ‘U+2018
New match: U+2018
2) Node: Inserting Text (‘m Inserting Text’)
Search for: C-x 8 [’ and inserts
Old match: . To see which characters have ‘C-x 8
New match: C-x 8
The new regexp is right, the old one is wrong.
3) Node: Setting Mark (‘m Setting Mark’)
Search for: (‘mouse-save-then-kill’).
Old match: ‘Shifted cursor motion keys
New match: Shifted cursor motion keys
Nested quotes: The new regexp matches all of the inner quote,
while the old one leaves the first ’ unquoted.
4) and 5) Node: Text Display (‘m Text Display’)
Search for: Emacs tries to determine if the curved quotes
Old match: The empty string in ‘’’.
New match: ’
Similarly, search for: If the curved quotes.
Same situation as before.
The new regexp is right, the old one is wrong (it fails to quote the ’).
6) Node: International Chars (‘m International Chars’)
Search for: a left single quotation mark
Old match: by typing ‘C-x 8 [
New match: C-x 8 [
Similar to 1) and 2).
7) Node: Quotation Marks (‘m Quotation Marks’)
Search for: "whose default value is"
Old match: '(?‘ ?
New match: ?
Quote characters inside a quote, but not making an inner quote. Both
regexps get it wrong.
8) Node: Quotation Marks (‘m Quotation Marks’)
Search for: you can type ‘C-x 8 [’ for
Old match: , ‘C-x 8 ]
New match: C-x 8 ]
Similar to 1) and 2).
* Calc (‘C-h i m Calc RET’)
9) Node: Yacas Language Mode (‘7 8 5’)
Search for: in Yacas mode, and
Old match: ‘arcsin(x^2)
New match: arcsin(x^2)
I find this one a little weird. In the calc.texi file, I navigated to
this spot, by searching for "arcsin(x^2)". There is a suspicious "`"
before @samp.
10) Node: Summary (‘m Summary RET’)
Search for: calc-grab-sum-across C-x *
Sorry, I don't know how to specify more this one (the text matched is
very long, for both regexps). Notice that the text matched begins in
" editing" and ends up in the row that has a "@".
Both regexps fail.
11) Node: Summary (‘m Summary RET’)
‘m Summary RET’
Search for: cancel if/loop command Z
Same as before. The quoting can be seen in "calc-kbd-push Z".
Both regexps fail.
* MH-E (‘C-h i m MH-E’)
12) Node: Speedbar (‘m Speedbar’)
Search for: ‘mh-speed-view’).
Old match: Expand Nested Folders (‘+
New match: +
Similar situation for the next two items:
Old match: Contract Nested Folders (‘-
New match: -
Old match: Refresh Speedbar (‘r
New match: r
While the old regexp quotes inconsistently, the old one just quotes the
shortcut. A regexp that matches nested quotes (and quotes the outer
ones) could do the trick (though I believe it could break cases like
1) and 2), for example).
* Org (‘C-h i m Org RET’)
13) Node: TTY keys (‘m Miscellaneous RET 9)
Search for: ‘S-<RIGHT>’
As with the Calc table, it is not easy to write this one.
Notice that there are keybindings that take two rows:
C-c <RIGHT>
C-c C-x <LEFT>
C-c C-x <RIGHT>
The old regexp matches up until the first ’, leaving the end of the
keybinding unquoted.
The new one, just matches the space between ‘ and ’ (under the Speed key
column of the table), leaving the keybinding unquoted.
Similar to 11), and both regexps get it wrong.
* SC (‘C-h i m SC RET’)
14) Node: Citations (‘m Citations’)
Search for: result in a nesting of the
Old match: ‘>
New match: >
Similarly,
search for: and multiple nesting of
Old match: ‘>
New match: >
Again a case of nested quotes, though I think the nested quote is not
necessary. The old regexp quotes inconsistently, making it look
uglier. The new one just quote the important character, >.
That is all. I built the info files from the latest master I could get,
just in case. That is, commit: c2c9ef2c1e509f1a01ffaefd7475004854162a10
I think it is much easier to navigate to the problematic spots now, but
please let me know if I missed something again.
Best regards,
Mauro.