[vim/vim] WIP: Add support for evaluating expression in a heredoc (PR #10138)
Yegappan Lakshmanan
You can view, comment on, or merge this pull request online at:
https://github.com/vim/vim/pull/10138
Commit Summary
- bb43803 Add support for evaluating expression in a heredoc
File Changes
(5 files)
- M runtime/doc/eval.txt (15)
- M runtime/pack/dist/opt/termdebug/plugin/termdebug.vim (4)
- M src/evalvars.c (99)
- M src/testdir/test_let.vim (18)
- M src/userfunc.c (21)
Patch Links:
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
codecov[bot]
Codecov Report
Merging #10138 (bb43803) into master (6013d00) will decrease coverage by
79.96%.
The diff coverage is0.00%.
@@ Coverage Diff @@ ## master #10138 +/- ## =========================================== - Coverage 81.97% 2.00% -79.97% =========================================== Files 167 152 -15 Lines 187863 170890 -16973 Branches 42368 39537 -2831 =========================================== - Hits 153999 3432 -150567 - Misses 21517 166763 +145246 + Partials 12347 695 -11652
| Flag | Coverage Δ | |
|---|---|---|
| huge-clang-none | ? |
|
| huge-gcc-none | ? |
|
| huge-gcc-testgui | ? |
|
| huge-gcc-unittests | 2.00% <0.00%> (-0.01%) |
⬇️ |
| linux | 2.00% <0.00%> (-81.97%) |
⬇️ |
| mingw-x64-HUGE | ? |
|
| mingw-x64-HUGE-gui | ? |
|
| windows | ? |
Flags with carried forward coverage won't be shown. Click here to find out more.
| Impacted Files | Coverage Δ | |
|---|---|---|
| src/evalvars.c | 4.46% <0.00%> (-86.87%) |
⬇️ |
| src/userfunc.c | 0.13% <0.00%> (-89.55%) |
⬇️ |
| src/libvterm/src/rect.h | 0.00% <0.00%> (-96.78%) |
⬇️ |
| src/sha256.c | 0.00% <0.00%> (-96.45%) |
⬇️ |
| src/libvterm/src/parser.c | 0.00% <0.00%> (-95.91%) |
⬇️ |
| src/gui_gtk_f.c | 0.00% <0.00%> (-94.72%) |
⬇️ |
| src/crypt_zip.c | 0.00% <0.00%> (-94.12%) |
⬇️ |
| src/vim9compile.c | 0.00% <0.00%> (-92.42%) |
⬇️ |
| src/debugger.c | 0.00% <0.00%> (-92.23%) |
⬇️ |
| src/eval.c | 0.10% <0.00%> (-92.18%) |
⬇️ |
| ... and 155 more |
Continue to review full report at Codecov.
Legend - Click here to learn more
Δ = absolute <relative> (impact),ø = not affected,? = missing data
Powered by Codecov. Last update 6013d00...bb43803. Read the comment docs.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Yegappan Lakshmanan
@yegappan pushed 1 commit.
- 77b0f0f Handle some corner conditions and add Vim9 test
—
View it on GitHub or unsubscribe.
You are receiving this because you are subscribed to this thread.
Yegappan Lakshmanan
@yegappan pushed 2 commits.
You are receiving this because you are subscribed to this thread.
Bram Moolenaar
Let's leave this open a few days to allow for comments.
I'm not sure if we should use =expr or just expr. Compared to other places in Vim =expr would be more common,
but compared to any other language expr would be preferred.
The help is not clear: can the expression span multiple lines? So I could use
some literal text `=
expr line
expr line
` more literal text
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Yegappan Lakshmanan
Let's leave this open a few days to allow for comments.
I'm not sure if we should use
=expror justexpr. Compared to other places in Vim=exprwould be more common,
but compared to any other languageexprwould be preferred.The help is not clear: can the expression span multiple lines? So I could use
vim-dev ML
On Sun, Apr 10, 2022 at 11:25 AM Bram Moolenaar ***@***.***>
wrote:
> Let's leave this open a few days to allow for comments.
>
> I'm not sure if we should use =expr or just expr. Compared to other
> places in Vim =expr would be more common,
> but compared to any other language expr would be preferred.
>
> The help is not clear: can the expression span multiple lines? So I could
> use
>
An expression must be within a single line and cannot span multiple lines.
I will update the help to reflect this.
Regards,
Yegappan
> some literal text `=
> expr line
> expr line
> ` more literal text
>
>
>
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
lacygoill
I'm not sure if we should use =expr or just expr. Compared to other places in Vim =expr would be more common,
but compared to any other language expr would be preferred.
Yes, I suggested backtick equal to be as consistent as possible with the existing syntax, but in practice I suspect it's hardly ever used. Dropping the equal sign might make it easier for people coming from other languages to assimilate this new syntax.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
Yegappan Lakshmanan
I'm not sure if we should use =expr or just expr. Compared to other places in Vim =expr would be more common,
but compared to any other language expr would be preferred.Yes, I suggested
backtick equalto be as consistent as possible with the existing syntax, but in practice I suspect it's hardly ever used. Dropping the equal sign might make it easier for people coming from other languages to assimilate this new syntax.
vim-dev ML
On Sun, Apr 10, 2022 at 8:53 PM lacygoill ***@***.***> wrote:
> I'm not sure if we should use =expr or just expr. Compared to other places
> in Vim =expr would be more common,
> but compared to any other language expr would be preferred.
>
> Yes, I suggested backtick equal to be as consistent as possible with the
> existing syntax, but in practice I suspect it's hardly ever used. Dropping
> the equal sign might make it easier for people coming from other languages
> to assimilate this new syntax.
>
>
>
Should we support using only backtick for expanding the Vim expression in a
heredoc?
Thanks,
Yegappan
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Bram Moolenaar
> On Sun, Apr 10, 2022 at 11:25 AM Bram Moolenaar <vim-dev...@256bit.org>
> wrote:
>
> > Let's leave this open a few days to allow for comments.
> >
> > I'm not sure if we should use =expr or just expr. Compared to other
> > places in Vim =expr would be more common,
> > but compared to any other language expr would be preferred.
> >
> > The help is not clear: can the expression span multiple lines? So I could
> > use
>
> An expression must be within a single line and cannot span multiple lines.
> I will update the help to reflect this.
be a variable or something like "shellescape(bufname(bnr))".
--
ARTHUR: Be quiet! I order you to shut up.
OLD WOMAN: Order, eh -- who does he think he is?
ARTHUR: I am your king!
OLD WOMAN: Well, I didn't vote for you.
"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD
/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
vim-dev ML
> On Sun, Apr 10, 2022 at 11:25 AM Bram Moolenaar ***@***.***>
> wrote:
>
> > Let's leave this open a few days to allow for comments.
> >
> > I'm not sure if we should use =expr or just expr. Compared to other
> > places in Vim =expr would be more common,
> > but compared to any other language expr would be preferred.
> >
> > The help is not clear: can the expression span multiple lines? So I could
> > use
>
> An expression must be within a single line and cannot span multiple lines.
> I will update the help to reflect this.
I suppose that will cover most use cases. I expect most use will just
be a variable or something like "shellescape(bufname(bnr))".
--
ARTHUR: Be quiet! I order you to shut up.
OLD WOMAN: Order, eh -- who does he think he is?
ARTHUR: I am your king!
OLD WOMAN: Well, I didn't vote for you.
"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD
/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Bram Moolenaar
The help says "If the expression evaluation fails, then it is replaced with an empty string."
I think it's better to treat an error like an error and not silently use an empty string.
If you would have an assignment with a faling expression, it would also fail.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
Yegappan Lakshmanan
Yegappan Lakshmanan
The help says "If the expression evaluation fails, then it is replaced with an empty string."
I think it's better to treat an error like an error and not silently use an empty string.
If you would have an assignment with a faling expression, it would also fail.
I have updated the PR to fail the assignment if an expression evaluation fails.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
Yegappan Lakshmanan
@yegappan pushed 1 commit.
- 3d84a66 Add support for evaluating expression in a heredoc
Bram Moolenaar
I have not seen comments objecting to using the "=expr" form, including the equal sign. So I guess it should be OK that way.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
Bram Moolenaar
When adding another test I found that this doesn't work:
var x = 'X'
code =<< eval trim END
let b = `=x`
END
This will require more work, since "x" would have to be evaluated at runtime. Let's do that in a followup change.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
Bram Moolenaar
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
Yegappan Lakshmanan
I have not seen comments objecting to using the "
=expr" form, including the equal sign. So I guess it should be OK that way.
vim-dev ML
On Sun, Apr 17, 2022 at 3:51 AM Bram Moolenaar ***@***.***>
wrote:
> I have not seen comments objecting to using the "=expr" form, including
> the equal sign. So I guess it should be OK that way.
>
>
>
If you think using a single backquote will be easier and less confusing
than using "`=",
then we can still change this.
Regards,
Yegappan
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
errael
I've never use vimscript, or the = that I see around occasionally. From my perspective, whatever is consistent with what I'll see in vim9script is best; :help script explains vim9. Consistency with vim9 seems paramount. IMO, if the = is required in vim9 in situations, then OK; otherwise nuke it.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
Bram Moolenaar
> I've never use vimscript, or the `=` that I see around occasionally.
> From my perspective, whatever is consistent with what I'll see in
> vim9script is best; `:help script` explains vim9. Consistency with
> vim9 seems paramount. IMO, if the `=` is required in vim9 in
> situations, then OK; otherwise nuke it.
syntax. On the command line this has been used in places where
expanding $VAR is insufficient, and uses the shell to evaluate the
expression. I believe other programs also support using backticks to
expand an expression, possibly with the shell.
Later we wanted to use a Vim expression, which is where `=expr` was
introduced. I don't think any other application does this.
So we can choose here to be more similar to other applications, just
using backtics, or be consistent with what is done on the command line,
using `=expr`.
I can't really think of a reason for one or the other. One slight
advantage of using `=expr` is that backticks can be used anywhere, only
`= is special, which should be quite rare.
--
hundred-and-one symptoms of being an internet addict:
10. And even your night dreams are in HTML.
/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
Shane-XB-Qian
correct the syntax highlight when with/without trim and eval as well..
// currently it is broken.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
Shane-XB-Qian
Bram Moolenaar
@cecamp for the highlighting
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.