Skip to content
This repository has been archived by the owner on Dec 15, 2022. It is now read-only.

Add a new method, setSpellcheckerType, to pick spellchecker selection. #115

Merged
merged 3 commits into from
Jul 29, 2019
Merged

Add a new method, setSpellcheckerType, to pick spellchecker selection. #115

merged 3 commits into from
Jul 29, 2019

Conversation

dmoonfire
Copy link
Contributor

  • Also exposed three constant values to choose different modes.
  • Added additional tests for testing new functionality.

This is in reference to #109. I'm tagging it as work-in-progress since I need the PRs to test across multiple platforms.

@dmoonfire dmoonfire marked this pull request as ready for review May 14, 2019 19:11
@dmoonfire
Copy link
Contributor Author

@rsese: I think this is ready for review. Would you be the best person to start?

@rsese
Copy link

rsese commented May 16, 2019

I'll bring this one up for you 👍

@dmoonfire
Copy link
Contributor Author

I'm asking for a sanity review and correctness to make sure I didn't miss anything.

I do not need this pulled into atom/spell-check, I will do that in a second PR.

@nathansobo nathansobo self-assigned this Jun 10, 2019
Copy link
Contributor

@nathansobo nathansobo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It looks like always-use-hunspell-spec.coffee is mostly a duplicate of spellchecker-spec.coffee. In situations like this, we've done some metaprogramming around the calls to describe and it in a loop to programmatically duplicate tests with a different configuration. Here's an example of running a subset of find and replace tests for two different values of the useRipgrep setting. Do you think you could do something like that here with setSpellcheckerType to avoid duplicating the test?

src/main.cc Show resolved Hide resolved
@dmoonfire
Copy link
Contributor Author

dmoonfire commented Jul 24, 2019

Do you think you could do something like that here with setSpellcheckerType to avoid duplicating the test?

@nathansobo: My original reason for having the two versions is that I needed to test both normal operations and the "force hunspell" version at the same time. If I combine them together, I'm not sure the best way of running the same test file twice with two different options. Also the files are slightly different, so I was afraid that the if statements would get even more complex to maintain because you have two axes to control (windows/mac/linux verses default/force-hunspell).

Suggestions?

- Introduce a new API call, `setSpellcheckerType` which takes a constant
  to determine if a system checker should be used, if available (the
  default), to always use the system checker, or to always use Hunspell.
- Duplicates the specs to have a force to Hunspell implementation.
@nathansobo
Copy link
Contributor

nathansobo commented Jul 26, 2019

@dmoonfire I went ahead and made the change I had in mind. I basically just loop over two boolean conditions surrounding the test. It adds a bit of complexity, but I think the savings in terms of duplication is worth it. What do you think? We'll see if the tests pass on CI, because I have a couple failing locally, possibly due to being on a different macOS version.

Copy link
Contributor Author

@dmoonfire dmoonfire left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, now I see what you mean. Looks good other than what appears to be a focus on the tests which may not be intentional.


@fixture.setDictionary('de_DE_frami', dictionaryDirectory)
for testAlwaysUseHunspell in [true, false]
fdescribe 'SpellChecker', ->
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this be a fdescribe?

@nathansobo nathansobo merged commit 55ae514 into atom:master Jul 29, 2019
@nathansobo
Copy link
Contributor

Published as spellchecker@3.7.0, thanks for your contribution! ❤️

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants