GNOME Bugzilla – Bug 789389
indistinguisable patterns added to matcher table
Last modified: 2017-10-24 21:15:13 UTC
I don't feel like investigating these now, so filing just for safekeeping: $ VTE_DEBUG=parse ./vte-2.91 [...] CSI J \e6 \c6 DEL'=> 'erase-in-display' and 'CSI J \e6 \c6 DEL'=> 'erase-in-display' are indistinguisable. '\9b J \de \e6 \c6 DEL'=> 'erase-in-display' and '\9b J \de \e6 \c6 DEL'=> 'erase-in-display' are indistinguisable. 'CSI ? J \c6 DEL'=> 'selective-erase-in-display' and 'CSI ? J \c6 DEL'=> 'selective-erase-in-display' are indistinguisable. '\9b ? J \e6 \c6 DEL'=> 'selective-erase-in-display' and '\9b ? J \e6 \c6 DEL'=> 'selective-erase-in-display' are indistinguisable. 'CSI K \e6 \c6 DEL'=> 'erase-in-line' and 'CSI K \e6 \c6 DEL'=> 'erase-in-line' are indistinguisable. '\9b K \de \e6 \c6 DEL'=> 'erase-in-line' and '\9b K \fd '=> 'erase-in-line' are indistinguisable. 'CSI ? K'=> 'selective-erase-in-line' and 'CSI ? K \c6 DEL'=> 'selective-erase-in-line' are indistinguisable. '\9b ? K'=> 'selective-erase-in-line' and '\9b ? K'=> 'selective-erase-in-line' are indistinguisable. No idea if they indicate a bug, or are just harmless.
Apparently these have escape sequences both with and without %m in caps.cc, whereas %m stands for multiple (optionally 0) numbers. So obviously technically they conflict, while it doesn't cause any problems (it's always the same method they resolve to, and we've seen no reports about any of these escape sequences not being properly recognized). Removing their non-%m versions seems to cause no harm, and the warning is gone. Alternatively, we could go for %m requiring at least one number (and duplicating the remaining %m rules). By the way, how did you get the list of bytes printed? They don't appear to me. Those '\e6 \c6 DEL' etc., sometimes the same on both sides while sometimes different, seems to be garbage to me (e.g. non-nul terminated string dumped as if it as nul-terminated), or am I missing something?
Created attachment 362176 [details] [review] fix
(In reply to Egmont Koblinger from comment #1) > Apparently these have escape sequences both with and without %m in caps.cc, > whereas %m stands for multiple (optionally 0) numbers. So obviously > technically they conflict, while it doesn't cause any problems (it's always > the same method they resolve to, and we've seen no reports about any of > these escape sequences not being properly recognized). > > Removing their non-%m versions seems to cause no harm, and the warning is > gone. That's probably the best solution. > By the way, how did you get the list of bytes printed? They don't appear to > me. Those '\e6 \c6 DEL' etc., sometimes the same on both sides while > sometimes different, seems to be garbage to me (e.g. non-nul terminated > string dumped as if it as nul-terminated), or am I missing something? Right, there was a bug there since the string isn't 0-terminated; fixed now.
Comment on attachment 362176 [details] [review] fix Thanks! :-)
Comment on attachment 362176 [details] [review] fix C
Committed.