Hi Stig, I wrote a patch that checks if the string being typed is a beginning of a protocol name, and if it so, then it calls the auto-complete functionality.
It works as I describe in my previous email, it checks if the string being typed is a protocol name by checking if it is preceded by a logical operation (or, and, not, xor) or the string we want to auto-complete is located at the beginning of the display filter. The problem of logical operation (and, or) followed by "not" (e.g: exp1 and not exp2) can't be solved programmatically since we have no way to predict whether the user is going to type "not" or some protocol that starts with "n" letter. Similarly, we can't predict whether the user is going to begin typing a display filter that starts with the logical operation "not" (not exp1) or starts with a protocol that starts with the letter "n". patch file is attached. - Bahaa On Sat, Oct 25, 2008 at 1:31 AM, Bahaa Naamneh <[EMAIL PROTECTED]> wrote: > correction: i missed the fact that logical operation can be also preceded > by other logical operation! :), so checking whether the string is preceded > by logical operation won't help. > > (tcp.flags.push==1) and not(tcp.flags.ack==0) > > > > On Sat, Oct 25, 2008 at 1:08 AM, Bahaa Naamneh <[EMAIL PROTECTED]>wrote: > >> Hi, >> >> I think trying to figure out if the user is typing a protocol name could >> be easier since protocol name can only comes either at the beginning of the >> display filter or after logical Operation. >> >> Display Filter syntax: >> [Protocol].[String1].[String2] [Comparison operator] [Value] [Logical >> Operations] [Other expression] >> >> So you could check whether the string you are trying to auto-complete is a >> protocol name or not by checking if the protocol name is preceded by logical >> operation or located at the beginning of the display filter. >> and of course, parentheses should be taken into account. >> >> >> - Bahaa >> >> >> >> On Fri, Oct 24, 2008 at 10:37 PM, Stig Bjørlykke <[EMAIL PROTECTED]>wrote: >> >>> Hi. >>> >>> I have just committed a patch which enables autocomplete and >>> autocompletion list of protocol names in the filter entry. But this >>> has some side effects, because it currently also autocompletes >>> operators (when typing "and" or "or") and values (typing something >>> like "ip.tos.precedence > 3" will popup "3comxns"). >>> >>> I don't know how to fix this yet, but I leave the code in so more >>> people can try the feature and maybe fix this issue? I guess we could >>> try figure out if the user is typing an operator or a value. >>> >>> Or maybe just add a preference value (turn on/off) and document this >>> behavior? >>> >>> -- >>> Stig Bjørlykke >>> _______________________________________________ >>> Wireshark-dev mailing list >>> [email protected] >>> https://wireshark.org/mailman/listinfo/wireshark-dev >>> >> >> >
is_protocol_being_typed.patch
Description: Binary data
_______________________________________________ Wireshark-dev mailing list [email protected] https://wireshark.org/mailman/listinfo/wireshark-dev
