[Lldb-commits] [PATCH] D70137: [lldb][Editline] Support ctrl+left/right arrow word navigation.

[Pavel Labath via Phabricator via lldb-commits]

labath added inline comments.


================
Comment at: lldb/packages/Python/lldbsuite/test/terminal/TestEditline.py:37-38
+
+        # Run help for different commands for escape variants to make sure each
+        # one matches uniquely (the buffer isn't cleared in between matches).
+        cases = [
----------------
rupprecht wrote:
> labath wrote:
> > The buffer isn't exactly "cleared", but each "expect" command should only match from the end of the previous match, so repeating the same command should not be a problem. What the other (few) pexpect tests do is put an `self.expect_prompt()` to ensure all output from the previous command is ignored, and lldb is ready to receive a new command. You could do that too. In fact, you could probably use the helper "expect" command which does all of this for you:
> > `self.expect("el ommand{L}c{L}{L}h{R}p".format(...), substrs=["Syntax: command"])`
> The expect helper is nice, thanks!
> 
> > but each "expect" command should only match from the end of the previous match
> I am not able to reproduce that. If I change the expect to the static string `"Syntax: print"` (not `% cmd`), then the second case (which types `"help step"`) passes. Which implies it's checking the entire buffer.
> 
> The third case (`"help exit"`) fails because the buffer does not contain the `print` help text anymore. But that means this behavior is dependent on the relation between help text length and buffer size. For now, I'll leave this as separate help commands.
That's very odd. It's definitely not how things behave on my end (the second check fails straight away), and it's not clear to me why would that differ for you. Looking at the code, it's pretty obvious <https://github.com/llvm/llvm-project/blob/b5f14326b447e5a97b3d7654448c36d7745a6882/lldb/third_party/Python/module/pexpect-4.6/pexpect/expect.py#L32> that pexpect intends to reset the internal buffer to include only the text after the last match.

I'd like to get to the bottom of this. Can you dig around (maybe step through the pexpect code) to see what's happening in your case? One thing that's been causing confusion in the past was the leftover `third_party/Python/module/pexpect-2.X` folder from the time before we updated pexpect. However, I find it unlikely that this would be the case here, as this should have been the pexpect behavior since forever...


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D70137/new/

https://reviews.llvm.org/D70137