Open nanashili opened 6 months ago
Thanks for submitting a issue!
to assign this issue to yourself please comment @aurora-care-bear please assign me
If I understand it correctly, the config should be fed via a JSON provided by the user?
Duplicate Languages: Implement checks to prevent users from adding languages that already exist.
AE keep the config a la VSCode in a gigantic JSON too?
Yes, the language configuration would be provided by the user in a JSON format. This approach allows users to define new languages by specifying necessary attributes like the language name, associated file extensions, syntax definitions, etc., in a structured and familiar format.
Regarding the storage of configurations, while the proposal suggests using JSON for individual language configurations, it doesn't necessarily mandate storing all configurations in a single "gigantic" JSON file like VSCode. However, this approach can be adopted for ease of access and uniformity, especially if the editor is expected to handle numerous custom language configurations. The key points to consider would be:
Ease of Management: A single JSON file can simplify the process of managing language configurations, making it easier to access and update the settings. However, it might become cumbersome as the file grows.
Performance: Loading and parsing a very large JSON file could impact the editor's startup time and performance, especially if the file contains configurations for many languages.
User Experience: Users might find it easier to navigate and edit a single configuration file, or they might prefer individual files for better organization, depending on their background and preferences.
Version Control and Sharing: A single file might be easier to version control and share among a team or community, but individual files can be more manageable and less prone to merge conflicts.
In conclusion, whether to store all configurations in a single file or use separate files for each language could depend on various factors including the expected number of custom languages, user preferences, and the editor's architecture. It might also be beneficial to provide an interface within the editor to manage these configurations, abstracting away the underlying storage mechanism.
Dynamic Language Loading System for CodeLanguage in AuroraEditor
Proposal Details
Introduction
This proposal aims to introduce a robust and flexible system for dynamic language support within the Aurora Editor, allowing users to add and configure new programming languages directly from the editor interface. This document provides an exhaustive overview of the proposed features, detailed design, edge cases, and the necessary code implementations to achieve a comprehensive solution.
System Overview
The dynamic language support system will consist of several interconnected components that facilitate the addition, configuration, modification, and retrieval of user-defined programming languages within the Aurora Editor. These components include an enhanced
LanguageRegistry
class, a versatileCodeLanguage
structure, a user-friendly configuration interface, and updated APIs for language management.Enhanced
LanguageRegistry
ClassThe
LanguageRegistry
class will be the central hub for managing both predefined and dynamically added languages. It will need to handle various edge cases, such as duplicate language entries, invalid configurations, and concurrency issues.Code Implementation:
Modification of the CodeLanguage Structure
The
CodeLanguage
structure should be flexible enough to accommodate various language specifications and handle edge cases, like missing or incorrect configuration data.Code Implementation:
Language Configuration Interface
A graphical user interface will be necessary to facilitate the creation and modification of language configurations. This interface should validate user input to prevent the creation of invalid or incomplete language definitions.
Suggested Interface Workflow:
CodeLanguage
instance is created and registered.API Updates for Language Management
The APIs within
AuroraEditorSupportedLanguages.h/m
need to be expanded to provide comprehensive language management capabilities, including adding, updating, and removing languages.Code Implementation:
Edge Case Considerations
Conclusion
Implementing the proposed dynamic language support system will significantly enhance the adaptability and utility of the Aurora Editor, making it an even more valuable tool for developers. By addressing various use cases and edge cases, the system will provide a seamless and robust experience for users wishing to extend the editor's capabilities.