remove redundant code #13301
remove redundant code #13301
Conversation
x % 1 = 0
| --s; | ||
| if ((*p == ' ' && (xp->xp_backslash == XP_BS_THREE && (p - s) < 3)) | ||
| || (*p == ',' && (flags & P_COMMA) && ((p - s) % 1) == 0) | ||
| || (*p == ',' && (flags & P_COMMA)) |
There was a problem hiding this comment.
what if (p -s ) is negative?
There was a problem hiding this comment.
Is it still not zero?
There was a problem hiding this comment.
I'm not sure. (but probably)
There was a problem hiding this comment.
I pointed out what the logic is doing elsewhere already but either way p-s cannot be negative here. s is counted down from p in the above line.
|
This line exists for a reason, albeit it's buggy and doesn't do anything… It was pointed out in #13182 (comment) too. I was working on a PR to fix it and it's basically working but haven't sent it out yet, so I just made the PR right now: #13303. The correct logic is The PR has more explanation, but basically when you are doing cmdline expansion for a comma-separated list, let's say you have |
|
Sorry I really meant the flipped logic. It should be |
|
So for example,
That's why it's an inequality check just like the You need one fewer backslash in Windows because in Windows, patterns like As pointed out in the PR, |
|
OK, looks like this will be correctly handled in #13303 then. |
|
Just a minor question: What's the rationale for this PR? Was it triggered by some static analyzers? I think we should be a little careful deleting "unused logic" like this because they usually contain some intention behind them, even if buggy. I think if it's blatantly useless like this, we should try to make sure to understand the intention behind them first as blanket deletion makes debugging harder later as you lose the context. I do admit understanding the full intention could be a little time consuming as it requires essentially unwinding the stack (and the author of said logic isn't around to answer them anymore), but I think otherwise it's better to leave them be. |
|
I understand. I'll try to not to send these types of fixes anymore then. @zeertzjq for reference ☝️ |
When something like this is encountered, as @ychin states
A PR with a comment like might be good. |
|
Sorry, I wasn't trying to discourage such effort. I'm just pointing out that it could be worth tagging these as potential bugs (as was in this case) since they tend to reflect a mismatch of expectations of a programmer and what the code is actually doing. So it's definitely useful to detect these. I'm just advising against deleting them unless we have a fair idea why it was written to begin with. |
This comment was marked as off-topic.
This comment was marked as off-topic.
Problem: cmdline-completion for comma-separated options wrong
Solution: Fix command-line expansions for options with filenames with
commas
Fix command-line expansions for options with filenames with commas
Cmdline expansion for option values that take a comma-separated list
of file names is currently not handling file names with commas as the
commas are not escaped. For such options, the commas in file names need
to be escaped (to differentiate from a comma that delimit the list
items). The escaped comma is unescaped in `copy_option_part()` during
option parsing.
Fix as follows:
- Cmdline completion for option values with comma-separated file/folder
names will not start a new match when seeing `\\,` and will instead
consider it as one value.
- File/folder regex matching will strip the `\\` when seeing `\\,` to
make sure it can match the correct files/folders.
- The expanded value will escape `,` with `\\,`, similar to how spaces
are escaped to make sure the option value is correct on the cmdline.
This fix also takes into account the fact that Win32 Vim handles file
name escaping differently. Typing '\,' for a file name results in it
being handled literally but in other platforms '\,' is interpreted as a
simple ',' and commas need to be escaped using '\\,' instead.
Also, make sure this new logic only applies to comma-separated options
like 'path'. Non-list options like 'set makeprg=<Tab>' and regular ex
commands like `:edit <Tab>` do not require escaping and will continue to
work.
Also fix up documentation to be clearer. The original docs are slightly
misleading in how it discusses triple slashes for 'tags'.
closes: #13303
related: #13301
Signed-off-by: Christian Brabandt <[email protected]>
Co-authored-by: Yee Cheng Chin <[email protected]>
Problem: cmdline-completion for comma-separated options wrong
Solution: Fix command-line expansions for options with filenames with
commas
Fix command-line expansions for options with filenames with commas
Cmdline expansion for option values that take a comma-separated list
of file names is currently not handling file names with commas as the
commas are not escaped. For such options, the commas in file names need
to be escaped (to differentiate from a comma that delimit the list
items). The escaped comma is unescaped in `copy_option_part()` during
option parsing.
Fix as follows:
- Cmdline completion for option values with comma-separated file/folder
names will not start a new match when seeing `\\,` and will instead
consider it as one value.
- File/folder regex matching will strip the `\\` when seeing `\\,` to
make sure it can match the correct files/folders.
- The expanded value will escape `,` with `\\,`, similar to how spaces
are escaped to make sure the option value is correct on the cmdline.
This fix also takes into account the fact that Win32 Vim handles file
name escaping differently. Typing '\,' for a file name results in it
being handled literally but in other platforms '\,' is interpreted as a
simple ',' and commas need to be escaped using '\\,' instead.
Also, make sure this new logic only applies to comma-separated options
like 'path'. Non-list options like 'set makeprg=<Tab>' and regular ex
commands like `:edit <Tab>` do not require escaping and will continue to
work.
Also fix up documentation to be clearer. The original docs are slightly
misleading in how it discusses triple slashes for 'tags'.
closes: vim/vim#13303
related: vim/vim#13301
vim/vim@5484485
Co-authored-by: Yee Cheng Chin <[email protected]>
Problem: cmdline-completion for comma-separated options wrong
Solution: Fix command-line expansions for options with filenames with
commas
Fix command-line expansions for options with filenames with commas
Cmdline expansion for option values that take a comma-separated list
of file names is currently not handling file names with commas as the
commas are not escaped. For such options, the commas in file names need
to be escaped (to differentiate from a comma that delimit the list
items). The escaped comma is unescaped in `copy_option_part()` during
option parsing.
Fix as follows:
- Cmdline completion for option values with comma-separated file/folder
names will not start a new match when seeing `\\,` and will instead
consider it as one value.
- File/folder regex matching will strip the `\\` when seeing `\\,` to
make sure it can match the correct files/folders.
- The expanded value will escape `,` with `\\,`, similar to how spaces
are escaped to make sure the option value is correct on the cmdline.
This fix also takes into account the fact that Win32 Vim handles file
name escaping differently. Typing '\,' for a file name results in it
being handled literally but in other platforms '\,' is interpreted as a
simple ',' and commas need to be escaped using '\\,' instead.
Also, make sure this new logic only applies to comma-separated options
like 'path'. Non-list options like 'set makeprg=<Tab>' and regular ex
commands like `:edit <Tab>` do not require escaping and will continue to
work.
Also fix up documentation to be clearer. The original docs are slightly
misleading in how it discusses triple slashes for 'tags'.
closes: vim/vim#13303
related: vim/vim#13301
vim/vim@5484485
Co-authored-by: Yee Cheng Chin <[email protected]>
Problem: cmdline-completion for comma-separated options wrong
Solution: Fix command-line expansions for options with filenames with
commas
Fix command-line expansions for options with filenames with commas
Cmdline expansion for option values that take a comma-separated list
of file names is currently not handling file names with commas as the
commas are not escaped. For such options, the commas in file names need
to be escaped (to differentiate from a comma that delimit the list
items). The escaped comma is unescaped in `copy_option_part()` during
option parsing.
Fix as follows:
- Cmdline completion for option values with comma-separated file/folder
names will not start a new match when seeing `\\,` and will instead
consider it as one value.
- File/folder regex matching will strip the `\\` when seeing `\\,` to
make sure it can match the correct files/folders.
- The expanded value will escape `,` with `\\,`, similar to how spaces
are escaped to make sure the option value is correct on the cmdline.
This fix also takes into account the fact that Win32 Vim handles file
name escaping differently. Typing '\,' for a file name results in it
being handled literally but in other platforms '\,' is interpreted as a
simple ',' and commas need to be escaped using '\\,' instead.
Also, make sure this new logic only applies to comma-separated options
like 'path'. Non-list options like 'set makeprg=<Tab>' and regular ex
commands like `:edit <Tab>` do not require escaping and will continue to
work.
Also fix up documentation to be clearer. The original docs are slightly
misleading in how it discusses triple slashes for 'tags'.
closes: vim/vim#13303
related: vim/vim#13301
vim/vim@5484485
Co-authored-by: Yee Cheng Chin <[email protected]>
…ong (#25569) Problem: cmdline-completion for comma-separated options wrong Solution: Fix command-line expansions for options with filenames with commas Fix command-line expansions for options with filenames with commas Cmdline expansion for option values that take a comma-separated list of file names is currently not handling file names with commas as the commas are not escaped. For such options, the commas in file names need to be escaped (to differentiate from a comma that delimit the list items). The escaped comma is unescaped in `copy_option_part()` during option parsing. Fix as follows: - Cmdline completion for option values with comma-separated file/folder names will not start a new match when seeing `\\,` and will instead consider it as one value. - File/folder regex matching will strip the `\\` when seeing `\\,` to make sure it can match the correct files/folders. - The expanded value will escape `,` with `\\,`, similar to how spaces are escaped to make sure the option value is correct on the cmdline. This fix also takes into account the fact that Win32 Vim handles file name escaping differently. Typing '\,' for a file name results in it being handled literally but in other platforms '\,' is interpreted as a simple ',' and commas need to be escaped using '\\,' instead. Also, make sure this new logic only applies to comma-separated options like 'path'. Non-list options like 'set makeprg=<Tab>' and regular ex commands like `:edit <Tab>` do not require escaping and will continue to work. Also fix up documentation to be clearer. The original docs are slightly misleading in how it discusses triple slashes for 'tags'. closes: vim/vim#13303 related: vim/vim#13301 vim/vim@5484485 Co-authored-by: Yee Cheng Chin <[email protected]>
This comment was marked as off-topic.
This comment was marked as off-topic.
5 participants
x % 1 = 0