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

Jordan Rupprecht via Phabricator via lldb-commits lldb-commits at lists.llvm.org
Fri Nov 15 10:50:18 PST 2019


rupprecht marked 3 inline comments as done.
rupprecht 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 = [
----------------
labath wrote:
> 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...
Figured out what was going on and mailed D70324 to prevent this from happening to the next person this bites -- which could be me :)

I originally had:

```
self.child.send("help command\n")
self.child.expect_exact("Syntax: command")
```

And based on your suggestion, changed it to:
```
self.expect("help command\n", substrs=["Syntax: command"])
```

Which is wrong, because `self.expect()` calls `self.child.sendline(cmd)`, so it's running `"help command\n\n"` == `"help command\nhelp command\n"`.
The `expect_prompt()` helper will match the first prompt it sees, so the second run of the command is still in the match buffer. Checking for "Syntax: command" would still pass even though it was not intentionally ran twice.

I also tried changing `expect_prompt()` to continuously match until the last prompt it sees, but it's simpler to just disallow `\n` in the command.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D70137





More information about the lldb-commits mailing list