AUR-0001 - Proposal: Dynamic Language Loading System for CodeLanguage in AuroraEditor

[nanashili]

Dynamic Language Loading System for CodeLanguage in AuroraEditor

Proposal Details

• Proposal ID: AUR-0001
• Author: Nanashi Li
• Status: Draft

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 versatile CodeLanguage structure, a user-friendly configuration interface, and updated APIs for language management.

Enhanced LanguageRegistry Class

The 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:

public class LanguageRegistry {
    public static let shared = LanguageRegistry()
    private var staticLanguages: [String: CodeLanguage] = [:]
    private var dynamicLanguages: [String: CodeLanguage] = [:]

    public func registerDynamicLanguage(languageConfig: CodeLanguage) {
        let languageID = languageConfig.id.rawValue
        if staticLanguages[languageID] != nil || dynamicLanguages[languageID] != nil {
            print("Warning: Attempt to register an already existing language.")
            return
        }

        dynamicLanguages[languageID] = languageConfig
        notifyLanguageRegistration(languageConfig.id)
    }

    private func notifyLanguageRegistration(_ id: TreeSitterLanguage) {
        NotificationCenter.default.post(
            name: .languageRegistered,
            object: self,
            userInfo: ["languageID": id]
        )
    }

    // Handling potential race conditions with a thread-safe implementation
    // and methods for language retrieval, updating, and deletion...
}

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:

public struct CodeLanguage {
    var languageRegistry: LanguageRegistry = .shared
    public let id: TreeSitterLanguage
    public let tsName: String
    public let extensions: Set<String>

    public init?(configData: Data) {
        // Assume configData is JSON for simplicity. Error handling should address missing keys or incorrect formats.
        guard let config = try? JSONDecoder().decode(LanguageConfiguration.self, from: configData) else {
            print("Error: Invalid language configuration data.")
            return nil
        }

        self.id = config.id
        self.tsName = config.tsName
        self.extensions = config.extensions
    }

    // Additional methods and properties...
}

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:

1. Language Information Collection: The interface collects basic information, including language name, file extensions, and possibly a syntax definition or reference.
2. Validation: The input data is validated for completeness and correctness.
3. Language Creation: Upon validation, a 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:

// AuroraEditorSupportedLanguages.h

extern void registerDynamicLanguage(NSString *languageName, LanguageConfig config);
extern void updateDynamicLanguage(NSString *languageName, LanguageConfig config);
extern void removeDynamicLanguage(NSString *languageName);
extern TSLanguage *getDynamicLanguage(NSString *languageName);

// AuroraEditorSupportedLanguages.m

void registerDynamicLanguage(NSString *languageName, LanguageConfig config) {
    // Implementation similar to the provided registerDynamicLanguage snippet...
}

void updateDynamicLanguage(NSString *languageName, LanguageConfig config) {
    // Implementation to update an existing language's configuration...
}

void removeDynamicLanguage(NSString *languageName) {
    // Implementation to remove a dynamically added language...
}

TSLanguage *getDynamicLanguage(NSString *languageName) {
    // Implementation to retrieve a dynamically added language...
}

Edge Case Considerations

• Duplicate Languages: Implement checks to prevent users from adding languages that already exist.
• Invalid Configurations: Implement comprehensive validation for user input to ensure that only correct and complete language configurations are accepted.
• Concurrency: Ensure that all modifications to the language registry are thread-safe.
• Language Updates and Deletion: Provide clear mechanisms for updating and removing languages to avoid any inconsistencies or orphaned settings.

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.

[aurora-care-bear]

Thanks for submitting a issue!
to assign this issue to yourself please comment @aurora-care-bear please assign me

[Maartz]

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?

[nanashili]

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:

1. 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.

2. 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.

3. 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.

4. 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.