Revert "Fix move to line start in multi-line history entries"

[fdncred]

Reverts #584

This is causing odd test behavior like ansi escapes, seeing reedline prompts in the middle of testing, leaving the terminal in a raw state.

@boathouse2112 If you can find a fix for this it would be great!!

These are the two test commands that I run and see the problems.

cargo test --features=bashisms,sqlite,external_printer,system_clipboard

and

cargo nextest run --all-features

[codecov]

Codecov Report

Attention: 7 lines in your changes are missing coverage. Please review.

Comparison is base (0c5f981) 56.09% compared to head (b619ebb) 49.32%.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #704      +/-   ##
==========================================
- Coverage   56.09%   49.32%   -6.78%     
==========================================
  Files          46       46              
  Lines        7993     7998       +5     
==========================================
- Hits         4484     3945     -539     
- Misses       3509     4053     +544     

Files	Coverage Δ
src/engine.rs	4.97% <36.36%> (-17.39%)	⬇️

... and 14 files with indirect coverage changes

[stormasm]

We need to be able to run these tests on all (3) of our platforms including Windows and Mac...

Currently the CI is not set up to do this...

I would be willing to run the tests on my Mac once they are fixed and I am sure someone would be willing to run them on Windows as well prior to re-landing these tests...

Thanks !

[stormasm]

I don't think these tests belong in Engine.

We want to keep the Engine code clean and just keep this one test in there that has been there for awhile.

#[test]
fn thread_safe() {
    fn f<S: Send>(_: S) {}
    f(Reedline::create());
}

I think we should start a test directory under the top level Reedline and put them there...

The following comments were observed on a Mac.

There appears to be some strange race conditions which are caused by running the tests in parallel
with nextest...

They pass some of the time in the cargo test runner (with no issue) but have more serious issues in nextest which is not a good sign.

[stormasm]

I am going to experiment with refactoring the tests and getting rid of the rstest functionality. This may be blocking nextest which is what I am seeing...

I think by refactoring the tests to have individual tests with just the different type of input scenarios would be simpler to test longer term. Right now all of the cases are bundled into two tests with 3 cases each...

This makes it challenging to figure out what tests are more flaky than others and also we can't currently IGNORE the individual CASES.

Also --- for some reason and this is a question for folks reading this....

I can NOT FIGURE OUT how to IGNORE rstests --- if anyone knows how to do this let me know ! thanks...

#[ignore] 

It works with regular tests but not with rstests which is kind of annoying...

[IanManske]

There appears to be some strange race conditions which are caused by running the tests in parallel

That was my suspicion as well (multiple tests all trying to read/write from the terminal). But even when running the tests serially (cargo test -j 1), the terminal output is still garbled. I assume our testing structure isn't meant to interact with the terminal which is why there previously weren't any tests for the Reedline struct.

A more future-proof solution is to use rexpect for testing, as it will create terminal files to isolate each test/process's stdin and stdout. Unfortunately, I think it only supports unix systems. PR #673 is related.

[fdncred]

after reverting the tests run fine on my mac too with the exception of the system_clipboard feature which is just broke unrelated to the recent PRs.