Skip to content

Conversation

@heaths
Copy link
Contributor

@heaths heaths commented Oct 8, 2024

Resolves #9704

@heaths heaths requested a review from a team as a code owner October 8, 2024 09:12
@heaths heaths requested a review from andyfeller October 8, 2024 09:12
@cliAutomation cliAutomation added the external pull request originating outside of the CLI core team label Oct 8, 2024
@jtmcg jtmcg self-requested a review October 8, 2024 21:30
@heaths
Copy link
Contributor Author

heaths commented Oct 9, 2024

@jtmcg this is ready. I rebased on trunk as well.

@heaths heaths changed the title Add gist search command Supporting filtering on gist list Oct 9, 2024
@heaths
Copy link
Contributor Author

heaths commented Oct 9, 2024

I have a change nearly ready to highlight the search terms in the displayed text, which really only includes the description. This refactors the highlighting in gh search code as well to be consistent and open it up for other use.

I wanted to wait to finish it because:

  1. It may be a little confusing to only see (potentially) some highlights and not others (because the file names or code match and aren't shown).
  2. I need to solve a problem - not hard, but annoying - that the descriptions are subtly (to the point I didn't even noticed in my terminal) made bold when printed, so if I highlight that overwrites the previous bold foreground, so I have to restore it after the highlight(s). Again, not hard, but before I went through that I wanted to see if anyone is on board with highlighting matches e.g.,

image

Copy link
Contributor

@jtmcg jtmcg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good! I do like the idea of syntax highlighting, but you're right - it may be awkward without showing the filenames or text that is also being filtered on.

We had discussed that maybe there's an opportunity to add a new type of TTY output to allow for showing files and their text, but perhaps that's a follow-up PR.

Anyway, I've really only got one comment that I've pushed a commit on 🙌 Let me know your thoughts on it

Copy link
Contributor Author

@heaths heaths left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Change looks good considering the comment already seems to imply that:

Include gists' file content when filtering

@heaths
Copy link
Contributor Author

heaths commented Oct 11, 2024

We had discussed that maybe there's an opportunity to add a new type of TTY output to allow for showing files and their text, but perhaps that's a follow-up PR.

The thought had crossed my mind as well when I was looking at search for inspiration for the original gist search, which really did end up just filtering. My initial idea was to skip showing a table and instead show the gist ID and file name(s) along with content like search code:

image

This could be default if --filter was passed, or completely separate. If only when --filter is passed, I could see doing it in this PR or I could immediately follow up with another PR before the next release so there's no compat concern later.

...though, given this is now considered a filter, I wonder if that would be too jarring. You're filtering the list, so one might expect the same table to be rendered. To clarify, I wasn't married to gist search and not necessarily advocating for its return, but just wanted to put idea out there.

But even as implemented in this PR now, it's incredibly helpful. I tend to prototype a lot of ideas for the Azure SDKs for Rust I'm heading up now, and instead of letting https://play.rust-lang.org create a gist I can't change, I make my own along with a comment to open it in the playground (something I wish https://play.go.dev would support). I have tons of gists with main.rs and lib.rs files, not to mention the past decade or so of other gists I have e.g., lots of main.go files as well.

@heaths
Copy link
Contributor Author

heaths commented Oct 11, 2024

If desired, I have a change ready that would output something like this:

image

  • The gist ID, file name, and description are always printed if the filter matches any thing we pulled including the file names, description, and content.
  • Descriptions are printed with 4 spaces to offset them from code, which...
  • Matching code lines are printed 8 spaces over to match search code

Should we print this same thing if output is not to a TTY? gist list still prints a table without the headers, and no color. heaths#43 prints colors in a way that should already be conditional on IOStreams.ColorEnabled(), so this would be pretty easy to accommodate.

Comparatively, search code prints the following to non-TTY output, but I'm not sure where we'd stick the description. Do we perhaps consider the : a delimiter and format matches - given the same rules above - like so?

repo:name: description : matching line, if any

@andyfeller
Copy link
Member

Should we print this same thing if output is not to a TTY? gist list still prints a table without the headers, and no color. heaths#43 prints colors in a way that should already be conditional on IOStreams.ColorEnabled(), so this would be pretty easy to accommodate.

Comparatively, search code prints the following to non-TTY output, but I'm not sure where we'd stick the description. Do we perhaps consider the : a delimiter and format matches - given the same rules above - like so?

repo:name: description : matching line, if any

I like the gist description being included during TTY and don't see it is too disruptive to the existing experience in gh search code. I wouldn't change anything there.

I don't know if it makes sense breaking the non-TTY format of gh search code for gh gist list --filter with the description.

gh search code retry --owner cli | cat

Screenshot 2024-10-11 at 11 59 39 AM

So my knee jerk would be leaving out the description in non-TTY for now 🤷

Copy link
Member

@andyfeller andyfeller left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Having a chance to discuss the feature outside of the code changes, I think things look pretty solid so far. While waiting on the highlighting change alluded to, here are a few minor suggestions.

Thank you as always, @heaths, for continuing to improve gh ❤️

@heaths
Copy link
Contributor Author

heaths commented Oct 11, 2024

So my knee jerk would be leaving out the description in non-TTY for now

The gist without a description - and just a single matching line - is pretty useless, IMO. I have tons of gist with just a main.rs and a matching line tells me nothing about what that gist does. I think the description is necessary.

That said, I don't see any big reason to keep this non-TTY formatting. It's not truly : delimited because your code may have : that isn't likely escaped. So I don't see much point in trying to keep it compatible with some machine parsing format since it's not already machine parsable. Taking that a step further, since it's not made machine parsable (otherwise, just output JSON), why even bother changing the format? IMO, that non-TTY search code is a bit hard to read compared to the newline-separated search results for TTY, so why not just make the non-TTY output the non-colored output of gist list --filter now?

image

This looks much more readable to me. (I also see I should probably format non-printable characters similar to what cat -v does, but that's probably a separate PR since search code may need it as well.)

@heaths
Copy link
Contributor Author

heaths commented Oct 11, 2024

While waiting on the highlighting change alluded to

@andyfeller the changes are nearly ready in heaths#43. All I have to do is update tests but wanted to to wait on that (testing ANSI escape sequences spread out all over is time-consuming), I wanted to make sure we're settled on a course of action.

I still have some doubts whether drastically and implicitly changing the format just by passing --filter is the best idea. It does seem a little jarring. I still think it's the best output for seeing search results, but maybe this should be opt in, or I go back to gist search, though I appreciate this may be confusing if GitHub ever adds search capabilities to gists.

Accuweaty24 added a commit to Accuweaty24/cli that referenced this pull request Oct 11, 2024
Unless required by applicable law or agreed to in writing, software
   distributed under the License is distributed on an "AS IS" BASIS,
   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
   See the License for the specific language governing permissions and
   limitations under the License.
@probablycorey @matschaffer @digitalfu cli#9745 cli#9721 cli#9728 cli#9746 №accuweaty24 #
@jtmcg
Copy link
Contributor

jtmcg commented Oct 11, 2024

I still have some doubts whether drastically and implicitly changing the format just by passing --filter is the best idea. It does seem a little jarring. I still think it's the best output for seeing search results, but maybe this should be opt in, or I go back to gist search, though I appreciate this may be confusing if GitHub ever adds search capabilities to gists.

I like the opt-in idea. Why not introduce a flag for the alternative view? Something like --verbose-view (maybe verbose is overloaded, here) that indicates to the user they want to see all the extra information they've fetched? Leveraging the same flag could allow you to change the non-TTY output in a non-breaking way as well, which I think may satisfy @andyfeller's hesitation with adding the description to the non-TTY output.

This could also be a follow-up PR, so we can get this one in and make the QoL visual improvements next

@heaths
Copy link
Contributor Author

heaths commented Oct 11, 2024

Yeah, "verbose" doesn't sound right here; however, some variation on "view" makes sense. Let me review other commands for some inspiration. Maybe just --view {type}" with inspiration drawn from where ya'll have been taking for the JSON formatting flags in more recent commands e.g. project list --format {string}as opposed to the olderissue list --json {[]string}`.

I'd love to get @andyfeller's clarification on what he meant. I took it as not adding the description to what search code otherwise shows e.g., instead of my proposed:

{gist}:{filename}: {description} : {optional content}

He was saying do exactly what search code does:

{gist}:{filename}: {content}

However,

  1. Without the description, the gist ID (a GUID) and the filename are pretty much useless.
  2. The text match could be only in the description, so not showing it seems confusing.
  3. Content is optional in either case since the text may not be in the content so what do we show then?

Assuming I get time, I'll fix up my other PR to this one (or if you want to merge, then I can rebase the other PR) this weekend and proceed down the --view (or something similar; I'll think on it a little more) concept.

@heaths
Copy link
Contributor Author

heaths commented Oct 12, 2024

Another idea came to mind: what if the default table view highlighted in the description or x file(s) but we do this search code-like view if they pass --include-content? Thinking about this more, it just seems they're missing out on a better view for this purpose by default.

Or, what about gist find if "search" is potentially concerning? Or is that too subtle?

Here's a mock up of gist list --filter without --include-content for what I'm describing about:

image

@heaths
Copy link
Contributor Author

heaths commented Oct 12, 2024

I'm kinda liking this idea of showing search code-like results when passed --include-content only. The color package I added highlighting to already does the right thing (color to TTY, or no color otherwise) so it's really just a matter of highlighting results when passed --filter and showing content when passed --include-content:

image

You can see examples of the existing behavior, highlighting the table to TTY and non-TTY, and highlighting content to TTY and non-TTY (using more for example).

We don't need to add a new switch and I think the context makes sense. Thoughts?

I went ahead and merged heaths#43 so that if you agree this is best, it's ready to merge. Effectively, --filter just filters (but with highlighting) and only if people elect to include content do we actually show content in the search code-like format.

heaths and others added 9 commits October 12, 2024 23:17
Filter as we get results instead of getting them all. This allows us to more easily terminate pagination when opts.Limit is reached.
Also changes `--filter` argument to "expression" to coincide with some other commands' help text e.g., `--jq`.
Filtering can take a while, so show progress. This also uncovered a bug
that I wasn't checking if a filter was actually specified, resulting in
a non-nil `opts.Filter`.
When `--filter` is passed, matches will be highlighted in the existing table. If file names match, the "n file(s)" cell will be highlighted.

When `--include-content` is additionally passed, the file name, description, and/or content will be printed like `search code` with matches highlighted.
@jtmcg
Copy link
Contributor

jtmcg commented Oct 14, 2024

I'm fine with this approach, given --include-content is a new flag. What do you think, @andyfeller?

@andyfeller
Copy link
Member

andyfeller commented Oct 14, 2024

So my knee jerk would be leaving out the description in non-TTY for now

The gist without a description - and just a single matching line - is pretty useless, IMO. I have tons of gist with just a main.rs and a matching line tells me nothing about what that gist does. I think the description is necessary.

That is fair. My suggestion was primarily based on 1) the perspective that gh search code doesn't report any file-level comments or metadata about its purpose either; allowing the outputs to be similar and 2) the non-TTY output is already busy and hard to read without another bit of information. Again, I get the preference for including the gist title.

That said, I don't see any big reason to keep this non-TTY formatting. It's not truly : delimited because your code may have : that isn't likely escaped. So I don't see much point in trying to keep it compatible with some machine parsing format since it's not already machine parsable. Taking that a step further, since it's not made machine parsable (otherwise, just output JSON), why even bother changing the format? IMO, that non-TTY search code is a bit hard to read compared to the newline-separated search results for TTY, so why not just make the non-TTY output the non-colored output of gist list --filter now?

I'm down with this in all honesty.

I still have some doubts whether drastically and implicitly changing the format just by passing --filter is the best idea. It does seem a little jarring. I still think it's the best output for seeing search results, but maybe this should be opt in, or I go back to gist search, though I appreciate this may be confusing if GitHub ever adds search capabilities to gists.

I like the opt-in idea. Why not introduce a flag for the alternative view? Something like --verbose-view (maybe verbose is overloaded, here) that indicates to the user they want to see all the extra information they've fetched? Leveraging the same flag could allow you to change the non-TTY output in a non-breaking way as well, which I think may satisfy @andyfeller's hesitation with adding the description to the non-TTY output.

This could also be a follow-up PR, so we can get this one in and make the QoL visual improvements next

I'm not worried so much about the different experience when passing --filter for now or implementing alternate displays at this point in all honesty. I'd rather wait for user feedback about before investing the time and effort to maintain that without stronger motivations.

I'd love to get @andyfeller's clarification on what he meant. I took it as not adding the description to what search code otherwise shows e.g., instead of my proposed:

Again, I felt the non-TTY gh search code results above were busy enough before considering how to duplicate it for gh gist list --filter with the gist description for every entry.

$ gh search code retry --owner cli | cat
cli/cli:pkg/cmd/release/shared/upload.go: func shouldRetry(err error) bool {
cli/cli:pkg/cmd/release/shared/upload.go: bo := backoff.NewConstantBackOff(retryInterval)
cli/cli:pkg/cmd/release/shared/upload.go: return backoff.Retry(func() error {
cli/cli:internal/codespaces/codespaces.go: err := backoff.Retry(func() error {
cli/gh-webhook:webhook/forward.go: // If the error is a server disconnect (1006), retry connecting
cli/cli:pkg/cmd/pr/create/create.go: return backoff.Retry(func() error {
cli/cli:pkg/cmd/pr/create/create.go: // Only retry if we have forked the repo else the push should succeed the first time.
cli/cli:pkg/cmd/attestation/verification/attestation.go: return nil, fmt.Errorf("no attestations found in the OCI registry. Retry the command without the --bundle-from-oci flag to check GitHub for the attestation")
cli/cli:git/client.go: message: fmt.Sprintf("unable to find git executable in PATH; please install %s before retrying", programName),
cli/cli:internal/codespaces/api/api.go: retryBackoff time.Duration
cli/cli:internal/codespaces/api/api.go: retryBackoff: 100 * time.Millisecond,
cli/cli:go.mod: github.com/hashicorp/go-retryablehttp v0.7.7 // indirect
cli/cli:pkg/cmd/repo/sync/sync.go: return fmt.Errorf("refusing to sync due to uncommitted/untracked local changes\ntip: use `git stash --all` before retrying the sync and run `git stash pop` afterwards")
cli/cli:pkg/cmd/repo/fork/fork.go: cloneDir, err := backoff.RetryWithData(func() (string, error) {
cli/cli:pkg/cmd/repo/create/create.go: } else if err := cloneWithRetry(opts, remoteURL, templateRepoMainBranch); err != nil {
cli/cli:pkg/cmd/repo/create/create.go: return backoff.Retry(func() error {
cli/cli:pkg/cmd/repo/fork/fork_test.go: name: "does not retry clone if error occurs and exit code is not 128",
cli/cli:pkg/cmd/attestation/verify/verify_test.go: require.ErrorContains(t, runVerify(&customOpts), "no attestations found in the OCI registry. Retry the command without the --bundle-from-oci flag to check GitHub for the attestation")
cli/cli:pkg/cmd/attestation/verify/verify_test.go: require.ErrorContains(t, runVerify(&customOpts), "no attestations found in the OCI registry. Retry the command without the --bundle-from-oci flag to check GitHub for the attestation")
cli/cli:pkg/cmd/repo/create/create_test.go: name: "noninteractive create from template with retry",
cli/cli:pkg/cmd/release/shared/upload_test.go: func Test_uploadWithDelete_retry(t *testing.T) {
cli/cli:pkg/cmd/release/shared/upload_test.go: retryInterval = 0
cli/cli:pkg/cmd/repo/sync/sync_test.go: errMsg:  "refusing to sync due to uncommitted/untracked local changes\ntip: use `git stash --all` before retrying the sync and run `git stash pop` afterwards",
cli/cli:internal/codespaces/api/api_test.go: retryBackoff: 0,

@heaths
Copy link
Contributor Author

heaths commented Oct 14, 2024

Again, I felt the non-TTY gh search code results above were busy enough before considering how to duplicate it for gh gist list --filter with the gist description for every entry.

But what about this implementation?

I like this because --filter just filters the existing table - with highlights - and while that's new, it's just a filter; whereas, --include-content not only augments --filter but implies that content will be included this I output search code-like output for both TTY and non-TTY cases where the only differences is color or no color, respectively. It reads much nicer.

Copy link
Member

@andyfeller andyfeller left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@heaths : looks good! I've only got 2 minor points on the changes but all in all looks good. Will see if @jtmcg has anything else before final review and approval.

this will be slower and increase the rate limit used. Instead of printing a table,
code will be printed with highlights.
For supported regular expression syntax, see https://pkg.go.dev/regexp/syntax
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure if I included the surrounding < > earlier, but these are needed to ensure that links are linkable in the CLI manual.

Suggested change
For supported regular expression syntax, see https://pkg.go.dev/regexp/syntax
For supported regular expression syntax, see <https://pkg.go.dev/regexp/syntax>

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I commented about that above. They actually render as < and > in the usage docs to the terminal, though. I looked at a lot of links in the CLI and didn't see them either. IMO, prioritizing --help output to a terminal should be priority; your doc formatter can - and honestly should - be handling URLs anyway. Most do - even github.com's does. I know markdown-lint recommends <> around URLs but the original markdown spec from Daring Fireball doesn't necessitate them.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Never mind. I just compared the results of:

grep -r '<https:' **/*.go

With:

grep -rP '(?<!<)https:' **/*.go

And stand corrected. Fixing...

Copy link
Contributor Author

@heaths heaths Oct 14, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@andyfeller wait, no, I was right: the <> do render to the terminal:

image

Part of the source of my confusion was that a URL at the bottom if --help on any command didn't wrap the URL. I found this in pkg/cmd/root/help.go:

	helpEntries = append(helpEntries, helpEntry{"LEARN MORE", heredoc.Docf(`
		Use %[1]sgh <command> <subcommand> --help%[1]s for more information about a command.
		Read the manual at https://cli.github.com/manual
		Learn about exit codes using %[1]sgh help exit-codes%[1]s
	`, "`")})

I'll update this text as you recommend so it can hopefully get merged soon, but I do think it's worth considering whether terminal output should have <> surrounding URLs - IMO, looks bad and certainly inconsistent with any other CLI - or fix whatever is rendering markdown for the CLI docs.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I commented about that above. They actually render as < and > in the usage docs to the terminal, though. I looked at a lot of links in the CLI and didn't see them either. IMO, prioritizing --help output to a terminal should be priority; your doc formatter can - and honestly should - be handling URLs anyway. Most do - even github.com's does. I know markdown-lint recommends <> around URLs but the original markdown spec from Daring Fireball doesn't necessitate them.

I admit the gh help usage isn't consistent in every place URLs are emitted. There have been multiple efforts to clean up as much as we could consistently do within various commands, however it isn't complete as you allude to.

As for whether gh contextually formats URLs differently depending on 1) --help, 2) man, or 3) web manual, I think that is reasonable as a next step.

@jtmcg
Copy link
Contributor

jtmcg commented Oct 14, 2024

@heaths : looks good! I've only got 2 minor points on the changes but all in all looks good. Will see if @jtmcg has anything else before final review and approval.

No further comments on my part about the design, here. I'll give the code another review by mid-day tomorrow and hopefully we can :shipit:

Copy link
Member

@andyfeller andyfeller left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jtmcg : once you get a chance to review, if you also approve, please feel free to merge 🙇

Copy link
Contributor

@jtmcg jtmcg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overall, the code looks good. There's one improvement I would like to see, though, which I've commented on.

Comment on lines +223 to +252
matched := false
out.Reset()

if filename, err = highlightMatch(file.Filename, filter, &matched, cs.Green, cs.Highlight); err != nil {
return err
}
fmt.Fprintln(out, cs.Blue(gist.ID), filename)

if gist.Description != "" {
if description, err = highlightMatch(gist.Description, filter, &matched, cs.Bold, cs.Highlight); err != nil {
return err
}
fmt.Fprintf(out, "%s%s\n", tab, description)
}

if file.Content != "" {
for _, line := range strings.FieldsFunc(file.Content, split) {
if filter.MatchString(line) {
if line, err = highlightMatch(line, filter, &matched, normal, cs.Highlight); err != nil {
return err
}
fmt.Fprintf(out, "%[1]s%[1]s%[2]s\n", tab, line)
}
}
}

if matched {
fmt.Fprintln(io.Out, out.String())
}
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I'd like to see this refactored out into a new function. Something like formatGistWithContent or similar. This confers a few benefits:

  1. Testing of that function is limited to a single gist, making it easier to test the various permutations implied by the conditionals
  2. It separates the responsibility of formatting the gists and formatting the list
  3. It makes it easier to read

Non-blocking: I'd also like to see the formatting code be more representative of what the output will look like, though I'm not exactly sure how to do that 😅 I find it hard to understand what the output will be from the code aside from reading the tests, and when that happens test expectations often become copy/pasted output. I generally have this complaint throughout the CLI, though, so I'm not going to block on it.

Copy link
Contributor Author

@heaths heaths Oct 15, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's going to be largely duplicative. The checks for things like Description or Content aren't just there for --filter --include-content. A gist - however it's printed - may not have a description. Or did you just mean lines 238 through 247 i.e., just for the if file.Content != "" conditional? Everything but that check would be duplicative and, not only increase maintenance costs, but likely increase binary size.

This is also taking advantage of a lot of singularly-defined variables including functions we'd have to pass in or keep allocating / redefining in each iteration like a strings.Builder that will be good to reuse to avoid unnecessary allocations. All that we'd have to pass in with enough parameters we'll likely exceed parameter registers on every platform and have to push arguments to the stack for each iteration.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let me cut a branch and tinker on it to show you what I'm thinking. You may be right, but I'm gonna give it a try anyway 🙂

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Alright, I tinkered around and I wasn't happy with the lowest hanging fruit. What I would like to see happen (well outside the scope of this) is for fetching and filtering to be hoisted way up the logic stack and set in NewCmdList, kind of how the IssuePrinter was extracted in this PR (merging the branch at a later date).

The problem is that this probably requires a rewrite of how we're fetching, too, and that is waaaay out of scope 😅

As a result, I'm fine to leave it as is in this PR. Thanks for indulging me and your patience while I dig into it myself 🍻

Copy link
Contributor

@jtmcg jtmcg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

:shipit:

Comment on lines +223 to +252
matched := false
out.Reset()

if filename, err = highlightMatch(file.Filename, filter, &matched, cs.Green, cs.Highlight); err != nil {
return err
}
fmt.Fprintln(out, cs.Blue(gist.ID), filename)

if gist.Description != "" {
if description, err = highlightMatch(gist.Description, filter, &matched, cs.Bold, cs.Highlight); err != nil {
return err
}
fmt.Fprintf(out, "%s%s\n", tab, description)
}

if file.Content != "" {
for _, line := range strings.FieldsFunc(file.Content, split) {
if filter.MatchString(line) {
if line, err = highlightMatch(line, filter, &matched, normal, cs.Highlight); err != nil {
return err
}
fmt.Fprintf(out, "%[1]s%[1]s%[2]s\n", tab, line)
}
}
}

if matched {
fmt.Fprintln(io.Out, out.String())
}
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Alright, I tinkered around and I wasn't happy with the lowest hanging fruit. What I would like to see happen (well outside the scope of this) is for fetching and filtering to be hoisted way up the logic stack and set in NewCmdList, kind of how the IssuePrinter was extracted in this PR (merging the branch at a later date).

The problem is that this probably requires a rewrite of how we're fetching, too, and that is waaaay out of scope 😅

As a result, I'm fine to leave it as is in this PR. Thanks for indulging me and your patience while I dig into it myself 🍻

@jtmcg jtmcg merged commit 7aef6ec into cli:trunk Oct 15, 2024
@heaths heaths deleted the issue9704 branch October 15, 2024 23:27
tmeijn pushed a commit to tmeijn/dotfiles that referenced this pull request Oct 17, 2024
This MR contains the following updates:

| Package | Update | Change |
|---|---|---|
| [cli/cli](https://github.com/cli/cli) | minor | `v2.58.0` -> `v2.59.0` |

MR created with the help of [el-capitano/tools/renovate-bot](https://gitlab.com/el-capitano/tools/renovate-bot).

**Proposed changes to behavior should be submitted there as MRs.**

---

### Release Notes

<details>
<summary>cli/cli (cli/cli)</summary>

### [`v2.59.0`](https://github.com/cli/cli/releases/tag/v2.59.0): GitHub CLI 2.59.0

[Compare Source](cli/cli@v2.58.0...v2.59.0)

#### What's Changed

-   Allow community submitted design work by [@&#8203;BagToad](https://github.com/BagToad) in cli/cli#9683
-   Improve `SECURITY.md` with expectations for privately reported vulnerabilities by [@&#8203;BagToad](https://github.com/BagToad) in cli/cli#9687
-   Emit a log message when extension installation falls back to a `darwin-amd64` binary on an Apple Silicon macOS device by [@&#8203;timrogers](https://github.com/timrogers) in cli/cli#9650
-   Print the login URL even when opening a browser by [@&#8203;ulfjack](https://github.com/ulfjack) in cli/cli#7091
-   configurable maxwidth for markdown WithWrap() by [@&#8203;smemsh](https://github.com/smemsh) in cli/cli#9626
-   Handle errors when parsing hostname in auth flow by [@&#8203;BagToad](https://github.com/BagToad) in cli/cli#9729
-   Add `repo license list/view` and `repo gitignore list/view` by [@&#8203;BagToad](https://github.com/BagToad) in cli/cli#9721
-   Introduce testscript acceptance tests generally, and for the MR command specifically by [@&#8203;williammartin](https://github.com/williammartin) in cli/cli#9745
-   Support `GH_ACCEPTANCE_SCRIPT` env var to target a single script by [@&#8203;williammartin](https://github.com/williammartin) in cli/cli#9756
-   Ensure Acceptance defer failures are debuggable by [@&#8203;williammartin](https://github.com/williammartin) in cli/cli#9754
-   Add acceptance task to makefile by [@&#8203;williammartin](https://github.com/williammartin) in cli/cli#9748
-   Add Acceptance tests for `issue` command by [@&#8203;williammartin](https://github.com/williammartin) in cli/cli#9757
-   Update IsEnterprise and IsTenancy for orthogonality using go-gh by [@&#8203;jtmcg](https://github.com/jtmcg) in cli/cli#9755
-   Supporting filtering on `gist list` by [@&#8203;heaths](https://github.com/heaths) in cli/cli#9728

#### New Contributors

-   [@&#8203;ulfjack](https://github.com/ulfjack) made their first contribution in cli/cli#7091
-   [@&#8203;smemsh](https://github.com/smemsh) made their first contribution in cli/cli#9626

**Full Changelog**: cli/cli@v2.58.0...v2.59.0

</details>

---

### Configuration

📅 **Schedule**: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).

🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied.

♻ **Rebasing**: Whenever MR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 **Ignore**: Close this MR and you won't be reminded about this update again.

---

 - [ ] <!-- rebase-check -->If you want to rebase/retry this MR, check this box

---

This MR has been generated by [Renovate Bot](https://github.com/renovatebot/renovate).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiIzNy40NDAuNyIsInVwZGF0ZWRJblZlciI6IjM3LjQ0MC43IiwidGFyZ2V0QnJhbmNoIjoibWFpbiIsImxhYmVscyI6WyJSZW5vdmF0ZSBCb3QiXX0=-->
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

external pull request originating outside of the CLI core team

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Support searching gists

4 participants