Servidor de Lenguaje

Wippy incluye un servidor LSP (Language Server Protocol) integrado que proporciona funcionalidades de IDE para codigo Lua. El servidor se ejecuta como parte del runtime de Wippy y se conecta a editores via TCP o HTTP.

Caracteristicas

Autocompletado con sugerencias basadas en tipos
Informacion al pasar el cursor mostrando tipos y firmas
Ir a la definicion
Buscar referencias
Simbolos de documento y espacio de trabajo
Jerarquia de llamadas (entrantes y salientes)
Diagnosticos en tiempo real (errores de analisis, errores de tipo)
Ayuda de firma para parametros de funciones

Configuracion

Habilita el servidor LSP en .wippy.yaml:

version: "1.0"

lua:
  type_system:
    enabled: true

lsp:
  enabled: true
  address: ":7777"

Campos de Configuracion

Campo	Por Defecto	Descripcion
`enabled`	false	Habilitar el servidor TCP
`address`	:7777	Direccion de escucha TCP
`http_enabled`	false	Habilitar el transporte HTTP
`http_address`	:7778	Direccion de escucha HTTP
`http_path`	/lsp	Ruta del endpoint HTTP
`http_allow_origin`	*	Origen permitido para CORS
`max_message_bytes`	8388608	Tamano maximo de mensaje entrante (bytes)

Transporte TCP

El servidor TCP utiliza JSON-RPC 2.0 con el enmarcado estandar de mensajes LSP (cabeceras Content-Length). Este es el transporte principal para integraciones con editores.

Transporte HTTP

El transporte HTTP acepta solicitudes POST con payloads JSON-RPC. Util para editores basados en navegador y herramientas web. Se incluyen cabeceras CORS para acceso entre origenes.

lsp:
  enabled: true
  http_enabled: true
  http_address: ":7778"
  http_path: "/lsp"
  http_allow_origin: "*"

Esquema de URI de Documentos

El servidor LSP usa el esquema de URI wippy:// para identificar entradas del registro:

wippy://namespace:entry_name

Los editores mapean estos URIs a IDs de entrada en el registro. Se aceptan tanto el esquema wippy:// como el formato directo namespace:entry_name.

Indexacion

El servidor LSP mantiene un indice de todas las entradas de codigo para busquedas rapidas. La indexacion ocurre en segundo plano usando multiples workers.

Comportamientos clave:

Las entradas se indexan en orden de dependencias (dependencias primero)
Los cambios disparan la re-indexacion de las entradas afectadas
Los cambios no guardados del editor se almacenan en una capa superpuesta
El indice es incremental - solo se reprocesan las entradas modificadas

Metodos LSP Soportados

Metodo	Descripcion
`initialize`	Negociacion de capacidades
`textDocument/didOpen`	Seguimiento de documentos abiertos
`textDocument/didChange`	Sincronizacion completa de documentos
`textDocument/didClose`	Liberacion de documentos
`textDocument/hover`	Informacion de tipo en el cursor
`textDocument/definition`	Ir a la definicion
`textDocument/references`	Buscar todas las referencias
`textDocument/completion`	Autocompletado
`textDocument/signatureHelp`	Firmas de funciones
`textDocument/diagnostic`	Diagnosticos de archivo
`textDocument/documentSymbol`	Simbolos de archivo
`workspace/symbol`	Busqueda global de simbolos
`textDocument/prepareCallHierarchy`	Jerarquia de llamadas
`callHierarchy/incomingCalls`	Buscar llamadores
`callHierarchy/outgoingCalls`	Buscar llamados

Autocompletado

El motor de autocompletado resuelve tipos a traves del grafo de codigo. Proporciona:

Autocompletado de miembros despues de . y : (campos, metodos)
Autocompletado de variables locales
Autocompletado de simbolos a nivel de modulo
Caracteres de activacion: ., :

Diagnosticos

Los diagnosticos se calculan durante la indexacion e incluyen:

Errores de analisis (problemas de sintaxis)
Errores de verificacion de tipos (incompatibilidades, simbolos no definidos)
Niveles de severidad: error, warning, information, hint

Los diagnosticos se actualizan mientras escribes a traves del sistema de capa superpuesta de documentos.

Ver Tambien

Linter - Verificacion de codigo por linea de comandos
Tipos - Documentacion del sistema de tipos
Configuracion - Configuracion del runtime