Fix internal command {} arguments: Comment "" and {fu}/{ou} NAME (#141)#159
Merged
Conversation
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: b53cc43825
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
…on (#141) An internal command (Protect/Comment/...) invoked with NAME={fu} or NAME={ou} previously did nothing or, for one code, mangled the result: the {} code was resolved to a string and fed back to function_build_list(), which routes a bare filename ({ou}) through find_entry() but a full path ({fu}) through the lock-file branch, losing the lister-entry link and the source-lister association. Treat such a NAME as 'operate on the current selection, keep it selected': - function_drop_brace_name_arg() clears the argument so function_build_list() gathers the live selection (with real lister entries); - function_run_instruction() rewinds the entry list and flags every entry FUNCENTF_NO_UNSELECT after argument expansion has consumed entries; - function_change() reselects the replacement entry (FCF_SELECT) when the no-unselect intent applies, since changing protection/comment/date replaces the lister entry and would otherwise clear its selected state. This makes {fu} and {ou} behave identically and matches the normal Protect/Comment flow, so the lister refreshes and the selection is preserved. The special handling fires only for a standalone {fu}/{ou} NAME - not an embedded form such as {fu}.info, which names specific files, nor commands invoked without such a NAME - so all other cases are byte-for-byte unaffected.
midwan
force-pushed
the
issue-141-internal-command-args
branch
from
June 3, 2026 16:40
b53cc43 to
1bb305f
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #141.
Two independent problems with the internal Protect/Comment commands.
Problem 3 —
Comment COMMENT=""could not clear a filenoteAn empty (or quoted-empty
""/'', whitespace-only) Comment argument now clears thefilenote. A shared helper
function_change_arg_empty()detects these cases; theDateStamp path reuses it.
Problem 1 —
Protect NAME={fu}/NAME={ou}did nothing (or misbehaved)For an internal command, a
{fu}/{ou}(no-unselect) NAME now means "operate on thecurrent selection and keep it selected":
function_drop_brace_name_arg()clears the argument sofunction_build_list()gathersthe live selection (with real lister entries) instead of the resolved control-byte
string. The old approach routed a bare filename (
{ou}) throughfind_entry()but afull path (
{fu}) into the lock-file branch, losing the lister-entry link and thesource-lister association.
function_run_instruction()rewinds the entry list and flags every entryFUNCENTF_NO_UNSELECT, so the whole selection is processed and stays selected.function_change()reselects the replacement entry (FCF_SELECT) — aprotection/comment/date change replaces the lister entry, which would otherwise drop
the selection on redraw.
The gate is scoped to the no-unselect codes, so commands not invoked with
{fu}/{ou}are byte-for-byte unaffected.
Problem 2 from the issue (Protect with nothing ticked affecting all selected files) is
intentionally left out of scope.
Verification
{fu}and{ou}apply+s, the listerauto-refreshes, and the selection is preserved;
Comment ""clears the filenote.i386-AROS (ABIv0), x86_64-AROS (ABIv11).