-
Notifications
You must be signed in to change notification settings - Fork 269
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
alias.many
suffers from lingering parsing issues, and also incompatible with numberedArgs of some commands
#1327
Comments
alias.many
can't be used with find
to copy a namespace without historyalias.many
can't be used with find
or ls
to copy a namespace without history
Same problem with |
Bummer, that was an oversight. Intended to work the way you expected. The problem imo is that numberedArgs needs different contents depending on what you plan to do with them. In this case (and probably only this case!) you want it to contain relative names, as alias.many is only well defined over relative names. A case when you don’t want relative names IMO is One solution I see would be to include multiple forms in the numberedArgs, and have the consumer pick the one that makes sense for it? But that would be a bit of work.
Say more? |
Oh, I just re-read your comment. If |
Another fix could be the “represent all paths as absolute, and apply an optional currentpath in some cases for parsing, printing, resolving” thing. ref #1298 Then you can alias.many any previous find results that happen to be in or below your currentPath, regardless of where you were when you found them. |
@aryairani FYI
What do you think best next step is here? I was trying to create |
@pchiusano Sorry, okay — the absolute name thing must've been something I adopted later than I think I can work on it or pair on it if you want; I have 2 open tasks on my stack currently though. |
Update: it seems to be something screwy when copying symboly ids:
If you constrain your copying to just non-symbolic ids, it works okay. |
Reminiscent of #763; recommend killing the ucm indentifier parsers with fire, per our conversation. |
@pchiusano I haven't yet been able to replicate the parsing issue at the repl. When you have a chance, could you post the |
|
@pchiusano Sorry for not noticing that you had included the |
Okay, so this looks like exactly #763: the bug prevents us from operating on unqualified symboly names. In your first example, it would break on the unqualified In the second example, it would break on the unqualified A workaround for the first case would be to issue the That said, this is a super annoying bug that we should fix. I'm going to take it off the top of my stack for now until we get another chance to chat and/or pair. |
Now that #763 is fixed,
|
alias.many
can't be used with find
or ls
to copy a namespace without historyalias.many
suffers from lingering parsing issues, and also incompatible with numberedArgs of some commands
Reading through the thread, I think the only remaining problem (not covered by another issue) is that
I wholeheartedly support this approach. It‘s the same thing I did in my path library, after being frustrated with never being sure where relative paths were going to resolve.
I suppose it’s implied by my above statement, but I agree that What I don’t understand is why absolute numbered args can't easily work with Footnotes
|
wow TIL footnotes |
I think this should work, but doesn't:
Reason this doesn't work -
find
produces hash qualified numbered args andalias.many
doesn't accept hash qualified arguments.@aryairani I had thought this was a major use case for the command, copying a namespace without its history. I remember we'd considered a
merge.nohistory
command and went with this instead after thinking they had equivalent power.Seems like
alias.many
could just be made to work with hash qualified names and that would address the problem?The text was updated successfully, but these errors were encountered: