feat: data-driven config profiles with custom commands and interactions

[mpryor]

Summary

Support config profiles that match against input data and provide custom commands, keybindings, and interactions tailored to that data — turning nless into a framework for building bespoke data exploration tools (like k9s, but for any data source).

Dependencies

Builds on top of:

• bug: JSON delimiter auto-inference not working #25 — JSON delimiter inference (profiles reference delimiters)
• feat: multiple regex highlights with distinct colors #24 — Multiple regex highlights (profiles define highlight rules)
• feat: bookmarks / saved views #26 — Saved views (profiles are a superset of views)
• feat: auto-detect common log formats via built-in regex patterns #31 — Built-in log format patterns (profiles reference formats by name)

Details

A config file (e.g., ~/.config/nless/profiles.yaml or per-project .nlessrc) defines profiles that activate when input matches certain criteria. Each profile can define:

• Matching rules — activate based on filename pattern, column names, delimiter type, or content regex
• Custom keybindings — bind keys to shell commands, filters, or transforms scoped to this data
• Action menus — context-aware actions on the selected row (e.g., press enter on a Kubernetes pod row to tail its logs into a new buffer)
• Row actions — shell command templates using column values as variables (e.g., kubectl describe pod {{name}} -n {{namespace}})
• Default views — pre-applied filters, sorts, column visibility, and refresh intervals
• Refresh/polling — re-run the source command on an interval to keep data live
• Drill-down chains — define how selecting a row leads to a new view (e.g., pods → containers → logs)

Example Config

profiles:
  - name: kubernetes-pods
    match:
      columns: [NAME, READY, STATUS, RESTARTS, AGE]
    default:
      sort: NAME=asc
      hidden_columns: [NOMINATED NODE, READINESS GATES]
    actions:
      enter: "kubectl describe pod {{NAME}} -n {{NAMESPACE}}"
      l: "kubectl logs {{NAME}} -n {{NAMESPACE}} --tail=100"
      x: "kubectl delete pod {{NAME}} -n {{NAMESPACE}}"
      e: "kubectl edit pod {{NAME}} -n {{NAMESPACE}}"
    refresh: 5s

  - name: docker-containers
    match:
      columns: [CONTAINER ID, IMAGE, STATUS, PORTS, NAMES]
    actions:
      enter: "docker logs {{CONTAINER ID}} --tail=100"
      s: "docker stop {{CONTAINER ID}}"
      x: "docker rm {{CONTAINER ID}}"
    refresh: 3s

  - name: nginx-access-logs
    match:
      filename: "*access*.log"
    delimiter: 'combined'  # use built-in log pattern (#31)
    highlight:
      - pattern: " 5\\d{2} "
        color: red
      - pattern: " 4\\d{2} "
        color: yellow
    actions:
      enter: "whois {{remote_addr}}"

Use Cases

• k9s-style Kubernetes dashboard: kubectl get pods | nless with full pod management keybindings
• Docker management: docker ps | nless with container lifecycle actions
• AWS resource explorer: aws ec2 describe-instances | nless with instance actions
• Custom ops dashboards: any CLI tool's tabular output becomes an interactive management UI
• Log-specific workflows: auto-apply highlights, filters, and alert rules for known log formats
• Team-shared configs: check .nlessrc into a repo so the whole team gets the same interactive experience

Considerations

• Profile precedence when multiple profiles match
• Security — shell command execution from config files needs user trust/confirmation model
• Relationship with feat: bookmarks / saved views #26 (saved views), feat: auto-detect common log formats via built-in regex patterns #31 (log format detection), feat: multiple regex highlights with distinct colors #24 (highlights), feat: alerting rules for streaming data #34 (alerts) — profiles could compose all of these
• Hot-reloading config changes without restarting
• Config format — YAML vs TOML vs JSON
• Per-project configs (.nlessrc in cwd) vs global configs
• This could become the core extensibility mechanism for nless