El protocolo de servidor de lenguaje ( LSP ) es un protocolo abierto basado en JSON-RPC para uso entre editores de código fuente o entornos de desarrollo integrados (IDE) y servidores que proporcionan "herramientas de inteligencia del lenguaje": [1] características específicas del lenguaje de programación , como el código. finalización , resaltado de sintaxis y marcado de advertencias y errores, así como rutinas de refactorización . El objetivo del protocolo es permitir que el soporte del lenguaje de programación se implemente y distribuya independientemente de cualquier editor o IDE. [2] A principios de la década de 2020, LSP se convirtió rápidamente en una "norma" para los proveedores de herramientas de inteligencia lingüística. [1]
LSP se desarrolló originalmente para Microsoft Visual Studio Code y ahora es un estándar abierto. El 27 de junio de 2016, Microsoft anunció una colaboración con Red Hat y Codenvy para estandarizar la especificación del protocolo. El protocolo fue originalmente apoyado y adoptado por estas tres empresas. [3] [4] Su especificación está alojada y desarrollada en GitHub . [5]
Los IDE modernos brindan a los programadores funciones sofisticadas como finalización de código , refactorización , navegación a la definición de un símbolo , resaltado de sintaxis y marcadores de error y advertencia.
Por ejemplo, en un lenguaje de programación basado en texto, un programador podría querer cambiar el nombre de un método read. El programador podría editar manualmente los respectivos archivos de código fuente y cambiar las apariciones apropiadas del nombre del método antiguo por el nuevo nombre, o en su lugar utilizar las capacidades de refactorización de un IDE para realizar todos los cambios necesarios automáticamente. Para poder admitir este estilo de refactorización, un IDE necesita una comprensión sofisticada del lenguaje de programación en el que está escrito el código fuente del programa . Una herramienta de programación sin esa comprensión (por ejemplo, una que realiza una ingenua búsqueda y reemplazo) . —podría introducir errores. Al cambiar el nombre de un readmétodo, por ejemplo, la herramienta no debe reemplazar la coincidencia parcial en una variable que podría llamarse readyState, ni tampoco debe reemplazar la parte de un comentario de código que contiene la palabra "ya". Tampoco cambiar el nombre de una variable local read , por ejemplo, debería terminar alterando variables con nombres idénticos en otros ámbitos .
Los compiladores o intérpretes convencionales para un lenguaje de programación específico generalmente no pueden proporcionar estos servicios de lenguaje porque están escritos con el objetivo de transformar el código fuente en código objeto o ejecutar el código inmediatamente. Además, los servicios de lenguaje deben poder manejar código fuente que no esté bien formado , por ejemplo, porque el programador está en medio de la edición y aún no ha terminado de escribir una declaración, procedimiento u otra construcción. Además, los pequeños cambios en un archivo de código fuente que se realizan durante la escritura generalmente cambian la semántica del programa. Para poder proporcionar retroalimentación instantánea al usuario, la herramienta de edición debe ser capaz de evaluar muy rápidamente las consecuencias sintácticas y semánticas de una modificación específica. Por lo tanto, los compiladores e intérpretes son malos candidatos para producir la información necesaria para que la consuma una herramienta de edición. [6]
Antes del diseño y la implementación del protocolo de servidor de idiomas para el desarrollo de Visual Studio Code, la mayoría de los servicios de idiomas generalmente estaban vinculados a un IDE determinado u otro editor. En ausencia del protocolo de servidor de idiomas, los servicios lingüísticos normalmente se implementan mediante una API de extensión específica de la herramienta. Proporcionar el mismo servicio de idioma a otra herramienta de edición requiere un esfuerzo para adaptar el código existente para que el servicio pueda apuntar a las interfaces de extensión del segundo editor. [7]
El protocolo de servidor de idiomas permite desacoplar los servicios de idiomas del editor para que los servicios puedan estar contenidos dentro de un servidor de idiomas de propósito general . Cualquier editor puede heredar un soporte sofisticado para muchos idiomas diferentes haciendo uso de los servidores de idiomas existentes. De manera similar, un programador involucrado en el desarrollo de un nuevo lenguaje de programación puede poner servicios para ese lenguaje a disposición de las herramientas de edición existentes. [6] Por lo tanto, el uso de servidores de idiomas a través del protocolo de servidor de idiomas también reduce la carga de los proveedores de herramientas de edición, porque los proveedores no necesitan desarrollar sus propios servicios lingüísticos para los idiomas que pretenden soportar, siempre que el idioma Los servidores ya han sido implementados. El protocolo de servidor de idiomas también permite la distribución y el desarrollo de servidores aportados por un tercero interesado, como usuarios finales, sin participación adicional ni del proveedor del compilador para el lenguaje de programación en uso ni del proveedor del editor al que pertenece el lenguaje. Se está agregando soporte. [ cita necesaria ]
LSP no se limita a lenguajes de programación. Se puede utilizar para cualquier tipo de lenguaje basado en texto, como especificaciones [8] o lenguajes específicos de dominio (DSL) . [9]
Cuando un usuario edita uno o más archivos de código fuente utilizando una herramienta habilitada para el protocolo de servidor de idiomas, la herramienta actúa como un cliente que consume los servicios de idiomas proporcionados por un servidor de idiomas . La herramienta puede ser un editor de texto o IDE y los servicios de lenguaje podrían ser refactorización , finalización de código , etc.
El cliente informa al servidor sobre lo que está haciendo el usuario, por ejemplo, abrir un archivo o insertar un carácter en una posición de texto específica. El cliente también puede solicitar al servidor que realice un servicio de idioma, por ejemplo, formatear un rango específico en el documento de texto. El servidor responde a la solicitud de un cliente con una respuesta adecuada. Por ejemplo, la solicitud de formato se responde mediante una respuesta que transfiere el texto formateado al cliente o mediante una respuesta de error que contiene detalles sobre el error.
El protocolo del servidor de idiomas define los mensajes que se intercambiarán entre el cliente y el servidor de idiomas. Son JSON-RPC precedidos por encabezados similares a HTTP. Los mensajes pueden originarse desde el servidor o el cliente.
El protocolo no establece ninguna disposición sobre cómo se transfieren las solicitudes, respuestas y notificaciones entre el cliente y el servidor. Por ejemplo, el cliente y el servidor podrían ser componentes dentro del mismo proceso que intercambian cadenas JSON mediante llamadas a métodos. También podrían ser diferentes procesos en la misma o en diferentes máquinas comunicándose a través de sockets de red .
Un registro global de servicios lingüísticos, alojado por la Fundación Eclipse, debería poner los servidores de idiomas a disposición del público. [10] Además, hay listas de implementaciones compatibles con LSP, mantenidas por Langserver.org [11] o Microsoft, impulsado por la comunidad. [12]