Just thinking about this, the argument that it could be done with regex would also apply to spaces. It's by no means an argument _in favor_, but it clearly wasn't a blocker.
On Mon, Jun 24, 2019 at 4:10 PM kai zhu <kaizhu...@gmail.com> wrote: > fyi, a search of the entire markedjs/marked repo shows 2 places where > rtrim is used: > > ```js > // https://github.com/markedjs/marked/blob/master/lib/marked.js > 227 > <https://github.com/markedjs/marked/blob/5ba9ba5b93b95096445249c11b31c13f7514137a/lib/marked.js#L227> > codeBlockStyle: 'indented', > 228 > <https://github.com/markedjs/marked/blob/5ba9ba5b93b95096445249c11b31c13f7514137a/lib/marked.js#L228> > text: !this.options.pedantic > 229 > <https://github.com/markedjs/marked/blob/5ba9ba5b93b95096445249c11b31c13f7514137a/lib/marked.js#L229> > ? rtrim(cap, '\n') > 230 > <https://github.com/markedjs/marked/blob/5ba9ba5b93b95096445249c11b31c13f7514137a/lib/marked.js#L230> > : cap > … > 1425 > <https://github.com/markedjs/marked/blob/5ba9ba5b93b95096445249c11b31c13f7514137a/lib/marked.js#L1425> > baseUrls[' ' + base] = rtrim(base, '/', true); > 1426 > <https://github.com/markedjs/marked/blob/5ba9ba5b93b95096445249c11b31c13f7514137a/lib/marked.js#L1426> > } > > 1427 > <https://github.com/markedjs/marked/blob/5ba9ba5b93b95096445249c11b31c13f7514137a/lib/marked.js#L1427> > } > > 1428 > <https://github.com/markedjs/marked/blob/5ba9ba5b93b95096445249c11b31c13f7514137a/lib/marked.js#L1428> > base > = baseUrls[' ' + base]; > 1429 > <https://github.com/markedjs/marked/blob/5ba9ba5b93b95096445249c11b31c13f7514137a/lib/marked.js#L1429> > 1430 > <https://github.com/markedjs/marked/blob/5ba9ba5b93b95096445249c11b31c13f7514137a/lib/marked.js#L1430> > if (href.slice(0, 2) === '//') { > ``` > > only the 1st use-case does what this thread proposes (the 1st trimRight's > "\n", while the 2nd behaves differently and is more like nodejs' > `require("path").dirname()` > > if i were writing the library, i wouldn't have bothered with a > helper-function if its only going to show up in 2 [trivial] places. > would've instead inlined two throwaway regexp-expressions, to keep code > more-self-contained / less-fragmented: > > ```js > 228 text: !this.options.pedantic > 229 ? cap.replace((/\n+$/), "") // remove trailing "\n" or > perhaps just use .trimRight() > 230 : cap > … > 1425 baseUrls[' ' + base] = base.replace((/\/[^\/]*$/), "/"); // get > "dirname" of base-url > 1426 } > ``` > > On Mon, Jun 24, 2019 at 2:27 PM Jacob Pratt <jhpratt...@gmail.com> wrote: > >> No idea how common of a use case this is; I personally ran across it when >> reviewing the source code for marked (specifically the [rtrim method]). >> That example only does characters, not strings, but it's used in the wild >> by a package with ~2m weekly downloads on npm. >> >> Of course we wouldn't want `trimStart` to differ from `trimLeft`, they'd >> all be modified in unison. I just think that symmetry between similar >> methods is important, and (apparently) has use cases. >> >> [rtrim method]: >> https://github.com/markedjs/marked/blob/master/lib/marked.js#L1493-L1517 >> >> On Mon, Jun 24, 2019 at 12:46 AM Jordan Harband <ljh...@gmail.com> wrote: >> >>> `trimStart` and `trimEnd` are better-named versions of the very very >>> long-existing `trimLeft` and `trimRight`, which lack this ability, along >>> with ES5's `trim`. >>> >>> It wouldn't make sense for these three to differ. >>> >>> It certainly seems like a potential language proposal to add a string >>> argument to all three; however, at what point is that reimplementing >>> `string.replace(/^(foo)+/, '')`, `string.replace(/(foo)+$/, '')`, and >>> `string.replace(/^(foo)+|$(foo)+$/, '')`? How common is the use case to >>> trim matching substrings off of the ends of a string? (the use cases for >>> padding were quite common) >>> >>> On Sun, Jun 23, 2019 at 12:14 AM Jacob Pratt <jhpratt...@gmail.com> >>> wrote: >>> >>>> `String.prototype.padStart` and `String.prototype.padEnd` accept the >>>> string to pad with as their final parameter. Is there any particular reason >>>> `String.prototype.trimStart` and `String.prototype.trimEnd` don't do the >>>> same? It would be nice to have a parallel, such that `'foo'.padEnd(10, >>>> 'bar').trimEnd('bar') === 'foo'`. >>>> >>>> References: >>>> - https://github.com/tc39/proposal-string-pad-start-end >>>> - https://github.com/tc39/proposal-string-left-right-trim >>>> >>>> Jacob Pratt >>>> _______________________________________________ >>>> es-discuss mailing list >>>> es-discuss@mozilla.org >>>> https://mail.mozilla.org/listinfo/es-discuss >>>> >>> _______________________________________________ >> es-discuss mailing list >> es-discuss@mozilla.org >> https://mail.mozilla.org/listinfo/es-discuss >> >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
