package progress
import "cuelang.org/go/internal/golangorgx/gopls/progress"
The progress package defines utilities for reporting the progress of long-running operations using features of the LSP client interface such as Progress and ShowMessage.
Index ¶
- func NewEventWriter(ctx context.Context, operation string) io.Writer
- func NewWorkDoneWriter(ctx context.Context, wd *WorkDone) io.Writer
- type Tracker
- func NewTracker(client protocol.Client) *Tracker
- func (t *Tracker) Cancel(token protocol.ProgressToken) error
- func (t *Tracker) SetSupportsWorkDoneProgress(b bool)
- func (t *Tracker) Start(ctx context.Context, title, message string, token protocol.ProgressToken, cancel func()) *WorkDone
- func (t *Tracker) SupportsWorkDoneProgress() bool
- type WorkDone
Functions ¶
func NewEventWriter ¶
NewEventWriter returns an io.Writer that calls the context's event printer for each data payload, wrapping it with the operation=generate tag to distinguish its logs from others.
func NewWorkDoneWriter ¶
NewWorkDoneWriter wraps a WorkDone handle to provide a Writer interface, so that workDone reporting can more easily be hooked into commands.
Types ¶
type Tracker ¶
type Tracker struct {
// contains filtered or unexported fields
}
A Tracker reports the progress of a long-running operation to an LSP client.
func NewTracker ¶
NewTracker returns a new Tracker that reports progress to the specified client.
func (*Tracker) Cancel ¶
func (t *Tracker) Cancel(token protocol.ProgressToken) error
func (*Tracker) SetSupportsWorkDoneProgress ¶
SetSupportsWorkDoneProgress sets whether the client supports "work done" progress reporting. It must be set before using the tracker.
TODO(rfindley): fix this broken initialization pattern. Also: do we actually need the fall-back progress behavior using ShowMessage? Surely ShowMessage notifications are too noisy to be worthwhile.
func (*Tracker) Start ¶
func (t *Tracker) Start(ctx context.Context, title, message string, token protocol.ProgressToken, cancel func()) *WorkDone
Start notifies the client of work being done on the server. It uses either ShowMessage RPCs or $/progress messages, depending on the capabilities of the client. The returned WorkDone handle may be used to report incremental progress, and to report work completion. In particular, it is an error to call start and not call end(...) on the returned WorkDone handle.
If token is empty, a token will be randomly generated.
The progress item is considered cancellable if the given cancel func is non-nil. In this case, cancel is called when the work done
Example:
func Generate(ctx) (err error) { ctx, cancel := context.WithCancel(ctx) defer cancel() work := s.progress.start(ctx, "generate", "running go generate", cancel) defer func() { if err != nil { work.end(ctx, fmt.Sprintf("generate failed: %v", err)) } else { work.end(ctx, "done") } }() // Do the work... }
func (*Tracker) SupportsWorkDoneProgress ¶
SupportsWorkDoneProgress reports whether the tracker supports work done progress reporting.
type WorkDone ¶
type WorkDone struct {
// contains filtered or unexported fields
}
WorkDone represents a unit of work that is reported to the client via the progress API.
func (*WorkDone) End ¶
End reports a workdone completion back to the client.
func (*WorkDone) Report ¶
Report reports an update on WorkDone report back to the client.
func (*WorkDone) Token ¶
func (wd *WorkDone) Token() protocol.ProgressToken
Source Files ¶
progress.go
- Version
- v0.12.0 (latest)
- Published
- Jan 30, 2025
- Platform
- linux/amd64
- Imports
- 11 packages
- Last checked
- 8 hours ago –
Tools for package owners.