[vim/vim] Add support for sourcing a script from the current buffer (PR #9967)
Yegappan Lakshmanan
This is based on the feature supported in Neovim with some enhancements.
Parts of the following commits are in this PR:
Commit: 4d5dbea4f402c76de4419977f7f89d3dec572510
Author: Vikram Pal vikram...@gmail.com
Commit: afdc9e61502a9f02c8cf5156652a1bde027e4345
Author: Sean Dewar sean...@users.noreply.github.com
Commit: d4ed51eb4492d4358eb4ab0c939802f2a5fdc636
Author: Sean Dewar sean...@users.noreply.github.com
Commit: 6188926e00081ae4b1a33d5fd12692a6749a2144
Author: Sean Dewar sean...@users.noreply.github.com
You can view, comment on, or merge this pull request online at:
https://github.com/vim/vim/pull/9967
Commit Summary
- fd4d575 Add support for sourcing a script from the current buffer
File Changes
(9 files)
- M runtime/doc/repeat.txt (9)
- M runtime/doc/todo.txt (6)
- M src/alloc.c (2)
- M src/charset.c (26)
- M src/ex_cmds.h (4)
- M src/proto/charset.pro (2)
- M src/proto/scriptfile.pro (1)
- M src/scriptfile.c (214)
- M src/testdir/test_source.vim (155)
Patch Links:
—
Reply to this email directly, view it on GitHub.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.
codecov[bot]
Codecov Report
Merging #9967 (b112a62) into master (1d9cef7) will decrease coverage by
2.72%.
The diff coverage is87.87%.
@@ Coverage Diff @@ ## master #9967 +/- ## ========================================== - Coverage 83.57% 80.84% -2.73% ========================================== Files 154 152 -2 Lines 175855 174430 -1425 Branches 39533 39548 +15 ========================================== - Hits 146966 141023 -5943 - Misses 16848 20755 +3907 - Partials 12041 12652 +611
| Flag | Coverage Δ | |
|---|---|---|
| huge-clang-none | 82.31% <87.87%> (+<0.01%) |
⬆️ |
| huge-gcc-none | ? |
|
| huge-gcc-unittests | 2.01% <0.00%> (-0.01%) |
⬇️ |
| linux | 80.84% <87.87%> (-2.73%) |
⬇️ |
Flags with carried forward coverage won't be shown. Click here to find out more.
| Impacted Files | Coverage Δ | |
|---|---|---|
| src/alloc.c | 79.04% <0.00%> (ø) |
|
| src/scriptfile.c | 83.17% <87.50%> (-0.39%) |
⬇️ |
| src/charset.c | 81.77% <100.00%> (-0.39%) |
⬇️ |
| src/libvterm/src/rect.h | 0.00% <0.00%> (-96.78%) |
⬇️ |
| src/libvterm/src/state.c | 34.80% <0.00%> (-54.37%) |
⬇️ |
| src/libvterm/src/keyboard.c | 40.00% <0.00%> (-47.63%) |
⬇️ |
| src/libvterm/include/vterm.h | 0.00% <0.00%> (-44.45%) |
⬇️ |
| src/libvterm/src/parser.c | 55.41% <0.00%> (-40.47%) |
⬇️ |
| src/libvterm/src/pen.c | 44.37% <0.00%> (-39.33%) |
⬇️ |
| src/libvterm/src/encoding.c | 37.37% <0.00%> (-36.16%) |
⬇️ |
| ... and 132 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 1d9cef7...b112a62. 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.
Maxim Kim
Is it legacy vimscript only?
—
Reply to this email directly, view it on GitHub.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.
Maxim Kim
Indeed it is, at least according to the test I can see.
So the source command would behave differently for vim9script buffers?
source %would work finesourceor%sourcewould fail?
—
Reply to this email directly, view it on GitHub.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.
Shane-XB-Qian
it sounds like another/alternative import ..
—
Reply to this email directly, view it on GitHub.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.
Yegappan Lakshmanan
Indeed it is, at least according to the test I can see.
So the source command would behave differently for vim9script buffers?
source %would work finesourceor%sourcewould fail?
vim-dev ML
On Fri, Mar 18, 2022 at 12:30 AM Maxim Kim ***@***.***>
wrote:
> Indeed it is, at least according to the test I can see.
>
> So the source command would behave differently for vim9script buffers?
>
> 2. source or %source would fail?
>
>
>
Sourcing a vim9 script from a buffer can be supported in a future PR.
Regards,
Yegappan
—
Reply to this email directly, view it on GitHub.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.
Maxim Kim
Sourcing a vim9 script from a buffer can be supported in a future PR.
Nice, thank you.
—
Reply to this email directly, view it on GitHub.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you commented.
Yegappan Lakshmanan
On Fri, Mar 18, 2022 at 3:41 AM Shane-XB-Qian <vim-dev...@256bit.org> wrote:
>
> it sounds like another/alternative import ..
>
command is an existing
command to source Vim scripts. It sources Vim Ex commands from a file.
This PR adds
support for sourcing the Ex commands from the current buffer. This is
useful for quickly
trying out a fragment of a Vim script. There is a already an item in
the todo list for this
support.
Regards,
Yegappan
Bram Moolenaar
Instead of concatenating all the lines into one long buffer, allocate each line separately and make the growarray a list of pointers to the lines. Avoids a very long string when the buffer is big, and avoids the need to split it again later. Even the "STRLEN(p->buf)" at the start of get_str_line() is quite inefficient.
There should be a test that "1,3source fname" fails.
The help should mention "[range] source" separately, mentioning "[range]" and "[fname]" together is confusing.
—
Reply to this email directly, view it on GitHub.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you commented.
matveyt
I remember I checked how this feature works in Neovim with respect to SID. They allocate a new anonymous SID (unvisible in scriptnames output) as soon as source tries to access it. So running the same "ranged" source twice (may) result in two new SIDs. Is this how it's done in this PR too? Or is there some more clever implementation?
—
Reply to this email directly, view it on GitHub.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you commented.
Bram Moolenaar
@matveyt: it should use the same SID for a buffer, based on the buffer number.
—
Reply to this email directly, view it on GitHub.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you commented.
Bram Moolenaar
—
Reply to this email directly, view it on GitHub.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you commented.
Yegappan Lakshmanan
I remember I checked how this feature works in Neovim with respect to SID. They allocate a new anonymous SID (unvisible in
scriptnamesoutput) as soon assourcetries to access it. So running the same "ranged" source twice (may) result in two new SIDs. Is this how it's done in this PR too? Or is there some more clever implementation?
vim-dev ML
On Fri, Mar 18, 2022 at 3:41 AM Shane-XB-Qian ***@***.***> wrote:
>
> it sounds like another/alternative import ..
>
This is not an alternative to the import mechanism. The ":source"
command is an existing
command to source Vim scripts. It sources Vim Ex commands from a file.
This PR adds
support for sourcing the Ex commands from the current buffer. This is
useful for quickly
trying out a fragment of a Vim script. There is a already an item in
the todo list for this
support.
Regards,
Yegappan
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Shane-XB-Qian
>
> This is not an alternative to the import mechanism. The ":source"
> command is an existing command to source Vim scripts.
i've forgot why i said that..
perhaps due to ':so' some functionality like 'import' do.. :-)
--
shane.xb.qian
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
vim-dev ML
On Sat, Mar 19, 2022 at 4:52 AM matveyt ***@***.***> wrote:
> I remember I checked how this feature works in Neovim with respect to SID.
> They allocate a new anonymous SID (unvisible in scriptnames output) as
> soon as source tries to access it. So running the same "ranged" source
> twice (may) result in two new SIDs. Is this how it's done in this PR too?
> Or is there some more clever implementation?
>
>
> I have modified that implementation. It uses the same script ID for a
given buffer.
Regards,
Yegappan
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Shane-XB-Qian
@yegappan @brammool
your guys' mailbox looks just free from jail this afternoon
// which i thought you were sleeping actually
// which should be not really you sent it at that time
since those mail looks were sent some months ago and duplicate............ :-)
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
Bram Moolenaar
I guess messages forwarding from the maillist to github is catching up with messages from around April.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
Christian Brabandt
FWIW: I have suspected missing messages for a while, but wasn't sure how this could happen.
I have no idea why this is now syncing old messages. 🤷 If this is too disturbing, I can disable the forwarding for a while.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you commented.