Editor and language service separation analysis method and device, equipment and medium

Abstract

The invention relates to the technical field of research and development management and the field of financial science and technology, and discloses an editor and language service separation analysis method, which comprises the following steps of: defining a communication protocol between an editor and a language server, monitoring file processing operation in the editor, generating a standard behavior event, and analyzing the standard behavior event. Sending the standard behavior event to a language server through an editor, analyzing the event by the language server, determining a corresponding file processing operation type, executing a language service based on the operation type, generating a service result, and judging whether feedback information needs to be sent to the editor or not; if it is determined that feedback is needed, language service feedback data are generated, the feedback data are sent to the editor through a communication protocol, and the editor updates editing feedback information displayed in the interface based on the feedback data. According to the invention, by breaking the tight coupling between the editor and the language server, the complexity of independently developing the language server for each language in different editors is avoided, and the development cost is reduced.

Description

Technical Field

[0001] The present invention relates to the fields of R&D management technology and financial technology, and in particular to an analysis method, device, equipment and storage medium for separating an editor from a language service. Background Art

[0002] In the financial industry, when developing and maintaining a large number of complex business systems, code writing, debugging and maintenance are one of the basic tasks. Usually, financial institutions rely on different programming tools and integrated development environments (IDEs) to develop different financial applications. These tools often provide functions such as code prompts, error diagnosis, and automatic completion to improve development efficiency. However, the implementation of these functions relies on the support of various language servers, that is, the language server process corresponding to each programming language is responsible for analyzing the code file being edited and providing relevant prompts and diagnostic information.

[0003] When financial institutions' development tools implement language analysis and prompting functions, they are often deeply coupled with language servers. For example, development environments such as Eclipse tightly integrate code analysis logic with language services. This high coupling makes it impossible for developers to flexibly select or switch between different development tools, limiting the diversity of tools.

[0004] Currently, editors used in financial development, such as VSCode, Vim, Sublime, etc., use different protocols to communicate with language servers. Each editor may only support a few programming languages. If all languages ​​are to be supported in different editors, the development cost and maintenance complexity will increase exponentially. The programming languages ​​involved in financial development are diverse, and the need to be compatible with various programming languages ​​in multiple environments forces developers to develop and maintain multiple language servers for each editor separately, which seriously affects development efficiency and resource allocation.

[0005] As the complexity of financial systems increases, more and more languages ​​are involved in development and maintenance. If a development tool needs to support n languages, and financial institutions use m different editors, then in theory n*m language servers need to be developed and adapted. Existing technical implementation methods lead to exponential growth in development costs and complexity, especially in scenarios where multiple teams collaborate on development. Unified management of these language servers has also become a major challenge.

[0006] Under the existing technical framework, there may be inconsistencies in the interfaces and protocols between different editors and language servers, which may lead to compatibility issues when the system performs code analysis and diagnosis when developing financial software. Once the language server fails or stops responding, it may affect the normal operation of the financial development environment, causing system crashes or data loss, thereby affecting the overall development efficiency. Summary of the invention

[0007] The main purpose of the present invention is to provide an analysis method, device, equipment and storage medium for separating an editor from a language service, aiming to solve the technical problem in the prior art that the tight coupling between the editor and the language server leads to insufficient cross-tool support and increases development cost and complexity.

[0008] To achieve the above object, the present invention provides an analysis method for separating an editor from a language service, comprising:

[0009] Defines a standard protocol for communication between editors and language servers;

[0010] Monitoring file processing operations in the editor, and generating corresponding standard behavior events based on the file processing operations;

[0011] Sending the standard behavior event to the language server according to the standard protocol by the editor;

[0012] Parsing the standard behavior event by the language server to determine the file processing operation type corresponding to the standard behavior event;

[0013] The language server executes a corresponding language service based on the file processing operation type and generates a language service result;

[0014] Determining, by the language server based on the language service result, whether it is necessary to send feedback information to the editor;

[0015] If feedback information needs to be sent, determining the language service feedback data that needs to be sent according to the language service result, and sending the language service feedback data to the editor according to the standard protocol;

[0016] The editor updates the editing feedback information displayed in the editor interface according to the language service feedback data.

[0017] Furthermore, to achieve the above-mentioned purpose, the present invention provides an analysis device with an editor separated from a language service, comprising:

[0018] The communication protocol definition module is used to define the standard protocol for communication between the editor and the language server;

[0019] An event monitoring module, used for monitoring file processing operations in the editor, and generating corresponding standard behavior events based on the file processing operations;

[0020] An event transmission module, configured to send the standard behavior event to the language server through the editor according to the standard protocol;

[0021] An event parsing module, configured to parse the standard behavior event through the language server and determine a file processing operation type corresponding to the standard behavior event;

[0022] A language service execution module, configured to execute a corresponding language service based on the file processing operation type through the language server and generate a language service result;

[0023] A feedback judgment module, configured to judge whether it is necessary to send feedback information to the editor based on the language service result through the language server;

[0024] A feedback generation and transmission module, configured to determine language service feedback data to be sent according to the language service result if feedback information needs to be sent, and send the language service feedback data to the editor according to the standard protocol;

[0025] The interface updating module is used to update the editing feedback information displayed in the editor interface according to the language service feedback data through the editor.

[0026] Furthermore, to achieve the above-mentioned purpose, the present invention also provides a computer device, which includes a memory, a processor, and an analysis program for separating an editor from a language service, which is stored in the memory and can be run on the processor, and the analysis program for separating an editor from a language service, when executed by the processor, implements the steps of the analysis method for separating an editor from a language service as described above.

[0027] Furthermore, to achieve the above-mentioned purpose, the present invention also provides a computer-readable storage medium, on which is stored an analysis program for separating an editor from a language service, and when the analysis program for separating an editor from a language service is executed by a processor, the steps of the analysis method for separating an editor from a language service as described above are implemented.

[0028] Beneficial effects: The present invention relates to the technical field of R&D management and the field of financial technology, and discloses an analysis method for separating an editor from a language service. By defining a communication protocol between an editor and a language server, the file processing operation in the editor is monitored, and a standard behavior event is generated. The standard behavior event is sent to the language server through the editor, and the language server parses the event, determines the corresponding file processing operation type, executes the language service based on the operation type, generates a service result, and determines whether it is necessary to send feedback information to the editor; if it is determined that feedback is required, language service feedback data is generated, and the feedback data is sent to the editor through a communication protocol, and the editor updates the editing feedback information displayed in the interface based on the feedback data. The present invention breaks the tight coupling between the editor and the language server, so that the development tool can adapt to different languages ​​and editors more flexibly, avoids the complexity of developing a language server for each language in different editors, and reduces development costs. Ultimately, higher cross-platform compatibility and development efficiency are achieved. BRIEF DESCRIPTION OF THE DRAWINGS

[0029] The present invention will be further described below with reference to the accompanying drawings and embodiments, in which:

[0030] Figure 1 A schematic diagram of an application environment of an analysis method for separating an editor from a language service in an embodiment of the present invention;

[0031] Figure 2 It is a flowchart of an embodiment of an analysis method for separating an editor from a language service according to the present invention;

[0032] Figure 3 A schematic diagram of functional modules of a preferred embodiment of an analysis device with separated editor and language service of the present invention;

[0033] Figure 4 A schematic diagram of the structure of a computer device in one embodiment of the present invention;

[0034] Figure 5 FIG. 4 is another schematic diagram of the structure of a computer device in one embodiment of the present invention. DETAILED DESCRIPTION

[0035] It should be understood that the specific embodiments described herein are only used to explain the present invention, and are not used to limit the present invention.

[0036] The analysis method for separating the editor from the language service provided by the embodiment of the present invention can be applied in the following aspects: Figure 1In an application environment, the user end communicates with the server end through a network. The server end can define the communication protocol between the editor and the language server through the user end, monitor the file processing operation in the editor, generate a standard behavior event, send the standard behavior event to the language server through the editor, the language server parses the event, determines the corresponding file processing operation type, executes the language service based on the operation type, generates a service result, and determines whether it is necessary to send feedback information to the editor; if it is determined that feedback is required, language service feedback data is generated, and the feedback data is sent to the editor through the communication protocol, and the editor updates the editing feedback information displayed in the interface based on the feedback data. The present invention breaks the tight coupling between the editor and the language server, so that the development tool can adapt to different languages ​​and editors more flexibly, avoids the complexity of developing a language server for each language in different editors, and reduces the development cost. Finally, higher cross-platform compatibility and development efficiency are achieved. Among them, the user end can be but not limited to various personal computers, laptops, smart phones, tablet computers and portable wearable devices. The server end can be implemented with an independent server or a server cluster composed of multiple servers. The present invention is described in detail below through specific embodiments.

[0037] See also Figure 2 , Figure 2 This is a flowchart of an embodiment of an analysis method for separating an editor from a language service provided by the present invention. It should be noted that although a logical sequence is shown in the flowchart, in some cases, the steps shown or described may be performed in a different order than that shown here.

[0038] like Figure 2 As shown, the analysis method for separating the editor from the language service proposed in the present invention includes the following steps:

[0039] S10, defines a standard protocol for communication between editors and language servers;

[0040] In this embodiment, the standard protocol needs to define the message format exchanged between the editor and the language server, including how to represent the event identifier, event type, timestamp, and detailed information of the event. Each behavioral event can be encapsulated into a standardized message body using JSON, XML, or a custom protocol format. The message body should contain the event's unique identifier, event type (such as file open, edit, save), timestamp (record the time when the event occurred), and event-related details, such as the modified code snippet or file path.

[0041] To ensure stable and reliable communication between the editor and the language server, the protocol needs to specify how to establish a connection, maintain a session, and define the transport layer protocol for communication (such as HTTP, WebSocket, etc.). WebSocket can be used to implement persistent two-way communication, so that the editor and the language server can exchange data in real time. Whenever the editor generates a standard behavior event, the message is transmitted through WebSocket, and the language server responds in real time. In the event of a disconnection, a retry mechanism can be set in the protocol to ensure the reliability of communication.

[0042] The standard protocol also needs to specify the order of message sending and the response mechanism to ensure that events can be properly processed after being sent, and that the editor can be adjusted based on the server's response. A request-response model can be used, where the editor sends a request and waits for the language server's response. A timeout handling mechanism can be defined in the standard protocol. If no response is received within a set time, the editor can resend the message or perform fault handling.

[0043] The protocol needs to clearly define how to handle errors that occur during communication, such as how to deal with network disconnection, message parsing failure, etc. An error code system can be added to the communication protocol. Whenever an error occurs, the editor and language server can take corresponding measures based on the defined error code, such as resending, logging, and notifying the user.

[0044] To ensure data security, the protocol needs to include authentication and encrypted transmission mechanisms to ensure that the interaction between the editor and the language server is secure. You can use OAuth or certificate-based authentication mechanisms. When the editor establishes communication with the language server, it must first complete the authentication process. SSL / TLS encryption ensures that data is not tampered with or stolen during transmission.

[0045] Example description: In financial system development, the quality of writing and maintaining code is crucial to the stable operation of business systems. For example, when developers write core financial data processing algorithms, the editor communicates with the language server through standard protocols to provide code prompts, error diagnosis, and security vulnerability detection in real time. The language server can parse the developer's code and immediately feedback to the editor through the communication protocol when possible errors are detected. This feedback mechanism not only improves development efficiency, but also effectively reduces system vulnerabilities caused by human errors. Especially when processing financial data, it can significantly improve code quality and reduce risks in financial data processing.

[0046] By defining a standard protocol for communication between editors and language servers, the problems of high coupling between editors and language servers and insufficient cross-tool support in the existing technology are solved. This protocol enables different editors and language servers to communicate in a unified way, reducing development costs and improving the scalability and cross-platform compatibility of the system. In addition, the message exchange rules, error handling mechanism and security authentication method of the standard protocol enhance the stability and security of the system, especially in large-scale team development and sensitive data processing scenarios, effectively improving the overall reliability of the system.

[0047] S20, monitoring the file processing operation in the editor, and generating a corresponding standard behavior event based on the file processing operation;

[0048] In this embodiment, the editor needs to monitor the file opening behavior performed by the user in the operating system and obtain key information such as the file path and file type. This can be done by monitoring the file opening events (such as open events) of the operating system or the editor itself. When the user opens a file, the editor triggers the event and records the file path, file type and other information, generating a "file open" behavior event.

[0049] The editor needs to monitor the user's editing behavior on the opened file, including operations such as content modification and cursor position change. The editor monitors the user input or text box change events to track file changes. Every time the user enters new content, deletes old content, or moves the cursor in the document, the corresponding event will be triggered, recording the specific row and column position and modified content, and generating a "file editing" behavior event.

[0050] Monitor the file saving behavior performed by the user in the editor, and record the saving time and saving status. The editor listens to the saving event (such as the save event), and triggers the event when the user presses the save shortcut key or clicks the save button. The editor records the file saving time and modification summary, and generates a "file save" behavior event.

[0051] When the user closes a file, the editor needs to monitor this behavior and obtain relevant information such as the closing time. The editor listens to file closing events (such as the close event) and triggers this event when the user closes the document. The editor records the closing time of the file and generates a "file closed" behavior event.

[0052] The editor monitors the user's behavior when operating files through a built-in event monitoring mechanism. Whenever the user performs a file open, edit, save, or close operation, the editor triggers the corresponding event. The editor generates standardized behavior events based on the specific operation and prepares to send the behavior event to the language server for processing.

[0053] Example description: In the development of financial systems, monitoring and real-time response of file operations are crucial. For example, when developers are working on code involving financial data, each edit, save, or close of a file may affect the stability of the system and the accuracy of the data. By monitoring these operations in real time and generating standard behavior events, the language server can instantly analyze potential problems in the code and provide developers with feedback on security vulnerabilities or error prompts. This mechanism ensures that developers can get timely feedback when processing critical financial data, reduces the risk of possible erroneous operations, and improves code quality and data security during the development of financial systems.

[0054] By monitoring the file processing operations in the editor, it is possible to accurately obtain the user's actions on opening, editing, saving, and closing files, and generate corresponding standard behavior events based on different operations. This mechanism breaks the coupling relationship between the editor and the language server, allowing different editors to process file operation events through the same protocol, improving cross-platform compatibility and development efficiency. In addition, monitoring different operation types and generating standard behavior events provides a basis for subsequent code analysis, error prompts, and syntax checking, ensuring that the system can respond accurately based on the user's operation type.

[0055] S30, sending the standard behavior event to the language server according to the standard protocol through the editor;

[0056] In this embodiment, the editor needs to encapsulate the generated standard behavior events according to a predefined protocol format so that it can communicate with the language server. The behavior events can be encapsulated using JSON-RPC, XML, or other custom data formats. The encapsulation process includes combining the event identifier, type, timestamp, and event details (such as file path, modified content) of the behavior event into a standardized data packet.

[0057] The editor needs to establish a communication connection according to the standard protocol to ensure that events can be stably transmitted to the language server. Use transmission protocols such as WebSocket, HTTP, or TCP. WebSocket can be used for real-time communication, while HTTP can be used for a single request-response mode. When the editor starts, connect to the language server and maintain the stability of the communication channel.

[0058] The editor needs to send the encapsulated standard behavior events in the transport format of the protocol to ensure that the language server can correctly receive and parse them. The editor serializes the behavior events into strings or binary data streams according to the transport layer format in the protocol and sends them to the language server using a transport protocol (such as WebSocket or HTTP POST request).

[0059] After sending, the editor needs to process the reception confirmation from the language server to ensure that the event data is successfully received; if the transmission fails or times out, the editor needs to perform error handling. The editor can monitor the response of the language server. If the confirmation is not received within the set time, the data packet can be resent, or the error can be recorded in the log system. The number of retries can be set to avoid event loss due to network failure.

[0060] Example description: In the development process of financial software, code changes need to be recorded and fed back in a timely manner, especially when dealing with code involving financial transaction logic or sensitive data. Each file edit, save, or close operation may have a significant impact. Through the standard protocol between the editor and the language server, financial developers can pass file operation information to the language server in real time. The server can automatically analyze the code and immediately feedback error prompts or optimization suggestions. For example, when the developer modifies the core code involving the payment system, the editor passes the operation to the language server through the protocol. After analysis, the server finds potential security vulnerabilities and immediately feeds back to the developer. This mechanism ensures the quality and security of code in the development of financial systems and effectively reduces system risks.

[0061] The editor sends standard behavior events to the language server according to the standard protocol, solving the problem of insufficient cross-platform support caused by the tight coupling between the editor and the language server and inconsistent protocols in the prior art. The definition of the standard protocol enables different editors to communicate with the language server in the same way, improving the scalability and compatibility of the system.

[0062] S40, parsing the standard behavior event by the language server to determine the file processing operation type corresponding to the standard behavior event;

[0063] In this embodiment, after the language server receives the standard behavior event sent by the editor, it needs to parse the event and extract key information therein, such as event identifier, event type, timestamp, and file operation data. After the language server receives the behavior event, it first parses it according to the standard protocol format. JSON or XML parsing libraries can be used to extract various fields of the event, such as event type (file open, edit, save or close), event identifier (unique identifier), timestamp (time when the operation occurs), and file-related operation data (such as file path, modified content, etc.).

[0064] The parsed event contains the file processing operation type, and the language server determines which file operation the event belongs to based on the type, such as file open, edit, save, or close. Based on the parsed event type field, the language server determines the specific operation type by matching a predefined set of file operation types (such as "open", "edit", "save", "close"). Event type matching can be achieved through string comparison, enumeration type mapping, etc.

[0065] In addition to the event type, the language server also needs to extract file data related to the operation (such as file path, modified content, row and column position, etc.). By parsing the detailed data part in the event, relevant information of the file, such as path, modified content, etc., is extracted. This data will be used for subsequent code analysis or operation processing.

[0066] Example description: In software development in the financial field, file operations (such as editing code files involving transaction logic) may affect the security and stability of the system. For example, when a developer edits the core code of a financial system, the editor generates a "file edit" behavior event and sends it to the language server. The language server parses the event, determines that it is a "file edit" operation, and extracts the relevant file path and modified content. At this point, the server can further analyze the code, find possible errors or security vulnerabilities, and provide timely feedback to the developer. This process ensures the code quality of the financial system and reduces potential risks, especially when processing sensitive financial data, which can effectively improve the security and accuracy of the code.

[0067] By parsing standard behavior events and determining the type of file processing operations through the language server, efficient communication and data sharing between the editor and the language server can be achieved. After parsing the behavior events, the language server can accurately identify the type of file operations, such as open, edit, save, or close, which lays the foundation for subsequent code analysis and feedback. Through standardized event parsing and operation type determination, the system can support cross-platform multi-editor and multi-language environments, improving the scalability and flexibility of the system.

[0068] S50, executing a corresponding language service based on the file processing operation type by the language server, and generating a language service result;

[0069] In this embodiment, after receiving the file processing operation type, the language server needs to select the corresponding language service module (such as syntax checking, code diagnosis, automatic completion, etc.) according to the operation type. The language server selects the corresponding language service module according to the parsed file processing operation type (such as file opening, editing, saving or closing). For example, for file editing operations, the language server will call the code diagnosis and syntax checking modules; for file saving operations, the server may execute the code formatting or error prompt modules.

[0070] After selecting the corresponding service module, the language server passes the file data of the operation (such as modified content, row and column position, etc.) to the corresponding module as input for subsequent processing. The parsed file data, such as file path, modified content, cursor position, etc., are passed to the language service module through function calls or data interfaces. After receiving the data, the language service module performs corresponding operations according to the different types of data.

[0071] The language service module performs specific tasks, such as syntax checking, code completion, compilation prompts, etc., based on the received file operation data, and generates result data. The service module performs specific processing tasks based on the input data. For example, the syntax checking module will traverse the content in the code file, find syntax errors, and generate error messages; the code completion module will provide code completion suggestions based on the current cursor position. After the processing is completed, the service module will encapsulate the generated results into a standardized language service result object.

[0072] Example: In the development of financial systems, the quality and accuracy of the code are crucial. For example, when a developer modifies a code file involving a payment transaction, the language server identifies this as a "file editing" operation by parsing the operation type, and then calls the syntax check module to check the modified code for possible syntax errors or logic vulnerabilities. After the check is completed, the language server generates a detailed error report and feeds it back to the developer. This mechanism ensures the accuracy and security of financial codes during the development process and effectively reduces potential risks in the system.

[0073] By selecting and executing the corresponding language service according to the file processing operation type, the language server can efficiently respond to the user's code operations and generate relevant code analysis results. This mechanism breaks the tight coupling between the editor and the language service, allowing the system to flexibly select service modules according to different operation types and support a development environment with multiple languages ​​and multiple operation types. Each language service module can independently handle specific tasks, such as syntax checking, code diagnosis, etc., to ensure the flexibility and scalability of the system. Ultimately, the system can generate language service results in real time and feedback to developers, significantly improving development efficiency and code quality.

[0074] S60, judging, by the language server based on the language service result, whether it is necessary to send feedback information to the editor;

[0075] In this embodiment, the language server first parses the generated language service results to identify key information therein, such as syntax errors, compilation problems, code prompts, etc. The language service results are usually stored in a standardized format, such as a JSON object or an XML document. The language server parses the result object and extracts key fields, such as error type, prompt information, warnings, etc. The parser can parse the output of different modules according to a predefined format or protocol.

[0076] The server needs to determine whether the key information meets the conditions for sending feedback to the editor. The conditions can be based on user preferences, the severity of the error, or the type of operation. The server can maintain a configuration file or user preferences to record what types of information need to be fed back to the editor. By comparing the parsed key information with the user preferences, it is determined whether it is necessary to send feedback to the editor. For example, if the user chooses to receive only serious error information instead of all warning information, the system will only send feedback when a serious error is found.

[0077] If feedback information needs to be sent, the server also needs to determine the priority of the feedback information so that the editor can choose how to present this information based on the priority. The language server sets a priority for each feedback message based on the parsed error level or the importance of the prompt information. For example, syntax errors may take precedence over code hints, and serious errors may take precedence over warnings. Priorities can be represented by numbers or labels such as "high", "medium", and "low".

[0078] Example description: In the development process of financial software, the quality of the code directly affects the security and stability of the financial system. For example, when developers are writing code involving payment and transaction processing, the language server finds syntax errors and security warnings after checking the code. By parsing the language service results, the language server determines that syntax errors are serious problems and must be fed back to the developer immediately, while security warnings are marked as minor prompts based on user preferences. In this case, developers can deal with serious problems in a timely manner to ensure that there are no errors in the core code of the financial system, while avoiding workflows affected by minor prompts. This mechanism greatly improves the code quality in financial software development and reduces system risks.

[0079] By parsing the language service results through the language server and determining whether feedback information needs to be sent to the editor, information redundancy can be effectively avoided, ensuring that developers only receive important feedback information and reducing unnecessary interference. Users can customize the type of feedback and information priority they receive according to their own needs, thereby improving development efficiency. At the same time, the system ensures that important issues can be handled in a timely manner through the feedback priority mechanism, which helps to quickly discover and solve key problems in the code. Ultimately, the system improves the user experience and improves code quality and development efficiency while ensuring the effectiveness of information transmission.

[0080] S70, if feedback information needs to be sent, determining language service feedback data that needs to be sent according to the language service result, and sending the language service feedback data to the editor according to the standard protocol;

[0081] In this embodiment, after determining that feedback information needs to be sent, the language server extracts or generates corresponding feedback data from the language service results. Feedback data generally includes error information, warning information, prompt information, etc. The language server sorts out the data that needs to be fed back based on the key information extracted from the language service results (such as error type, prompt information, etc.). The server may only extract error information of a specific level, such as syntax errors or compilation errors, according to the user's preference settings, and organize it into a standardized feedback data structure.

[0082] The extracted feedback data is encapsulated according to a predefined standard protocol so that it can be sent to the editor through a unified transmission method. The server encapsulates the feedback data into a data structure such as JSON or XML according to the format in the protocol, including fields such as feedback type (such as error, warning, prompt), feedback priority, and detailed description of feedback information. After encapsulation, the feedback data structure is ready to be sent to the editor.

[0083] The encapsulated feedback data needs to be sent to the editor through a standard protocol communication method (such as WebSocket or HTTP). The server sends the feedback data to the editor through a persistent WebSocket connection or through an HTTP request to ensure that the data can be transmitted smoothly. In WebSocket mode, the server can directly send the feedback data to the editor through an open communication channel; in HTTP mode, the server will send the data through a POST request and wait for the editor to confirm receipt.

[0084] The language server extracts feedback data based on judgment and sends it to the editor according to the standard protocol, which greatly improves the efficiency of feedback information transmission. Whether in real-time feedback mode or batch processing mode, developers can obtain error information, warnings or prompts related to the current operation in a timely manner to ensure the quality of code in the development process. By setting feedback priorities, the system can give priority to serious errors and reduce information overload and redundancy.

[0085] S80: updating the editing feedback information displayed in the editor interface according to the language service feedback data by the editor.

[0086] In this embodiment, the editor receives feedback data transmitted from the language server, and the feedback data usually includes syntax errors, compilation problems, code prompts, etc. The editor receives feedback data sent by the language server through a WebSocket connection or HTTP request. The data is usually encapsulated in a format such as JSON, XML, etc., and the editor uses a corresponding parser to extract the feedback information. The extracted data includes error types, prompt information, warnings, etc.

[0087] The editor parses the received feedback data and extracts key information, such as error type, warning level, line and column position, etc., so as to accurately display the feedback information in the interface. The received feedback data is parsed by a built-in parser (such as a JSON parser), and key fields for display are extracted, such as error type (syntax error, compilation error), prompt information, warning level, and error position (line and column number), and this information is stored in the editor's cache, ready for update and display.

[0088] Based on the parsed feedback data, the editor displays the information in the user interface. For example, by marking the error line, displaying a prompt box, or popping up error information prompts in certain areas. The editor updates different parts of the user interface through the rendering engine. For example:

[0089] Syntax Error: The editor highlights the error line and displays an error message next to the line.

[0090] Warning: Display code warning information through different color marks (such as yellow underline).

[0091] Hint: The editor displays relevant code hints or suggestions in the code completion prompt box to help developers quickly select appropriate code completion options.

[0092] Example: In financial system development, the accuracy of the code is directly related to the security and stability of the system. For example, when a developer modifies the code involved in transaction processing, the editor receives feedback data from the language server, prompting that some syntax errors and security warnings have been found. Based on this feedback information, the editor displays error prompts next to the code line and marks the code segments that may be risky. With timely feedback, developers can quickly fix errors and ensure the correctness and security of the financial transaction system code.

[0093] By updating the feedback information displayed on the interface based on the language service feedback data, the editor can respond to the developer's operations immediately and improve the efficiency and accuracy of code writing. The editor can clearly display errors, warnings and prompts in the user interface by parsing the feedback data, allowing developers to quickly locate problems and fix them in time.

[0094] The present invention relates to the technical field of R&D management and the field of financial technology, and discloses an analysis method for separating an editor from a language service. By defining a communication protocol between an editor and a language server, monitoring file processing operations in the editor, generating standard behavior events, and sending the standard behavior events to a language server through an editor, the language server parses the events, determines the corresponding file processing operation type, executes a language service based on the operation type, generates a service result, and determines whether feedback information needs to be sent to the editor; if it is determined that feedback is needed, language service feedback data is generated, and the feedback data is sent to the editor through a communication protocol, and the editor updates the editing feedback information displayed in the interface based on the feedback data. The present invention breaks the tight coupling between the editor and the language server, so that the development tool can adapt to different languages ​​and editors more flexibly, avoids the complexity of developing a language server for each language separately in different editors, and reduces the development cost. Finally, higher cross-platform compatibility and development efficiency are achieved.

[0095] In one embodiment, the above S10 includes:

[0096] S101, determining a data format of a standard protocol, wherein the data format is used to define a structure of an event identifier, an event type, and event detailed information;

[0097] S102, determining a communication mechanism in a standard protocol, where the communication mechanism is used to transmit messages between the editor and the language server;

[0098] S103, determining a message exchange standard of a standard protocol, wherein the message exchange standard is used to determine a message sending order and a response mechanism;

[0099] S104, establishing an error handling mechanism of a standard protocol, wherein the error handling mechanism is used to handle errors occurring during the communication process;

[0100] S105, establishing an authentication mechanism of a standard protocol, wherein the authentication mechanism is used to verify the identities of both communicating parties of the editor and the language server.

[0101] In this embodiment, a unique event identifier needs to be defined in the data format to distinguish different behavioral events and ensure the correctness of event processing. A unique string or digital identifier (such as UUID) is used as the event identifier, and each event is assigned a unique ID when it is generated for easy tracking and management.

[0102] Define the event type field to describe the category of the event, such as file opening, editing, saving, or closing. You can use a string or enumeration type to identify the event type. For example, "open" represents file opening, "edit" represents file editing, "save" represents file saving, and so on. Event types help the language server identify and handle different file operations.

[0103] The event details include specific information of the operation, such as file path, line and column position, and modified content, to ensure that the event can carry enough data to support the analysis of the language server. The detailed information is organized in the form of key-value pairs, and the fields include file path ("filePath"), line and column position ("line", "column"), modified content ("content"), etc. This information provides basic data for subsequent code analysis.

[0104] The protocol needs to support two-way communication, that is, the editor sends events to the language server, and the language server can also send responses to the editor. The WebSocket protocol is used to maintain a two-way communication channel, supporting real-time data transmission and event feedback. WebSocket allows low-latency, high-frequency interaction between the editor and the language server.

[0105] The protocol needs to clearly define the message transmission method to ensure that data can be transmitted securely and stably. Message transmission can be achieved through HTTP or WebSocket. HTTP is used in the traditional request-response mode, while WebSocket is suitable for real-time communication scenarios. The message transmission process needs to consider network delays, timeouts and other issues.

[0106] The message sending order specifies the order in which the editor sends messages, ensuring the correct logical order between different events. For example, a file open event should be sent before a file edit event. By defining a message queue management mechanism in the protocol, events are ensured to be sent in the order of generation or priority. The queue mechanism can prevent events from being transmitted out of order and ensure the integrity of the logic.

[0107] After receiving the event from the editor, the language server needs to send a response according to the rules defined in the protocol to confirm the event reception or return the analysis results. After processing the event, the server sends confirmation or feedback information to the editor through WebSocket or HTTP response. The protocol specifies timeout processing rules. If the response is not received within the specified time, the editor will trigger a retry mechanism.

[0108] During data transmission, errors such as connection interruption and data loss may occur. The protocol needs to specify how to handle such errors. The protocol defines an error code system. Whenever a network error, transmission failure, or data loss occurs, the editor and language server can take corresponding recovery actions based on the error code, such as retransmission, error log recording, or user notification.

[0109] When parsing or processing events sent by the editor, the language server may encounter malformed or unprocessable data. The protocol needs to define how to handle these errors. The protocol stipulates that when the language server cannot parse an event, it should return an error response containing a detailed description of the error and abort processing the event.

[0110] The editor and language server need to verify the identities of both parties during the communication process to ensure the security and legitimacy of data transmission. You can use OAuth 2.0 or certificate-based authentication mechanisms. In the early stages of communication, the editor authenticates through OAuth tokens or certificates. After successful authentication, data transmission is allowed to ensure that only authorized clients and servers can communicate.

[0111] The protocol needs to support encryption to ensure that sensitive data will not be tampered with or leaked during transmission. The SSL / TLS encryption layer is used to protect data transmission and ensure that all information is encrypted during transmission to prevent third parties from eavesdropping or tampering with data.

[0112] This embodiment defines a standard protocol to standardize and improve the communication between the editor and the language server, ensuring that different editors and language servers can communicate in a unified manner. The message format, communication mechanism, error handling and authentication mechanism of the standard protocol ensure the security, reliability and scalability of the system. It reduces the complexity of cross-platform development and enhances the flexibility of the system, allowing development tools to flexibly adapt to multiple languages ​​and editors, thereby improving development efficiency.

[0113] In one embodiment, the above S20 includes:

[0114] S201, monitoring the file opening operation through the event monitoring mechanism of the editor, obtaining the file path and file type, and generating a corresponding file opening event;

[0115] S202, monitoring the file editing operation through the event monitoring mechanism of the editor, detecting the file change, determining the row position and column position of the modification and the modified content, and generating a corresponding file editing event;

[0116] S203, monitoring the file saving operation through the event monitoring mechanism of the editor, obtaining the file saving time and modification summary, and generating a corresponding file saving event;

[0117] S204, monitoring the file closing operation through the event monitoring mechanism of the editor, obtaining the file closing time, and generating a corresponding file closing event.

[0118] In this embodiment, the editor needs to monitor the user's operation of opening a file, extract the file path and file type, and generate a standardized file open event. The editor monitors the file open event (such as the open event) of the operating system or the editor itself. When the user chooses to open a file, the event is triggered, the editor obtains the path and type of the file (such as a text file, a programming language file, etc.), and generates a corresponding "file open" event and records it.

[0119] When a user edits an open file, the editor needs to track content changes, record the line, column position and content where the modification occurred, and generate standardized file editing events. The editor listens for file content change events (such as change events). Each time a user makes a modification in a file, the editor records the specific line number, column number and content of the change, and generates a "file edit" event to ensure that the modification details can be passed to the language server for analysis later.

[0120] When a user saves a file, the editor needs to obtain the save time and the file's modification summary (such as the last modification time or file hash value) and generate a file save event. The editor listens for save operations (such as save events). When the user clicks the Save button or uses the Save shortcut key, the editor records the file save timestamp, modification summary or file hash value, and generates a "file save" event.

[0121] When the user closes a file, the editor needs to record the closing time and generate a file closing event to ensure the integrity of the file operation. The editor listens to file closing events (such as close events). When the user closes a file, the editor obtains the file closing time and generates a corresponding "file closing" event to record the status when the file operation ends.

[0122] This embodiment can accurately capture the user's behavior in file operations and generate standardized behavior events by monitoring the file processing operations in the editor. This ensures that the language server can provide accurate code analysis and feedback based on different file operations. Monitoring file opening, editing, saving, and closing operations not only ensures the integrity of the operation, but also lays a data foundation for subsequent code diagnosis, prompts, error checking and other services. The overall system is more compatible and scalable, can adapt to the needs of different development environments, and significantly improve the work efficiency of developers.

[0123] In one embodiment, the above S30 includes:

[0124] S301, encapsulating the standard behavior event according to the data format of the standard protocol through the editor;

[0125] S302, the editor establishes a communication connection with the language server based on the standard protocol;

[0126] S303, serializing the encapsulated standard behavior event according to the transmission format defined in the standard protocol through the editor;

[0127] S304, sending the serialized standard behavior event to the language server according to the standard protocol by the editor;

[0128] S305, the editor waits for the reception confirmation from the language server after sending. If the reception confirmation times out or fails, the editor performs an error handling operation or a resending operation.

[0129] In this embodiment, the editor needs to encapsulate the generated standard behavior events according to the data format in the standard protocol to ensure that the events can be correctly transmitted and parsed. The editor encapsulates the behavior events using the data format defined in the standard protocol. The data format can be JSON, XML, or other custom structures, and the encapsulated content includes event identification, type, detailed information, etc. Through this process, the editor ensures that the transmitted data conforms to the format specified by the protocol, ensuring its compatibility and parsability.

[0130] The editor needs to establish a communication connection with the language server according to the standard protocol to ensure that the encapsulated events can be transmitted. The editor establishes a connection with the language server through the communication mechanism in the standard protocol (such as HTTP, WebSocket, etc.). WebSocket is suitable for real-time two-way communication, and HTTP is suitable for a single request-response model. The editor establishes this connection when it starts or when it needs to communicate with the language server for the first time.

[0131] The editor serializes the encapsulated standard behavior event data according to the transmission format in the standard protocol. According to the transmission format specified by the protocol (such as binary or string format), the editor serializes the encapsulated event data. JSON data can be directly converted to a string, and XML data can be processed into a serialized stream as needed to adapt to the network transmission format.

[0132] The editor needs to send serialized standard behavior events to the language server through the communication channel. The editor sends serialized behavior events through methods such as WebSocket or HTTP POST. WebSocket maintains a continuous connection and is suitable for high-frequency, low-latency event transmission, while HTTP POST is suitable for less frequent, single event transmission scenarios. Data is sent to the language server through the network and waits for the server's receipt confirmation.

[0133] After sending event data, the editor needs to wait for the language server to confirm receipt. If the confirmation times out or fails, the editor needs to perform error handling or resend the operation. The editor sets a timeout for receiving confirmation. If the editor does not receive a confirmation response from the language server within the specified time, the editor will trigger the error handling mechanism and resend the data or record the log to ensure that the behavior event is not missed.

[0134] This embodiment solves the compatibility and communication problems between the editor and the language server by sending the standard behavior event to the language server according to the standard protocol. The standard protocol ensures that different editors and language servers can uniformly process behavior events, improving the efficiency of cross-platform development.

[0135] In one embodiment, the above S40 includes:

[0136] S401, the language server receives and parses the standard behavior event, and identifies the event type, event identifier, timestamp, and file operation data of the standard behavior event;

[0137] S402, matching the event type with a predefined file processing operation type;

[0138] S403, when the match is successful, determining the file processing operation type corresponding to the standard behavior event through the language server;

[0139] S404, analyzing the file operation data of the standard behavior event through the language server to determine the path of the file and the modified content of the file;

[0140] S405: The language server records the file processing operation type corresponding to the standard behavior event, as well as the file path and modified content into an event log.

[0141] In this embodiment, after receiving the standard behavior event sent by the editor, the language server needs to parse the event type, event identifier, timestamp and file operation data contained therein to identify the nature of the event. The language server parses the behavior event using the data format defined in the standard protocol. For example, if the event is sent in JSON format, the server uses the JSON parsing library to extract the event type, identifier, timestamp and related file operation data (such as file path, modified content, etc.).

[0142] The language server matches the event with the server's predefined operation type list based on the event type field to determine whether the event belongs to a file open, edit, save, or close operation. The server maintains a predefined file operation type mapping table or enumeration structure. For example, when the event type is parsed as "edit", the server matches the type with the file edit operation type. If the event type matches successfully, the server can determine that the event represents a certain file operation.

[0143] When the event type matches the predefined file operation type, the server determines the specific operation type of the event and continues processing based on this information. After a successful match, the server stores the operation type and marks the file operation type of the current event (such as file editing, saving, etc.) to provide a basis for subsequent steps.

[0144] In addition to the event type, the language server also needs to parse and analyze file operation data, such as the file path, modified row and column position and content, etc. The language server extracts the file operation data fields in the event, such as the file path, modified row and column information, etc. The server processes this information to ensure that the specific location and content of the file modification can be accurately tracked.

[0145] The server records the file processing operation type, file path, and file modification content in the event log for subsequent analysis, tracking, and debugging. The language server writes the key information of the event into the log system to ensure that the event can be analyzed and tracked later. The log information can include timestamp, operation type, file path, and file modification content.

[0146] This embodiment parses standard behavior events and determines the file processing operation type through the language server, which can ensure that the language server accurately identifies and classifies the events sent by the editor. This process standardizes the way events are handled, and the server can accurately parse and process whether it is a file open, edit, save or close operation. At the same time, by recording the operation type, file path and modified content, the system can effectively track file changes and enhance the accuracy of code analysis. The standardized event parsing process lays the foundation for subsequent syntax checking, code prompts and other services.

[0147] In one embodiment, the above S50 includes:

[0148] S501, the language server selects a corresponding language service module according to the file processing operation type;

[0149] S502, the language server extracts file operation data from the standard behavior event and transmits it to the selected language service module;

[0150] S503, the language service module performs language service based on the received file operation data;

[0151] S504, when the language service module completes executing the language service, it generates a corresponding language service result;

[0152] S505: Record the language service result through the language server.

[0153] In this embodiment, the language server selects the corresponding language service module to perform specific tasks, such as syntax checking, code diagnosis, automatic completion, etc., according to the parsed file processing operation type. The language server maintains a registry or mapping table of language service modules, and selects the corresponding service module according to different operation types (such as file editing, saving, etc.). For example, the file editing operation selects the syntax checking and error prompt module, and the file saving operation selects the code formatting module.

[0154] The language server needs to extract the file operation data (such as file path, modified content, row and column position, etc.) from the standard behavior event and pass it to the selected language service module as input. By parsing the file operation data field of the standard behavior event, the specific data required for analysis (such as file path, edited content, etc.) is extracted. The language server passes this data to the corresponding service module through function calls or interfaces so that the module can process it based on this data.

[0155] After receiving the file operation data, the language service module performs the corresponding service tasks, such as syntax checking, code completion prompts, or error diagnosis. The language service module performs predefined tasks internally. For example, the syntax checking module finds syntax errors based on the code structure and rules in the file, and the auto-completion module provides code suggestions based on the current editing position. The processing results will be generated inside the module.

[0156] After completing its task, the language service module generates corresponding language service results, which usually include error prompts, warning information, code completion suggestions, etc. The service module encapsulates the results into standardized result objects, including error type, prompt information, row and column position, etc. The result format needs to comply with the protocol so that the language server can process and feedback correctly.

[0157] After receiving the results generated by the service module, the language server records these results for subsequent processing or feedback. The server records the results to the log system or saves them to memory for later sending to the editor.

[0158] This embodiment uses a language server to execute the corresponding language service according to the file processing operation type, which can flexibly respond to the needs of different operation scenarios. Different operation types (such as editing, saving, closing, etc.) correspond to different service modules to ensure the efficiency and scalability of the system. The system can not only provide instant feedback when developers edit code, but also provide additional checks and prompts when saving or closing files to improve code quality. The language service results finally generated provide developers with specific code optimization suggestions and error prompts, significantly improving development efficiency and code robustness.

[0159] In one embodiment, the above S60 includes:

[0160] S601, the language server identifies key information from the language service result;

[0161] S602, the language server matches the key information with the editor preference settings, and determines whether feedback information needs to be sent to the editor based on the matching result;

[0162] S603: If the key information belongs to a type that allows feedback in the editor preference settings, confirm that feedback information needs to be sent to the editor, and determine the feedback priority of the corresponding feedback information according to the type of the key information and the editor preference settings.

[0163] In this embodiment, the language server extracts key information from the language service result, which includes syntax errors, compilation errors, code prompts or warning information. The language server parses the language service result object and extracts key information related to code quality. By analyzing the fields of the service result, such as error type, code prompt, line and column position, etc., the server can extract syntax errors, compilation errors, code prompts and warning information to ensure that the extracted information is feedback for the current file or code segment.

[0164] After extracting the key information, the server needs to match this information with the editor's user preferences to determine whether the user wants to receive specific types of information. Each user can configure preferences in the editor to define which types of feedback information to display, such as only receiving syntax errors or ignoring warnings. The server filters the extracted key information based on the user's preferences and matches the feedback types that the user is allowed to receive. If the key information matches the preferences, it further determines whether feedback needs to be sent.

[0165] If the key information matches the editor preferences, it is confirmed that feedback needs to be sent; if it does not match, the information is ignored. The server decides whether to send feedback based on the matching results. If the user's preferences explicitly allow feedback of a certain type of information (such as syntax errors), the server confirms that feedback is required for this type of information; conversely, if the information type is disabled by the user (such as ignoring warning messages), this type of information will not be sent to the editor.

[0166] For feedback information that needs to be sent, the server needs to determine the feedback priority based on the type of key information and the editor's preferences so that the editor can display these feedback information at different priorities. Feedback priority can be determined by system predefined rules or user configuration. For example, syntax errors are set to high priority, while code hints are set to low priority. The server assigns a priority label to each piece of information that needs feedback, allowing the editor to prioritize high-priority error prompts.

[0167] This embodiment uses the language server to identify key information of the language service results and match them with the editor preference settings. The system can determine whether feedback information needs to be sent based on user needs. This mechanism ensures that developers only receive important feedback, reduces information interference, and provides flexible personalized customization functions. The setting of feedback priority enables developers to quickly handle high-priority error or warning information, further improving development efficiency and code quality.

[0168] In one embodiment, an analysis device for separating an editor from a language service is provided, and the analysis device for separating an editor from a language service corresponds one-to-one to the analysis method for separating an editor from a language service in the above embodiment. Figure 3 , Figure 3 This is a functional module diagram of a preferred embodiment of the analysis device with separated editor and language service of the present invention. Communication protocol definition module 10, event monitoring module 20, event transmission module 30, event analysis module 40, language service execution module 50, feedback judgment module 60, feedback generation and transmission module 70 and interface update module 80. The functional modules are described in detail as follows:

[0169] A communication protocol definition module 10, used to define a standard protocol for communication between an editor and a language server;

[0170] An event monitoring module 20, used for monitoring file processing operations in the editor, and generating corresponding standard behavior events based on the file processing operations;

[0171] An event transmission module 30, configured to send the standard behavior event to the language server through the editor according to the standard protocol;

[0172] An event parsing module 40, configured to parse the standard behavior event through the language server to determine a file processing operation type corresponding to the standard behavior event;

[0173] A language service execution module 50, configured to execute a corresponding language service based on the file processing operation type through the language server and generate a language service result;

[0174] A feedback determination module 60, configured to determine whether feedback information needs to be sent to the editor based on the language service result through the language server;

[0175] A feedback generation and transmission module 70, for determining language service feedback data to be sent according to the language service result if feedback information needs to be sent, and sending the language service feedback data to the editor according to the standard protocol;

[0176] The interface updating module 80 is used to update the editing feedback information displayed in the editor interface according to the language service feedback data through the editor.

[0177] In one embodiment, the communication protocol definition module 10 is specifically used to:

[0178] Determining a data format of a standard protocol, the data format being used to define a structure of an event identifier, an event type, and event detailed information;

[0179] Determining a communication mechanism in a standard protocol for transmitting messages between the editor and the language server;

[0180] Determine a message exchange standard of a standard protocol, wherein the message exchange standard is used to determine a message sending order and a response mechanism;

[0181] Establishing an error handling mechanism of a standard protocol, wherein the error handling mechanism is used to handle errors occurring during the communication process;

[0182] An authentication mechanism of a standard protocol is established, where the authentication mechanism is used to verify the identities of both parties in communication between the editor and the language server.

[0183] In one embodiment, the event monitoring module 20 is specifically used to:

[0184] Monitor the file opening operation through the editor's event monitoring mechanism, obtain the file path and file type, and generate the corresponding file opening event;

[0185] Monitor file editing operations through the editor's event listening mechanism, detect file changes, determine the row and column positions where the changes occurred, and the content of the changes, and generate corresponding file editing events;

[0186] Monitor the file save operation through the editor's event monitoring mechanism, obtain the file save time and modification summary, and generate the corresponding file save event;

[0187] Monitor the file closing operation through the editor's event monitoring mechanism, obtain the file closing time, and generate the corresponding file closing event.

[0188] In one embodiment, the event transmission module 30 is specifically configured to:

[0189] Encapsulating the standard behavior event according to the data format of the standard protocol by the editor;

[0190] The editor establishes a communication connection with the language server based on the standard protocol;

[0191] Serializing the encapsulated standard behavior events according to the transmission format defined in the standard protocol through the editor;

[0192] Sending serialized standard behavior events to the language server through the editor according to the standard protocol;

[0193] After sending, the editor waits for the language server's reception confirmation. If the reception confirmation times out or fails, the editor performs error handling operations or resends the operation.

[0194] In one embodiment, the event analysis module 40 is specifically used to:

[0195] The language server receives and parses the standard behavior event, and identifies the event type, event identifier, timestamp, and file operation data of the standard behavior event;

[0196] Matching the event type with a predefined file processing operation type;

[0197] When the match is successful, the file processing operation type corresponding to the standard behavior event is determined through the language server;

[0198] Analyzing the file operation data of the standard behavior event through the language server to determine the path of the file and the modified content of the file;

[0199] The language server records the file processing operation type corresponding to the standard behavior event as well as the file path and modified content in the event log.

[0200] In one embodiment, the language service execution module 50 is specifically configured to:

[0201] The language server selects a corresponding language service module according to the file processing operation type;

[0202] The language server extracts the file operation data from the standard behavior event and transmits it to the selected language service module;

[0203] The language service module performs language service based on the received file operation data;

[0204] When the language service module completes the execution of the language service, it generates a corresponding language service result;

[0205] The language service result is recorded by the language server.

[0206] In one embodiment, the feedback determination module 60 is specifically configured to:

[0207] The language server identifies key information from the language service result;

[0208] The language server matches the key information with the editor preference settings, and determines whether feedback information needs to be sent to the editor based on the matching result;

[0209] If the key information belongs to the type that allows feedback in the editor preference settings, it is confirmed that the feedback information needs to be sent to the editor, and the feedback priority of the corresponding feedback information is determined according to the type of the key information and the editor preference settings.

[0210] In one embodiment, a computer device is provided. The computer device may be a server, and its internal structure diagram may be as follows: Figure 4 As shown. The computer device includes a processor, a memory, a network interface and a database connected via a system bus. The processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile and / or volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program and a database. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The network interface of the computer device is used to communicate with an external user terminal via a network connection. When the computer program is executed by the processor, the server-side functions or steps of an analysis method for separating an editor from a language service are implemented.

[0211] In one embodiment, a computer device is provided. The computer device may be a user terminal, and its internal structure diagram may be as follows: Figure 5As shown. The computer device includes a processor, a memory, a network interface, a display screen and an input device connected via a system bus. The processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system and a computer program. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The network interface of the computer device is used to communicate with an external server via a network connection. When the computer program is executed by the processor, the functions or steps on the user side of the analysis method for separating an editor from a language service are implemented.

[0212] In one embodiment, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the following steps when executing the computer program:

[0213] Defines a standard protocol for communication between editors and language servers;

[0214] Monitoring file processing operations in the editor, and generating corresponding standard behavior events based on the file processing operations;

[0215] Sending the standard behavior event to the language server according to the standard protocol by the editor;

[0216] Parsing the standard behavior event by the language server to determine the file processing operation type corresponding to the standard behavior event;

[0217] The language server executes a corresponding language service based on the file processing operation type and generates a language service result;

[0218] Determining, by the language server based on the language service result, whether it is necessary to send feedback information to the editor;

[0219] If feedback information needs to be sent, determining the language service feedback data that needs to be sent according to the language service result, and sending the language service feedback data to the editor according to the standard protocol;

[0220] The editor updates the editing feedback information displayed in the editor interface according to the language service feedback data.

[0221] In one embodiment, a computer-readable storage medium is provided, on which a computer program is stored, and when the computer program is executed by a processor, the following steps are implemented:

[0222] Defines a standard protocol for communication between editors and language servers;

[0223] Monitoring file processing operations in the editor, and generating corresponding standard behavior events based on the file processing operations;

[0224] Sending the standard behavior event to the language server according to the standard protocol by the editor;

[0225] Parsing the standard behavior event by the language server to determine the file processing operation type corresponding to the standard behavior event;

[0226] The language server executes a corresponding language service based on the file processing operation type and generates a language service result;

[0227] Determining, by the language server based on the language service result, whether it is necessary to send feedback information to the editor;

[0228] If feedback information needs to be sent, determining the language service feedback data that needs to be sent according to the language service result, and sending the language service feedback data to the editor according to the standard protocol;

[0229] The editor updates the editing feedback information displayed in the editor interface according to the language service feedback data.

[0230] It should be noted that the above functions or steps that can be implemented by the computer-readable storage medium or computer device can refer to the relevant descriptions on the server side and the user side in the aforementioned method embodiment. To avoid repetition, they will not be described one by one here.

[0231] Those skilled in the art can understand that all or part of the processes in the above-mentioned embodiment methods can be completed by instructing the relevant hardware through a computer program, and the computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to memory, storage, database or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM) or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. As an illustration and not limitation, RAM is available in many forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link (Synchlink) DRAM (SLDRAM), memory bus (Rambus) direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM).

[0232] Those skilled in the art can clearly understand that for the convenience and simplicity of description, only the division of the above-mentioned functional units and modules is used as an example. In actual applications, the above-mentioned functions can be distributed and completed by different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above.

[0233] It should be noted that if software tools or components other than those of the Company appear in the embodiments of the present application, they are only used for illustration and do not represent actual use. The above-described embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit them; although the present invention has been described in detail with reference to the above-mentioned embodiments, a person of ordinary skill in the art should understand that the technical solutions described in the above-mentioned embodiments can still be modified, or some of the technical features thereof can be replaced by equivalents; and these modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be included in the protection scope of the present invention.

Claims

1. An analysis method for separating an editor from a language service, characterized in that: The following steps are involved: Defines a standard protocol for communication between editors and language servers; Monitoring file processing operations in the editor, and generating corresponding standard behavior events based on the file processing operations; Sending the standard behavior event to the language server according to the standard protocol by the editor; Parsing the standard behavior event by the language server to determine the file processing operation type corresponding to the standard behavior event; The language server executes a corresponding language service based on the file processing operation type and generates a language service result; Determining, by the language server based on the language service result, whether it is necessary to send feedback information to the editor; If feedback information needs to be sent, determining the language service feedback data that needs to be sent according to the language service result, and sending the language service feedback data to the editor according to the standard protocol; The editor updates the editing feedback information displayed in the editor interface according to the language service feedback data.

2. The analysis method for separating the editor from the language service according to claim 1, characterized in that: Defines a standard protocol for communication between editors and language servers, including: Determining a data format of a standard protocol, the data format being used to define a structure of an event identifier, an event type, and event detailed information; Determining a communication mechanism in a standard protocol for transmitting messages between the editor and the language server; Determine a message exchange standard of a standard protocol, wherein the message exchange standard is used to determine a message sending order and a response mechanism; Establishing an error handling mechanism of a standard protocol, wherein the error handling mechanism is used to handle errors occurring during the communication process; An authentication mechanism of a standard protocol is established, where the authentication mechanism is used to verify the identities of both parties in communication between the editor and the language server.

3. The analysis method for separating the editor from the language service according to claim 1, characterized in that: Monitoring file processing operations in the editor and generating corresponding standard behavior events based on the file processing operations include: Monitor the file opening operation through the editor's event monitoring mechanism, obtain the file path and file type, and generate the corresponding file opening event; Monitor file editing operations through the editor's event monitoring mechanism, detect file changes, determine the row and column positions where the changes occurred, and the content of the changes, and generate corresponding file editing events; Monitor the file save operation through the editor's event monitoring mechanism, obtain the file save time and modification summary, and generate the corresponding file save event; Monitor the file closing operation through the editor's event monitoring mechanism, obtain the file closing time, and generate the corresponding file closing event.

4. The analysis method for separating the editor from the language service according to claim 1, characterized in that: Sending the standard behavior event to the language server according to the standard protocol by the editor includes: Encapsulating the standard behavior event according to the data format of the standard protocol by the editor; The editor establishes a communication connection with the language server based on the standard protocol; Serializing the encapsulated standard behavior events according to the transmission format defined in the standard protocol through the editor; Sending serialized standard behavior events to the language server through the editor according to the standard protocol; After sending, the editor waits for the language server's reception confirmation. If the reception confirmation times out or fails, the editor performs error handling operations or resends the operation.

5. The analysis method for separating the editor from the language service as claimed in claim 1, characterized in that: Parsing the standard behavior event by the language server to determine the file processing operation type corresponding to the standard behavior event includes: The language server receives and parses the standard behavior event, and identifies the event type, event identifier, timestamp, and file operation data of the standard behavior event; Matching the event type with a predefined file processing operation type; When the match is successful, the file processing operation type corresponding to the standard behavior event is determined through the language server; Analyzing the file operation data of the standard behavior event through the language server to determine the path of the file and the modified content of the file; The language server records the file processing operation type corresponding to the standard behavior event as well as the file path and modified content in the event log.

6. The analysis method for separating the editor from the language service according to claim 1, characterized in that: The language server executes a corresponding language service based on the file processing operation type and generates a language service result, including: The language server selects a corresponding language service module according to the file processing operation type; The language server extracts the file operation data from the standard behavior event and transmits it to the selected language service module; The language service module performs language service based on the received file operation data; When the language service module completes the execution of the language service, it generates a corresponding language service result; The language service result is recorded by the language server.

7. The analysis method for separating the editor from the language service according to claim 1, characterized in that: The language server determines whether feedback information needs to be sent to the editor based on the language service result, including: The language server identifies key information from the language service result; The language server matches the key information with the editor preference settings, and determines whether feedback information needs to be sent to the editor based on the matching result; If the key information belongs to the type that allows feedback in the editor preference settings, it is confirmed that the feedback information needs to be sent to the editor, and the feedback priority of the corresponding feedback information is determined according to the type of the key information and the editor preference settings.

8. An analysis device with a separate editor and language service, characterized in that: The analysis device in which the editor is separated from the language service comprises: The communication protocol definition module is used to define the standard protocol for communication between the editor and the language server; An event monitoring module, used for monitoring file processing operations in the editor, and generating corresponding standard behavior events based on the file processing operations; An event transmission module, configured to send the standard behavior event to the language server through the editor according to the standard protocol; An event parsing module, configured to parse the standard behavior event through the language server and determine a file processing operation type corresponding to the standard behavior event; A language service execution module, configured to execute a corresponding language service based on the file processing operation type through the language server and generate a language service result; A feedback judgment module, configured to judge whether it is necessary to send feedback information to the editor based on the language service result through the language server; A feedback generation and transmission module, configured to determine language service feedback data to be sent according to the language service result if feedback information needs to be sent, and send the language service feedback data to the editor according to the standard protocol; The interface updating module is used to update the editing feedback information displayed in the editor interface according to the language service feedback data through the editor.

9. A computer device, characterized in that: The computer device includes a memory, a processor, and an analysis program for separating an editor from a language service that is stored in the memory and can be run on the processor. When the analysis program for separating an editor from a language service is executed by the processor, the steps of the analysis method for separating an editor from a language service are implemented as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that: The storage medium stores an analysis program for separating an editor from a language service, and when the analysis program for separating an editor from a language service is executed by a processor, the steps of the analysis method for separating an editor from a language service according to any one of claims 1 to 7 are implemented.

Images