> not every problem in javascript demands a tc39 language-proposal-hammer. use some common-sense.
First and foremost, you should change your tone. There is no need for condescending comments. This list is intended to discuss the language and explore how we can further improve it; ideas are always welcome, and their cost, feasibility and usability are **constructively** discussed. Implying the lack of common sense is highly disgraceful and shows that you're not willing to have a meaningful discussion with anyone on this list. If all you intend to do on this list is reply "-1" to everyone, make patronizing comments, and flood everyone's inbox with images, I don't think anyone's interested in what you have to say. If you can't be civil and constructive, you are not welcome here. > there are 2 simple solutions to that: > > a) configure linter to complain about trailing whitespaces (which it should anyways). > > b) configure editor/ide to auto-remove trailing whitespace Configuring a third-party software to rewrite your code just so that it doesn't cause syntax errors is not a solution, but an unsafe hack, which should remind you of the path that Java's bloated IDEs went down. I would agree that linters are nice to have, but this isn't addressing the problem at hand. The problem at hand can be found in the "Subject" header of this e-mail. Further, there are some valid cases where you may need trailing whitespace at the end of a line (within a template string, this could be necessary depending on what you're trying to achieve). I'm not saying that I like or advocate trailing whitespace; but instructing some third-party software to remove it, even in places where it might make a difference, is the equivalent of closing your eyes and saying, "I can't see a problem here; everything is fine". > it may not be relevant to some who can afford to wait a few years for tc39 to come up with something. but it is relevant to engineers and pm’s with hard contract deadlines, and need practical solutions now with credibility they’ve been used in production (and not just some random gist). What benefit would an engineer or project manager have from a screenshot showing off some random, off-topic software? Or 225 lines of code where a single line could have been enough to get the idea? This discussion was supposed to be about syntax, not about your software; and we'd like to keep it that way. On Saturday, December 16, 2017 4:44:26 AM CET kai zhu wrote: > inline > > > If you haven't already guessed it, snippet 2 contains whitespace after the > > backslash invalidating the line continuation and hence making the string > > literal invalid. That's an invisible syntax error. > > there are 2 simple solutions to that: > > a) configure linter to complain about trailing whitespaces (which it should > anyways). > > b) configure editor/ide to auto-remove trailing whitespace > like this real-world vim one-liner @ > https://github.com/kaizhu256/node-utility2/blob/2017.9.15/.vimrc#L6 > <https://github.com/kaizhu256/node-utility2/blob/2017.9.15/.vimrc#L6> ``` > "auto remove trailing whitespace" > autocmd BufRead,BufWrite * if ! &bin | silent! %s/\s\+$//e | endif > ``` > > not every problem in javascript demands a tc39 language-proposal-hammer. > use some common-sense. > > @Kai Zhu: As has been done in the past, I, too, would like to kindly ask > > if > > you could please refrain from putting gigantic walls of code into your e- > > mails. Your last e-mail contained 225 (!) lines of escaped HTML and two > > screenshots that appeared to be unrelated to this discussion. Would it not > > have been enough to give one instance (as opposed to 225) of a "real-world > > example" for escaping, and to spare us the attachments? > > it may not be relevant to some who can afford to wait a few years for tc39 > to come up with something. but it is relevant to engineers and pm’s with > hard contract deadlines, and need practical solutions now with credibility > they’ve been used in production (and not just some random gist). > > On Dec 16, 2017, at 9:10 AM, kdex <[email protected]> wrote: > > > > IIRC, Douglas Crockford used to give the following example to illustrate > > why multi-line strings without template literals are cumbersome and > > error-prone: > > > > One of these snippets is okay, the other one won't even compile. Can you > > see which is which? > > > > Snippet 1: > > ```js > > const x = "foo\ > > bar"; > > ``` > > > > Snippet 2: > > ```js > > const x = "foo\ > > bar"; > > ``` > > > > If you haven't already guessed it, snippet 2 contains whitespace after the > > backslash invalidating the line continuation and hence making the string > > literal invalid. That's an invisible syntax error. > > > > Significant whitespace has never been the most popular idea in > > programming, and trailing whitespace is particularly problematic, as most > > editors don't even bother to show whitespace characters by default. > > > > There is more than one way to treat the following case: > > > > ```js > > const x = "foo > > bar"; > > ``` > > > > What should `x` contain? Should it be `"foobar"` (implicit line > > continuation) or `"foo\nbar"` (implicit EOL)? > > > > @Kai Zhu: As has been done in the past, I, too, would like to kindly ask > > if > > you could please refrain from putting gigantic walls of code into your e- > > mails. Your last e-mail contained 225 (!) lines of escaped HTML and two > > screenshots that appeared to be unrelated to this discussion. Would it not > > have been enough to give one instance (as opposed to 225) of a "real-world > > example" for escaping, and to spare us the attachments? > > > > In the future, if there really is the need to show longer code, I would > > like to ask if you (and everybody else) could instead use a gist for any > > example that exceeds ≈20 LoC. Making a gist [1] on GitHub is really > > simple and introduces far less noise on this list. You don't even need an > > account. Thanks! > > > > [1] https://gist.github.com/ > > > > On Saturday, December 16, 2017 1:12:42 AM CET Isiah Meadows wrote: > >> I'm aware. I typically use "newline" and "line continuation" > >> interchangeably, even though they technically aren't. (So feel free to > >> substitute "line continuation" for "newline", and that should be > >> accurate to what I meant. ;-)) > >> ----- > >> > >> Isiah Meadows > >> [email protected] > >> > >> Looking for web consulting? Or a new website? > >> Send me an email and we can get started. > >> www.isiahmeadows.com > >> > >> On Fri, Dec 15, 2017 at 8:53 AM, kdex <[email protected]> wrote: > >>> Sorry to be pedantic here, but: > >>> > >>> ```js > >>> "this\ > >>> right\ > >>> here" > >>> ``` > >>> > >>> aren't escaped newlines; that would be "\n". > >>> Those up there are line continuations. :) > >>> > >>> On Friday, December 15, 2017 2:48:00 PM CET Isiah Meadows wrote: > >>>> There are ES5 newline escapes. However, it'd be nice if I didn't have > >>>> to resort to templates just for multiline strings. Note: it wouldn't > >>>> actually simplify parsing by much - either you're handling the case > >>>> and remapping CR/CRLF to NL, or you're handling the case and throwing > >>>> an error. > >>>> > >>>> ```js > >>>> // ES5 escaped newlines > >>>> 'a multi-\ > >>>> line string' > >>>> ``` > >>>> ----- > >>>> > >>>> Isiah Meadows > >>>> [email protected] > >>>> > >>>> Looking for web consulting? Or a new website? > >>>> Send me an email and we can get started. > >>>> www.isiahmeadows.com > >>>> > >>>> On Fri, Dec 15, 2017 at 8:43 AM, J Decker <[email protected]> wrote: > >>>>> If any string were allowed to be multi-line it would not break any > >>>>> existing > >>>>> code, and it would simplify parsing strings. > >>>>> > >>>>> 'a multi- > >>>>> line string' > >>>>> > >>>>> Maybe this is a question... why not allow line spanning with single > >>>>> and > >>>>> double quoted strings? > >>>>> > >>>>> _______________________________________________ > >>>>> es-discuss mailing list > >>>>> [email protected] > >>>>> https://mail.mozilla.org/listinfo/es-discuss > >>>> > >>>> _______________________________________________ > >>>> es-discuss mailing list > >>>> [email protected] > >>>> https://mail.mozilla.org/listinfo/es-discuss > >>> > >>> _______________________________________________ > >>> es-discuss mailing list > >>> [email protected] > >>> https://mail.mozilla.org/listinfo/es-discuss > > > > _______________________________________________ > > es-discuss mailing list > > [email protected] > > https://mail.mozilla.org/listinfo/es-discuss
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss

