Eventually, all of the docs will use the non-singleton interface require('yargs/yargs'). Thus, it might be nice to clarify what the singleton interface is here, to make it clearer which part of the above code block is the singleton/non-singleton interface.

We recommend using this approach by default, as the singleton interface (`require('yargs')`) is

Calling `.parse()` with no arguments is equivalent to calling `.argv`:

The current sentence implies yargs.parse() is equivalent to calling yargs.argv, but neither of those are a thing when yargs is require('yargs/yargs').

require('yargs/yargs')(process.argv.slice(2)).parse()

The introduction to this first example as well as the following example should be changed. Currently, the introductions to these code examples say they show calling yargs without passing arguments and then with passing arguments. However, with yargs/yargs, arguments must always be passed, so there’s no such distinction.

First drafts of more appropriate introductions for examples 1 and 2:

You can run Yargs directly on the relevant part of process.argv:

Yargs accepts any array of options. It doesn’t have to be from process.argv:

The change in this PR is nonetheless better than leaving the docs as recommending require('yargs'), so I would be fine with merging this PR before this problem is fixed and then fixing it later.

I think the bash syntax highlighting is less readable than no syntax highlighting, due to its random-seeming coloring of & and return in the help text.

```

Also, this was a problem in the previous version too, but I notice this whole code block should be indented with two spaces so it counts as being within the bullet point, rather than outside of the bulleted list. So ultimately this section of the README should be written like this:

* a dynamically generated help menu based on your arguments:

  ```
  mocha [spec..]
  
  Run tests with Mocha
  
  Commands
    mocha inspect [spec..]  Run tests with Mocha                         [default]
    mocha init <path>       create a client-side Mocha setup at <path>
  
  Rules & Behavior
    --allow-uncaught           Allow uncaught errors to propagate        [boolean]
    --async-only, -A           Require all tests to use a callback (async) or
                               return a Promise                          [boolean]
  ```

* bash-completion shortcuts for commands and options.

There are a few formatting and grammar problems in this paragraph. Also, I personally think the text looks more readable if only the “Note” part of the paragraph is italic (as the majority of notes in api.md are formatted). Here is my suggested replacement paragraph that makes all those changes:

_**Note:**_ Yargs exposes the helper `hideBin`, which handles the `process.argv.slice`
logic for you.

Note: Yargs exposes the helper hideBin, which handles the process.argv.slice logic for you.

For comparison, here’s how it looks with all of my changes except making the paragraph non-italic:

Note: Yargs exposes the helper hideBin, which handles the process.argv.slice logic for you.

Fix these problems:

• unbalanced parens
• misspelled name of function setq-default

@rachelnabors

Unfortunately, a global configuration option would force every third party component author to be compatible with both modes

I think you overlooked a large part of the demo I provided. I was not suggesting a global configuration option—that was only @mr21’s idea. In my demo, I suggested adding a new attribute to React input elements, onChangeCompleted. Such an addition would be backwards-compatible because currently that attribute is ignored (and logs a warning that it is unknown).

There have been previous discussions, and if you have feedback, we'd love for you to join the conversation!

Discussing how to listen to input change events with React is a bit confusing because there have been multiple solutions discussed in multiple places:

• #14857 (closed) suggested the same thing I want to suggest, adding a new attribute such as onChangeCompleted. That issue was automatically closed due to inactivity.
• #19150 (open) (this issue) suggested a global configuration option $$useRealOnChange.
  • I then suggested an alternative, adding a new attribute such as onChangeCompleted.
• #9657 (open) suggested a backwards-incompatible change to the existing attribute onChange.
  • Later comments in that issue discuss the idea of a new attribute such as onEveryChange, but the new attribute would be in addition to the backwards-incompatible change to onChange.

In which places would you like me to discuss my preferred solution of adding a backwards-compatible new attribute such as onChangeCompleted? You suggested #9657, but I’m thinking it would make the conversation clearer if you reopened issue #14857, or if I created a new issue and posted links to it in the other issues.

@rachelnabors Here’s an example I made that demonstrates the desired behavior, React not providing access to that behavior, and the way I personally wish React would give us access to that behavior:

CodeSandbox demo requesting native onchange in React

Mirror of that demo page

As CodeSandbox is a third-party site I am unfamiliar with, I don’t trust it to stay up forever, so here’s a mirror of the important parts of that demo page:

public/index.html

<div>
  <script>
    function handleNativeOnChange(event) {
      console.log("native change event fired", event.value);
    }
  </script>
  <h2>Demo of native <code>onchange</code> attribute</h2>
  <input type="number" onchange="handleNativeOnChange(this)" />
</div>

Demo of native onchange attribute

The above number-type input element logs a message when its change event is fired. Such an event is fired when a change is committed. The exact conditions of the event firing depend on the type of input element and possibly the browser, but in my testing with this particular input element, the change event seems to fire when any of the following happen:

• The field is blurred after its value was changed.
• The user presses Enter/Return on the keyboard after changing its value.
• The user increments or decrements the number in the field by pressing Up or Down on the keyboard.

src/App.js

export default function App() {
  function handleOnChange(event) {
    console.log("React change event handler called", event.target.value);
  }

  return (
    <div className="App">
      <h2>
        Demo of React <code>onChange</code> attribute
      </h2>
      <input type="number" onChange={handleOnChange} />
    </div>
  );
}

Demo of React onChange attribute

The above number input logs a message on every input event, rather than only on change events. This is because React’s onChange attribute works the same as an onInput attribute.

Requested feature for React

It’s too late to redefine React’s onChange attribute, but can we add a way to get the same behavior as HTML’s onchange attribute without manually handling all the cases listed in that section?

Multiple possible solutions are discussed in React issue #19150, but the idea I currently favor is supporting a new attribute onChangeCompleted on input elements. If such an attribute existed, the following commented-out input element would work the same as in the native demo:

<input type="number" onChangeCompleted={handleOnChange} />

Bumps lodash from 4.17.15 to 4.17.19. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/lodash/lodash/releases">lodash's releases</a>.</em></p> <blockquote> <h2>4.17.16</h2> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/lodash/lodash/commit/d7fbc52ee0466a6d248f047b5d5c3e6d1e099056"><code>d7fbc52</code></a> Bump to v4.17.19</li> <li><a href="https://github.com/lodash/lodash/commit/2e1c0f22f425e9c013815b2cd7c2ebd51f49a8d6"><code>2e1c0f2</code></a> Add npm-package</li> <li><a href="https://github.com/lodash/lodash/commit/1b6c282299f4e0271f932b466c67f0f822aa308e"><code>1b6c282</code></a> Bump to v4.17.18</li> <li><a href="https://github.com/lodash/lodash/commit/a370ac81408de2da77a82b3c4b61a01a3b9c2fac"><code>a370ac8</code></a> Bump to v4.17.17</li> <li><a href="https://github.com/lodash/lodash/commit/1144918f3578a84fcc4986da9b806e63a6175cbb"><code>1144918</code></a> Rebuild lodash and docs</li> <li><a href="https://github.com/lodash/lodash/commit/3a3b0fd339c2109563f7e8167dc95265ed82ef3e"><code>3a3b0fd</code></a> Bump to v4.17.16</li> <li><a href="https://github.com/lodash/lodash/commit/c84fe82760fb2d3e03a63379b297a1cc1a2fce12"><code>c84fe82</code></a> fix(zipObjectDeep): prototype pollution (<a href="https://github-redirect.dependabot.com/lodash/lodash/issues/4759">#4759</a>)</li> <li><a href="https://github.com/lodash/lodash/commit/e7b28ea6cb17b4ca021e7c9d66218c8c89782f32"><code>e7b28ea</code></a> Sanitize sourceURL so it cannot affect evaled code (<a href="https://github-redirect.dependabot.com/lodash/lodash/issues/4518">#4518</a>)</li> <li><a href="https://github.com/lodash/lodash/commit/0cec225778d4ac26c2bac95031ecc92a94f08bbb"><code>0cec225</code></a> Fix lodash.isEqual for circular references (<a href="https://github-redirect.dependabot.com/lodash/lodash/issues/4320">#4320</a>) (<a href="https://github-redirect.dependabot.com/lodash/lodash/issues/4515">#4515</a>)</li> <li><a href="https://github.com/lodash/lodash/commit/94c3a8133cb4fcdb50db72b4fd14dd884b195cd5"><code>94c3a81</code></a> Document matches* shorthands for over* methods (<a href="https://github-redirect.dependabot.com/lodash/lodash/issues/4510">#4510</a>) (<a href="https://github-redirect.dependabot.com/lodash/lodash/issues/4514">#4514</a>)</li> <li>Additional commits viewable in <a href="https://github.com/lodash/lodash/compare/4.17.15...4.17.19">compare view</a></li> </ul> </details> <details> <summary>Maintainer changes</summary> <p>This version was pushed to npm by <a href="https://www.npmjs.com/~mathias">mathias</a>, a new releaser for lodash since your current version.</p> </details> <br />

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

<details> <summary>Dependabot commands and options</summary> <br />

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
• @dependabot use these labels will set the current labels as the default for future PRs for this repo and language
• @dependabot use these reviewers will set the current reviewers as the default for future PRs for this repo and language
• @dependabot use these assignees will set the current assignees as the default for future PRs for this repo and language
• @dependabot use this milestone will set the current milestone as the default for future PRs for this repo and language

You can disable automated security fix PRs for this repo from the Security Alerts page.

</details>

I manually ran the tests on this branch and they pass. The lodash version upgrade seems safe according to lodash’s changelog.

Thanks for the bug report. In a local branch, I added the file you linked as a test case, and can reproduce the problem.

Desired behavior

I think the desired behavior for :DetectIndent on this file is to not modify sw or ts in the local buffer. That way, you can configure your desired sw and ts for tab-only files by setting them in your vimrc (e.g. set tabstop=4).

The cause of the bug

To determine where the code is going wrong, I checked the output of :verbose DetectIndent for that file:

Using tabs to indent. leading_tab_count: 795, leading_space_count: 4, leading_spaces_gcd: 1, leading_space_dict: {'11': 2, '6': 2} Changes from the buffer’s initial settings: tabstop changed from 8 to 1, shiftwidth changed from 8 to 1, softtabstop changed from 0 to -1

That output shows that the file actually does not use only tabs for indentation. (I think DetectIndent already handles files with only tabbed indentation correctly, leaving sw and ts at their global values.) Rather, this plugin changes sw and ts because 4 of the 1,890 lines in this file are indented with spaces. An example of such a line:

	my $i;
	my @prefixes = find_unique_prefixes(@stuff) unless $opts->{LIST_ONLY};

      TOPLOOP: # <------
	while (1) {
		my $last_lf = 0;

The algorithm wrongly guesses that since two of the lines in the file start with 6 spaces, and two lines start with 11 spaces, the desired visual indent size should be the greatest common denominator of 6 and 11, which is 1.

How to fix the bug

I’m still thinking of the best heuristic for fixing this. In this particular file it seems the indentation of the four space-indented lines should be ignored because they are more properly thought of as using spaces for alignment, not spaces for indentation. But what’s the best heuristic for handling a mix of space-indented lines and tab-indented lines in general?

In files where 10% of lines are indented with spaces, the sizes of those indents currently affect the displayed tabstop size, but I think they shouldn’t. However, I think that space-indented lines that consist of 49% of indented lines still should affect the tabstop size. What should the cutoff be? There should probably also be a minimum absolute number of space-indented lines for space-indented lines to be taken into account.

More reasons for scroll bars

I want to note that scroll bars are useful for more reasons than using the pointer to scroll through the document, the reason given in the first comment. Scroll bars also provide these advantages:

• They provide visual feedback on where you are in a document. In this way it provides the same information as Vim’s percentage label (e.g. 35%), but in a more directly interpretable way.
• They provide visual feedback on how long the current document is. This can help me recognize whether I am in the right file, and how hard I should flick the scroll wheel or trackpad to reach a certain position in the document.

How scroll bars should work

For an example of how a Vim/Neovim GUI can display scroll bars, see how MacVim does it:

When calculating the length of the document for the purposes of the scroll bar, MacVim includes the distance you can scroll below the last line as part of the document length. I think this is a good way of accounting for the ability to scroll below the last line.

Before this, the sentence could be interpreted as “WebRTC, if you are curious, is an open source book…” and the reader would object “no, it’s a protocol.”

Wrong extension for the fish config file and wrong name for the functions folder in the fish config that fish automatically loads. Also, at least on my Mac OS X 10.9 machine, the folder is ~/.config/, not ~/.conf.

I ported all the changes from this PR that are still applicable into PR #307.

source of the information that it should be functions and not function: https://fishshell.com/docs/current/index.html#autoloading-functions

Just push 'Submit new issue'. You don't need to do anything else.

Just push 'Submit new issue'. You don't need to do anything else.

Just push 'Submit new issue'. You don't need to do anything else.

Parentheses are usually understood to be “()”. See https://en.wikipedia.org/wiki/Bracket#Parentheses and https://en.wikipedia.org/wiki/Bracket#Curly_brackets.

@HaojiXu I don’t understand exactly what problem you were running into with the Unicode character classes in the hashtag parsing regexp, but I wondered if it was related to browser support for that feature:

• Unicode property escapes support table on Can I use…
• Unicode property escapes support table on MDN

From those tables it seems that \p{…} in regexps is supported in all modern browsers as well as Node since v10. However, Firefox only gained this support in the last month with the release of version 78. Were you testing on Firefox 77? If so, that could be the problem.

It makes sense that any-char would be slow, so that’s probably a good guess.

The parse rule introduced in commit 9433e79 demonstrates a more efficient way to parse “any chars”:

<any-non-page-link-chars> = #'[^\\[\\]]*'

We can probably replace other uses of any-chars with similar constructions.

I didn’t write the parser with regexes like that to start with because such regexes slightly increase the difficulty of adding new syntax that may be nested. For example, if page links could contain **bold** text, the above regex would have to be #'([^*\\[\\]]|\\*[^*])*' (or you could use a shorter regex paired with another parse rule). The information that the syntax for bold text is ** would be duplicated both in the bold rule and in regexes of rules that can contain bold text.

The previous description was copy-pasted from _.endsWith. This updated description comes from https://lodash.com/docs/4.17.15#isString.

I notice that you already merged a PR that incorporates this PR’s changes and also does the extra things you were asking me to do: PR #288. That means there is no need for my PR, so I will close it.

Flow version: v0.128.0

Expected behavior

According to the documentation page Mixed Types, anything can be assigned to mixed:

mixed will accept any type of value. Strings, numbers, objects, functions– anything will work.

That documentation page doesn’t say it should work any different when mixed is inside an array or object. Therefore, the following code, which uses an Array<mixed> type, should pass Flow type checking:

const arrayOfNumbers: Array<number> = [1, 2, 3];
const arrayOfMixed: Array<mixed> = arrayOfNumbers;

Additionally, all of the example code in the “Actual behavior” section should pass Flow type checking.

I know that covariance and contravariance can sometimes cause similar confusion, but I don’t see why it would change my expectations here.

Actual behavior

Flow raises type errors in four of the six paragraphs of code below (demo on Try Flow):

// @flow

// mixed works when it’s a top-level value
const num: number = 3;
const mix: mixed = num;

// mixed FAILS inside array types
const arrayOfNumbers: Array<number> = [1, 2, 3];
const arrayOfMixed: Array<mixed> = arrayOfNumbers;

// mixed FAILS inside object types
const personWithNumberAge: { age: number } = { age: 55 };
const personWithMixedAge: { age: mixed } = personWithNumberAge;

// mixed FAILS inside indexed object types
const stringsToNumbers: { [string]: number } = { "a": 1, "b": 2 };
const stringsToMixed: { [string]: mixed } = stringsToNumbers;

// mixed FAILS inside indexed object types as function parameters (my use-case)
function withStringsToMixed(obj: { [string]: mixed }): Array<string> {
  return Object.keys(obj);
}
withStringsToMixed(stringsToNumbers);

// generics work inside indexed object types
function withStringsToGeneric<T>(obj: { [string]: T }): Array<string> {
  return Object.keys(obj);
}
withStringsToGeneric(stringsToNumbers);

The type errors are of this form:

Cannot assign somethingContainingNumbers to somethingContainingMixed because number [1] is incompatible with mixed [2] in [some container]. [incompatible-type]

    9: const arrayOfMixed: Array<mixed> = arrayOfNumbers;
                                          ^ Cannot assign `arrayOfNumbers` to `arrayOfMixed` because number [1] is incompatible with mixed [2] in array element. [incompatible-type]
        References:
        8: const arrayOfNumbers: Array<number> = [1, 2, 3];
                                       ^ [1]
        9: const arrayOfMixed: Array<mixed> = arrayOfNumbers;
                                     ^ [2]
    13: const personWithMixedAge: { age: mixed } = personWithNumberAge;
                                                   ^ Cannot assign `personWithNumberAge` to `personWithMixedAge` because number [1] is incompatible with mixed [2] in property `age`. [incompatible-type]
        References:
        12: const personWithNumberAge: { age: number } = { age: 55 };
                                              ^ [1]
        13: const personWithMixedAge: { age: mixed } = personWithNumberAge;
                                             ^ [2]
    17: const stringsToMixed: { [string]: mixed } = stringsToNumbers;
                                                    ^ Cannot assign `stringsToNumbers` to `stringsToMixed` because number [1] is incompatible with mixed [2] in the indexer property. [incompatible-type]
        References:
        16: const stringsToNumbers: { [string]: number } = { "a": 1, "b": 2 };
                                                ^ [1]
        17: const stringsToMixed: { [string]: mixed } = stringsToNumbers;
                                              ^ [2]
    23: withStringsToMixed(stringsToNumbers);
                           ^ Cannot call `withStringsToMixed` with `stringsToNumbers` bound to `obj` because number [1] is incompatible with mixed [2] in the indexer property. [incompatible-call]
        References:
        16: const stringsToNumbers: { [string]: number } = { "a": 1, "b": 2 };
                                                ^ [1]
        20: function withStringsToMixed(obj: { [string]: mixed }): Array<string> {
                                                         ^ [2]

As the last paragraph “generics work inside indexed object types” shows, this issue can be worked around by adding an unused generic parameter to the function. This workaround is only possible if the mixed-containing type is a parameter to the function, not if it’s a local variable.

For comparison, when I try writing equivalent code in TypeScript by changing mixed to unknown, TypeScript raises no errors. I know that Flow and TypeScript are not always directly comparable, though, since their type systems differ in a few ways.

Right now, the unknown top-level type is only documented in the release notes: https://www.typescriptlang.org/docs/handbook/release-notes/typescript-3-0.html#new-unknown-top-type

It’s good to document unknown next to the any type, because it replaces certain use-cases for any. This new documentation gives an overview of unknown and focuses on giving practical examples, while the existing release notes focus on defining the new feature and give exhaustive examples.

Fixes #960

Specifically, the pages that contain nothing but placeholder text are hyperapp.dev/guides (edit guides.md) and hyperapp.dev/ecosystem (edit ecosystem.md).

affects https://hyperapp.dev/tutorial

The previous description was copy-pasted from _.endsWith. This updated description comes from https://lodash.com/docs/4.17.15#isString.

I’m not working on this, so feel free.

If I understand your proposed solution correctly, React.$$useRealOnChange would be a global variable that would change the behavior of onChange in code such as <input onChange={event => handleChange(event)} />. The goal is to easily listen to the browser’s built-in change event.

I, too, wish that React allowed me to listen to the native change event. However, I have concerns about that specific solution. I worry that adding a global variable like React.$$useRealOnChange would cause surprising bugs and complicate testing. If you set React.$$useRealOnChange to true in one part of the code, it could affects parts of the code that were written assuming a value of false for it.

I favor the solution proposed by this older issue: #14857 “Easily handle browser 'change' events”. That issue proposed supporting a new attribute on input elements that act like a browser-native onchange attribute. It suggested these names as possibilities:

• onChangeAndBlur
• onChangeNative
• onChangeCompleted
• onCompleteChange

That issue was automatically closed for being “stale”, so perhaps this issue should become the new active issue about accessing the browser-native onchange.