Tony Mechelynck wrote:

> On Mon, Aug 20, 2018 at 10:06 AM, Bram Moolenaar <[email protected]> wrote:
> >
> >> On Monday, August 20, 2018 at 1:37:53 AM UTC+9, Bram Moolenaar wrote:
> >> > Currently, when making a list with continuation lines, it is not
> >> > possible to add a comment somewhere:
> >> >
> >> >     let array = [
> >> >             \ item,
> >> >             \ item,
> >> >             \ item,
> >> >             \]
> >> >
> >> > Adding a comment after the comma causes all the rest to be included in
> >> > the comment:
> >> >
> >> >     let array = [
> >> >             \ item,
> >> >             \ item, " comment
> >> >             \ item,
> >> >             \]
> >> >
> >> > Since this is equivalent to:
> >> >
> >> >     let array = [ item, item, " comment  item, ]
> >> >
> >> > Simple solutions will such as using \" fail, because just about anything
> >> > following the backslash is valid if we are inside a string:
> >> >
> >> >     echo "some
> >> >             \ word
> >> >             \" comment
> >> >             \ word
> >> >
> >> > Is equivalent to the valid command:
> >> >
> >> >     echo "some word" comment word
> >> >
> >> > So, a line starting with a backslash can't be used for a comment.
> >> > Thinking about what would work (that is, currently it is an error), I
> >> > thought of using |\":
> >> >
> >> >     let array = [
> >> >             \ item,
> >> >             |\" comment
> >> >             \ item,
> >> >             \]
> >> >
> >> > It looks a bit weird, but it would work.  Any thoughts?
> >> >
> >>
> >> I like this.
> >>
> >> https://go-gyazo.appspot.com/04e22439cfdc859e.png
> >>
> >> Most of people expect comments can be written as syntax is.
> >
> > Unfortunately, that currently is valid syntax, especially when the line
> > continuation is used for a long string.  The parsing happens after all
> > the continuation lines are joined, it's not really possible before that.
> 
> It is indeed is valid syntax, but is it used anywhere? When
> floating-point numbers were introduced into Vim, it was decided that
> using 1.5 to mean "the floating number one and a half" rather than, as
> before, "the string form of the integer 1 concatenated to the string
> form of the integer 5", i.e. the string "15" wasn't harmful.

An important difference is that there is no reason to write 1.5 to get
"15".  It's quite safe to assume that nobody has written that in a script.
While it is very well possible that someone wrote:

        let s = "
           \some text
           \ some more text
           \"

It's actually quite nice to be able to write it that way, we should not
stop supporting that.

> Would it be harmful to require than long strings be represented as
> 
>    "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
> \. "bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb"
> \. "ccccccccccccccccccccccccccccccccccc"
> 
> with both quotation marks on the same physical line and concatenation
> by . if necessary, and not
> 
>     "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
>     \bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
>     \ccccccccccccccccccccccccccccccccccc"
> 
> with a long string expanding over two or more continued lines? If it
> wouldn"t, then I suppose it would be possible to add to the parser a
> "preprocessor" whose sole task would be to remove comments (from the
> unpaired double-quote to the end of the physical line regardless of a
> possible continuation line). There would be an ambiguity in the case
> of more than one double quote on a single line, but that is already
> handled in the case of strings vs. comments in expressions, or when
> using registers in the operand of :normal, or anywhere in the case of
> @" which does not _have_ to be represented by @@

Currently the parsing happens after joining all the continuation lines.
To do what you want we would need to join a line, parse it, join another
line, parse it, etc.  The only way parsing works reliably is to do it
from the start.  Starting the parsing at an arbitrary part of the line
isn't really possible.  You never know where the continuation happens.
And parsing the line multiple times is a big performance penalty.

> Fixed-form COBOL (the only kind I knew), where comments had to be on
> their own lines (with an asterisk in column 7 IIRC), and continuation
> lines had a dash in the otherwise unused column 7, had strict rules
> about how to represent quoted strings (which could be up to 120
> characters long) on punched cards where the useful part of unlabeled
> lines was 61 characters including the starting quote (from column 12
> to column 72 inclusive) but these are not germane to Vim and I do not
> propose to introduce anything similar into Vim script language.

Well, the special character sequence to put in front of a comment in
between continuation lines is something like that.

> The alternative to Yatsuhiro's proposal, which is elegant and which I
> endorse despite its break with backward compatibility, is to break
> expressions over comments, which can already be done with the current
> code, and would remain valid syntax with unchanged meaning even if we
> introduce this change, but is ugly (see my previous post in this
> thread).

-- 
The problem with political jokes is that they get elected.

 /// Bram Moolenaar -- [email protected] -- http://www.Moolenaar.net   \\\
///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\  an exciting new programming language -- http://www.Zimbu.org        ///
 \\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

-- 
-- 
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

Raspunde prin e-mail lui