Repository navigation
Conversation
|
@dkearns You said in #21257 (comment) that you had a patch for this, so I waited a few (I feel like I've written this exact same thing to you before...) |
Are you actually complaining about delivery times again? I don't get paid enough just to deal with you, let alone meet your deadlines. I'm sorry you're losing sleep over a patch for a twenty-five-year-old bug, affecting no one, that you were neither diligent nor competent enough to notice yourself when excreting your latest feature addition. What's the hurry, is your subscription ending soon?
I must be getting old because I had to rack my brain to guess at what you were referring to here. Then it came to me, you might be pointing to that time you, bizarrely, created a PR to fix the As for this PR, sure merge it. It's relatively harmless, half-implemented, unidiomatic, and undocumented slop but it'll get fixed properly sooner or later. How's life on the push-button happy path? Are edge cases slowing your roll? I find it appalling that you are obviously one-shotting PRs for a three-decade-old project with the legacy of Vim. Sadly, I'm perfectly comfortable using this tone since you spend so much of your time running around this project snarling at other developers about how they're failing to respect your authority, like that little chap from South Park. |
|
A bug that nobody reports does not get fixed. An issue or a review A bug in a feature few people use is hard to notice. That is what Bringing an unreported bug out later as material for a personal attack |
|
closing here |
|
For the record, this is a different defect from the one #21346 fixes. The "endif" on line 3 is the text of the ":append", but it closes the |
Problem: Inside a block that is not executed, "if 0" for one, the text
of ":append", ":insert" and ":change" is read as commands: the
commands are not executed while skipping, so nothing reads the
lines up to the ".". A text line like "endif" then ends the
block. A ":source ++dryrun" has the same problem at the script
level. The three commands are also missing from the list at
":help :bar".
Solution: Execute the three commands while skipping, like ":function",
and only read the lines up to the "." then. Add them to the
":help :bar" list.
Assisted-by: Claude
Signed-off-by: Hirohito Higashi <[email protected]>
6573587 to
0222224
Compare
|
Thanks for reopening. Done. |
|
alright thanks |
… text as commands
Problem: In a block that is not executed, the text lines of :append,
:insert and :change are parsed as commands, so e.g. a text
line "endif" ends the block
Solution: Read and discard the text up to "." while skipping. Add the
commands to the ":help :bar" list.
closes: vim/vim#21331
vim/vim@ae8837c
Co-authored-by: Hirohito Higashi <[email protected]>
… text as commands
Problem: In a block that is not executed, the text lines of :append,
:insert and :change are parsed as commands, so e.g. a text
line "endif" ends the block
Solution: Read and discard the text up to "." while skipping. Add the
commands to the ":help :bar" list.
closes: vim/vim#21331
vim/vim@ae8837c
Co-authored-by: Hirohito Higashi <[email protected]>
| if false | ||
| append | ||
| enddef | ||
| . | ||
| endif |
There was a problem hiding this comment.
This seems wrong. In Vim9 script, :append leads to an error and doesn't consume any following lines when it's not skipped, so it shouldn't consume following lines when it's skipped either.
There was a problem hiding this comment.
You're right. thanks for following up on this!
… text as commands (#42196) Problem: In a block that is not executed, the text lines of :append, :insert and :change are parsed as commands, so e.g. a text line "endif" ends the block Solution: Read and discard the text up to "." while skipping. Add the commands to the ":help :bar" list. closes: vim/vim#21331 vim/vim@ae8837c Co-authored-by: Hirohito Higashi <[email protected]>
|
I wish I were incredulous that you'd pushed for the resurrection and merging of this PR, unmodified. Along with completely ignoring Vim9 handling, which has now been implemented at least twice, this PR also completely ignores Vim's unique autoindented end '.' marker behaviour in script files. I'm planning on making a case for removing support for indented '.' from scripts. It seems clear to me that it was only implemented as an interactive convenience in Vi but it's harder to be certain of the intent with Vim. Without giving it much thought over the years, I'd always assumed it was supposed to function like "trim". I'm waiting on someone to get back to me regarding a related reading of the POSIX spec and since the 'feature' has been around for a long time in Vim I wanted to do a decent survey of its usage. I had planned to remove it before bothering with skipping as it's impossible to properly support. This implementation also indulges the AI's fetish for pointless function extraction and early returns. If skipping was considered fixed properly we should also have updated the help to reflect that. @chrisbra cannot be expected review this flood of PRs in extreme detail and is relying on contributors to at least make a fair effort to get things right. Ten minutes of testing this by hand would turn up most of the problems. #21349 has more of the same and worse, from a quick skimming. |
… text as commands (neovim#42196) Problem: In a block that is not executed, the text lines of :append, :insert and :change are parsed as commands, so e.g. a text line "endif" ends the block Solution: Read and discard the text up to "." while skipping. Add the commands to the ":help :bar" list. closes: vim/vim#21331 vim/vim@ae8837c Co-authored-by: Hirohito Higashi <[email protected]>
4 participants
related: #21257