Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Build is broken #129

Closed
MartyGentillon opened this issue Apr 20, 2017 · 11 comments
Closed

Build is broken #129

MartyGentillon opened this issue Apr 20, 2017 · 11 comments

Comments

@MartyGentillon
Copy link
Contributor

MartyGentillon commented Apr 20, 2017

on 16abf38

> apm test
....................F.....................................................................................................................
..........................................................................................................................................
............................................................

AtomicEmacs
  atomic-emacs:forward-sexp
    it moves all cursors forward one symbolic expression
      Expected '  aa
[0](bb cc)[1]
' to equal '  aa[0]
(bb cc)[1]
'.
        at .<anonymous> (file:///C:/Users/Marty/Documents/GitHub/atomic-emacs/spec/atomic-emacs-spec.coffee:137:38)


Finished in 9.732 seconds
336 tests, 422 assertions, 1 failure, 0 skipped


Tests failed
@MartyGentillon
Copy link
Contributor Author

Running on windows 10 creators update.

@MartyGentillon
Copy link
Contributor Author

Based on bisecting, the first commit with this behavior is 66e312b. Interestingly before that, atom was different enough that it is possible that this test still failed.

@MartyGentillon
Copy link
Contributor Author

Some further test strings which happen to pass

"[0] aa (dd)\n[1](bb cc)\n" -> " aa[0] (dd)\n(bb cc)[1]\n"
"[0] aa dd\n[1](bb cc)\n" -> " aa[0] dd\n(bb cc)[1]\n"

yet doesn't pass. The bug has something to do with newlines.
"[0] aa\n (dd)\n[1](bb cc)\n" - aa\n[0] (dd)\n(bb cc)[1]\n"

@MartyGentillon MartyGentillon changed the title Build is broken on 16abf3853bb2907b5b2a0ff6e011509024323255 Build is broken Apr 21, 2017
@oggy
Copy link
Collaborator

oggy commented Apr 21, 2017

Thanks!

I'm pretty certain this did work when it was written. A while back I traced it down to a bug (or at least undocumented change) in the core text-buffer package. IIRC it changed how \s is handled with respect to newlines. I had started trying to fix it there but never got around to finishing it.

In the meantime if you can find a simple workaround that'd be awesome.

@MartyGentillon
Copy link
Contributor Author

Found a fix. I will include it with my pull request for #103

@MartyGentillon
Copy link
Contributor Author

Found my mistakes... now I have to see if I can find the underlying bug.

@MartyGentillon
Copy link
Contributor Author

This time I have got it right. The difference is that atom text-buffer considers /\W/ a single line regular expression, while /[\W\n]/ is a multi-line regular expression as determined by the regular expression on text-buffer/lib/helpers.js line 6.

@MartyGentillon
Copy link
Contributor Author

Apparently I am on a slightly old version, but the bug is still there. https://github.com/atom/text-buffer/blob/master/src/helpers.js#L3

@MartyGentillon
Copy link
Contributor Author

Root cause: atom/text-buffer#226

MartyGentillon added a commit to MartyGentillon/atomic-emacs that referenced this issue Apr 21, 2017
The cursor would skip across newlines in addition to a single word.

Root cause is an underlying bug in text-buffer where old regular
expression was considered single line.  Extra new lines can be
removed after it is fixed.

see atom/text-buffer#226
see avendael#129
@MartyGentillon
Copy link
Contributor Author

Workaround in #130

MartyGentillon added a commit to MartyGentillon/atomic-emacs that referenced this issue Apr 26, 2017
The cursor would skip across newlines in addition to a single word.

Root cause is an underlying bug in text-buffer where old regular
expression was considered single line.  Extra new lines can be
removed after it is fixed.

see atom/text-buffer#226
see avendael#129
oggy pushed a commit that referenced this issue May 15, 2017
The cursor would skip across newlines in addition to a single word.

Root cause is an underlying bug in text-buffer where old regular
expression was considered single line.  Extra new lines can be
removed after it is fixed.

see atom/text-buffer#226
see #129
@oggy
Copy link
Collaborator

oggy commented Jul 28, 2017

Fix was merged. Thanks @MartyGentillon !

@oggy oggy closed this as completed Jul 28, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants