Support .aeproj projects

[0xWDG]

Support .aeproj projects

• Finder must see those directories as a Bundle Package like xcode.
• AE Needs to open on double click

For later, and out of scope for this issue, AuroraEditor needs to actually open/handle the project file.

[ladvoc]

Has there been any discussion of the format AuroraEditor's .aeproj bundle format will take?

One of my biggest gripes with Xcode is the format of the .pbxproj file inside the project package bundle. When adding or regrouping sources in Xcode, this file is automatically updated. Sometimes, I would like to create or modify a few files and create one commit per change (for organizational purposes). However, when I do this, I have to manually go through the .pbxproj excluding file references that don't belong in my next commit.

Perhaps .aeproj can be better in this regard by storing file references in a human readable format such as TOML or YAML.

[rishaandesai]

I don't believe there's been any talk about implementing this in the near future, as the team is quite busy with other things at the moment.

[nanashili]

Has there been any discussion of the format AuroraEditor's .aeproj bundle format will take?

One of my biggest gripes with Xcode is the format of the .pbxproj file inside the project package bundle. When adding or regrouping sources in Xcode, this file is automatically updated. Sometimes, I would like to create or modify a few files and create one commit per change (for organizational purposes). However, when I do this, I have to manually go through the .pbxproj excluding file references that don't belong in my next commit.

Perhaps .aeproj can be better in this regard by storing file references in a human readable format such as TOML or YAML.

At the look of it, it would have been in a json format based on the idea that @0xWDG had. If you think we should use toml or yaml for the .aeproj we can do that too.

Also if you wanna start on this your more than welcome since majority of us are busy with totally other parts of the editor at the moment.

[0xWDG]

I started with a JSON because it's so easily decodable by swift.
Some people had suggested it needed to be a directory with multiple files (like Xcode), but I'm not sure if that is required, and otherwise it can be build in later.

I think the best option is json or yaml / toml.

[ladvoc]

Should .aeproj keep track of every file like Xcode projects do? An advantage of this is that the editor can keep track of per-file settings and allow the user to move and regroup files. However, a potential disadvantage is the complications this can introduce with Git, and if the project is edited using an external editor, the project file will not be updated (introducing missing/dangling references). My inclination is that the format should allow a project to be configured with or without file references, but I would like to hear your thoughts.

[KaiTheRedNinja]

i would think that if we’re going that route, the only file system data that would be stored is say the order of files within a folder, so that ae doesn’t need a full index of the file system

[0xWDG]

I think only saving the files in the particular order (or only the directories for what is explained above).

You want to re-index (file contents) on every opening of a project (like VSCode and others) does as well.

we must keep (especially for the first versions) it as simple as needed

[ladvoc]

After playing around for a while, I thought of an interesting hierarical format which might have some promise. This format does not require files and directories be explicitly listed unless they need specific configuration, and its hierarchal nature allows some configuration defined in a higher scope to propagate downward. These features would make for small, manageable project files.

Keys prefixed with $ denote configuration properties, and all other keys represent path components relative to their parent directory (or the project directory at file scope). In this simple example, since no files or directories are mentioned explicitly, configuration properties at file scope apply to everything in the project. In this case, everything would be sorted by file type.

---
# Aurora Editor Project
$displayName: Aurora Editor
$buildSystem: xcode
$configVersion: "0.1"
$sortBy: fileType
...

Now let's say I would like to sort alphabetically, but just inside the AuroraEditor/Base directory. I only need to specify that particular directory:

---
# Aurora Editor Project
$displayName: Aurora Editor
$buildSystem: xcode
$configVersion: "0.1"
$sortBy: fileType
AuroraEditor/Base:
    $sortBy: alphabetical
...

As $sortBy: fileType is still included in the parent scope, all other files will still be sorted by file type.

Let's consider a more complex example:

---
# Aurora Editor Project
$displayName: Aurora Editor
$buildSystem: xcode
$configVersion: "0.1"
$sortBy: fileType
AuroraEditor:
  Base:
      $sortBy: alphabetical
      About: { $hidden: true }
      Editor/Extensions:    # explicit ordering of files within directory
          - CodeEditor+Position.swift
          - ScrollView.swift
      TerminalEmulator: { $sortBy: dateModified }
  Application:   { $order: descending, $showMinimap: false }
  CodeLanguages: { $sortBy: dateModified, $order: ascending }
  Services:      { $hidden: true }
...

Note that some configuration properties, such as $configVersion, are only valid at file scope as applying them to specific files or directories would be meaningless. Also note these examples are to demonstrate the file structure—not the particular configuration options that should be available. I would like to hear your feedback.

[nanashili]

After playing around for a while, I thought of an interesting hierarical format which might have some promise. This format does not require files and directories be explicitly listed unless they need specific configuration, and its hierarchal nature allows some configuration defined in a higher scope to propagate downward. These features would make for small, manageable project files.

Keys prefixed with $ denote configuration properties, and all other keys represent path components relative to their parent directory (or the project directory at file scope). In this simple example, since no files or directories are mentioned explicitly, configuration properties at file scope apply to everything in the project. In this case, everything would be sorted by file type.

---
# Aurora Editor Project
$displayName: Aurora Editor
$buildSystem: xcode
$configVersion: "0.1"
$sortBy: fileType
...

Now let's say I would like to sort alphabetically, but just inside the AuroraEditor/Base directory. I only need to specify that particular directory:

---
# Aurora Editor Project
$displayName: Aurora Editor
$buildSystem: xcode
$configVersion: "0.1"
$sortBy: fileType
AuroraEditor/Base:
    $sortBy: alphabetical
...

As $sortBy: fileType is still included in the parent scope, all other files will still be sorted by file type.

Let's consider a more complex example:

---
# Aurora Editor Project
$displayName: Aurora Editor
$buildSystem: xcode
$configVersion: "0.1"
$sortBy: fileType
AuroraEditor:
  Base:
      $sortBy: alphabetical
      About: { $hidden: true }
      Editor/Extensions:    # explicit ordering of files within directory
          - CodeEditor+Position.swift
          - ScrollView.swift
      TerminalEmulator: { $sortBy: dateModified }
  Application:   { $order: descending, $showMinimap: false }
  CodeLanguages: { $sortBy: dateModified, $order: ascending }
  Services:      { $hidden: true }
...

Note that some configuration properties, such as $configVersion, are only valid at file scope as applying them to specific files or directories would be meaningless. Also note these examples are to demonstrate the file structure—not the particular configuration options that should be available. I would like to hear your feedback.

I like this approach, it follows a similar approach to that of Visual Studio and Intelli J in a sense... That could definitely work. The question is would there be any performance impact if we have different directories be sorted differently from that of the main directory?

[ladvoc]

Using this format, we should be able to decode the .aeproj file to an in-memory tree structure in order to efficiently retrieve configuration for each sub-directory.

I would like to share another idea I had. I'm not sure which is better—I think both have pros and cons. Instead of defining the configuration hierarchy in the main project file, we could use the filesystem itself.

Using this approach, there would still be a .aeproj file at the project root defining project-wide configuration and defaults for directory organization:

---
# Aurora Editor Project
displayName: Aurora Editor
buildSystem: xcode
configVersion: "0.1"
sortBy: fileType
...

Now let's say I would like to change the sorting method specifically for the AuroraEditor/Application directory. Using this approach, I would add a dot file in this directory called .aurora which defines configuration overrides for this specific directory:

---
# AuroraEditor/Application/.aurora
sortBy: dateModified
...

This approach is similar how macOS uses .DS_Store. Changing configuration of a single directory does not require the global project file to be modified which could be advantageous.