Comments (6)
So it looks like they decided to make evil-test-helpers its own package, but they let the recipe point to evil's repo, so they are always in sync. As they concluded, I think keeping it in the evil repo is the right thing to do. I'm still not aware of any arguments to do otherwise.
Thanks for clarifying this! :)
With regard to moving evil-tests.el and evil-test-helpers.el to a test folder, I'm not strongly opposed to it, but I don't think it affects clarity that much either way. If you want to make a PR, I would probably merge it.
👍
I don't think we actually use Cask, but I do in general like the idea of us moving to something like Eask. I introduced Eldev to evil-cleverparens and I do like it. Evil's current approach is a bit too "hand-rolled" for my liking. PR welcome on this.
Oh, sorry. I saw the Cask file, so I assumed this package was using Cask. 😓
Eldev is another good choice, but Windows support is a second-class citizen. As the author of Eask, I treat all modern OSs as first-class citizens. 🤔 BTW, evil-cleverparens
looks very interesting! 😋
from evil.
@jcs090218 before I answer specifically to this issue, I should preface by saying I'm not such a big fan of purely "correctness" changes to established projects like evil. But I'm happy to be convinced when it's more than just correctness.
Specifically to this issue, I read melpa/melpa#8172 and I'm not sure the presence of evil-test-helpers.el
in evil's repo is particularly relevant. That policy is about separate packages being in all-in-one repos, but I think it's too much of a stretch to say evil-test-helpers.el
is a separate package. I'm not aware of it being required by users or other packages in a scenario where at least some part of the rest of evil isn't required.
The sell that it "also streamlines the process of conducting CI tests" sounds alluring, but what do you actually mean? Can you be more concrete? When I think about it, I'm not sure I see much in the way of practical streamlining. Maybe I'm missing something.
And on your last point, I get the basic idea that splitting things out enhances clarity, but like I said, I don't really think they're separate packages, so I'm not sure why we need to "enhance clarity" between them..?
from evil.
The maintainer(s) are not interested. Closing this issue then. :)
from evil.
I should reiterate that I welcome counter-arguments to my points. I'm not immediately "interested" insofar as wanting to make the change without further discussion. But I am "interested" insofar as being curious about arguments I hadn't considered. I hope you don't feel I've been overly dismissive.
from evil.
I should reiterate that I welcome counter-arguments to my points. I'm not immediately "interested" insofar as wanting to make the change without further discussion. But I am "interested" insofar as being curious about arguments I hadn't considered. I hope you don't feel I've been overly dismissive.
Sorry, I shouldn't have gone to the conclusion that quickly. I apologize. I will elaborate more below.
The sell that it "also streamlines the process of conducting CI tests" sounds alluring, but what do you actually mean? Can you be more concrete? When I think about it, I'm not sure I see much in the way of practical streamlining. Maybe I'm missing something.
I was planning to contribute to this project by first replacing Cask with Eask since Cask has been deprecated for a long time. I would then clean up the Makefile and add tests for macOS and Windows. Similar to the PR emacs-evil/evil-collection#804.
And on your last point, I get the basic idea that splitting things out enhances clarity, but like I said, I don't really think they're separate packages, so I'm not sure why we need to "enhance clarity" between them..?
I was a bit confused by this since evil-test-helper
itself has its own recipe on MELPA, so I assumed they are two separate packages... no? 🤔
Other than that, having tests in the test
folder would help clarify what package files and test files are. Should evil-tests.el
be moved into the test
folder?
from evil.
Thanks @jcs090218 . I read #846 and agree with @wasamasa 's comment:
I'd be in for this change, as long as evil-tests-helpers.el remains in this repository so that Evil itself doesn't need to do anything else than (require 'evil-tests-helpers) in its test file.
So it looks like they decided to make evil-test-helpers its own package, but they let the recipe point to evil's repo, so they are always in sync. As they concluded, I think keeping it in the evil repo is the right thing to do. I'm still not aware of any arguments to do otherwise.
With regard to moving evil-tests.el
and evil-test-helpers.el
to a test
folder, I'm not strongly opposed to it, but I don't think it affects clarity that much either way. If you want to make a PR, I would probably merge it.
I was planning to contribute to this project by first replacing Cask with Eask since Cask has been deprecated for a long time. I would then clean up the Makefile and add tests for macOS and Windows. Similar to the PR emacs-evil/evil-collection#804.
I don't think we actually use Cask, but I do in general like the idea of us moving to something like Eask. I introduced Eldev to evil-cleverparens and I do like it. Evil's current approach is a bit too "hand-rolled" for my liking. PR welcome on this.
from evil.
Related Issues (20)
- Don't move cursor (and don't unhighlight) options in evil mode HOT 1
- `evil-redo` won't redo `evil-undo`, unless the latter was called in "normal mode" HOT 6
- Can't exit Visual-Block Mode with keyboard-escape-quit HOT 1
- Copy/paste in + register doesn't work when evil is run in Emacs terminal HOT 3
- incorrect behaviour of visual block paste HOT 14
- Backreferences in search fail to work with vim-style-regexp HOT 2
- Docstring slot busy for select-window in evil-core.el HOT 1
- C-M-mouse-1 / mouse-drag-region-rectangle doesn't work in normal state
- 'f' (search forward) becomes ';' repeat search on second search HOT 2
- `C-w <count> +` and `C-w <count> -` will not work; you *have* to put the count in front HOT 1
- Compile Error: List contains a loop: (lower-right lower-left upper-left upper-right HOT 3
- (evil-goto-definition) somehow erases the last jump HOT 5
- search motions forget offset when repeated HOT 1
- evil-jump-item issue with #ifdef #endif in c-ts-mode HOT 1
- Emacs >= 29.1: "⛔ Warning (comp): evil-pkg.el:1:2: Warning: the function `define-package' is not known to be defined." HOT 5
- Evil shift left/right restore to the wrong region HOT 3
- Programmatic options for `paste-after` HOT 2
- `C-w` in ex command-mode doesn't match insert mode (or Vim)
- [Feature] Support `defclass` for evil motions HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from evil.