Instead of displaying a standard open screen on launch, we might create a Welcome screen similar to Xcode's.

This screen would have a checkbox that says "Show this window when CodeEdit launches" that would also be found in Preferences.

This should be togglable between visible and hidden in the view menu and in preferences.

I just stumbled onto this project today, and I'm super pumped to see it! I'm always excited about new development tools for macOS, particular editors!

I work on a macOS editor called Chime. While it is a commercial product, we have a very heavy emphasis on open sourcing the app's internals. We are big believers in small, focused libraries. I've worked with a few other editor projects via these libraries, and I was hoping we might be able to do the same.

Our biggest focuses are LSP, tree-sitter, text/NSTextView-specific stuff, as well as more general-purpose AppKit stuff. All available on our GitHub account, or at Swift Package Index. We've also got a higher-level project brewing built on top of the lower-level tree-sitter lib for performant highlighting and indenting. This one isn't completely pulled out of the main app yet, but its really useful for many editor-like projects, so it something we want to prioritize more.

I'm not sure what your plans are in these areas, but I'd love to see how we could work together more.

When writing code like swiftui or HTML, we always expect a preview view. So in this way, we can know what we are doing or changing. Also, data analyst needs this too.

When in fullscreen the preference screen goes full screen instead of keeping its original size.

A diff view and tree view built in for git (and other version control systems) would be a great addition. One less plugin needed :)

Opening diff view from CLI would also be nice to have.

Can you guys create a release, for playing around, without downloading source
Would be nice if it could auto update

A few of us have been seeing the following message when trying to build automatic previews in Xcode.

MessageSendFailure: Message send failure for send previewInstances message to agent

==================================

|  RemoteHumanReadableError
|  
|  LoadingError: failed to load library at path "/Users/austincondiff/Library/Containers/austincondiff.CodeEdit/Data/FileTabRow.1.preview-thunk.dylib": Optional(dlopen(/Users/austincondiff/Library/Containers/austincondiff.CodeEdit/Data/FileTabRow.1.preview-thunk.dylib, 0x0002): tried: '/Users/austincondiff/Library/Developer/Xcode/DerivedData/CodeEdit-eucuzfpvpmbixxgjmirxpilehkpw/Build/Intermediates.noindex/Previews/CodeEdit/Products/Debug/FileTabRow.1.preview-thunk.dylib' (no such file), '/Users/austincondiff/Library/Containers/austincondiff.CodeEdit/Data/FileTabRow.1.preview-thunk.dylib' (code signature in <5AFC16EE-9F89-393F-B5F1-20329D5B5EB5> '/Users/austincondiff/Library/Containers/austincondiff.CodeEdit/Data/FileTabRow.1.preview-thunk.dylib' not valid for use in process: mapped file has no Team ID and is not a platform binary (signed with custom identity or adhoc?)), '/usr/local/lib/FileTabRow.1.preview-thunk.dylib' (no such file), '/usr/lib/FileTabRow.1.preview-thunk.dylib' (no such file))

I was under the assumption we didn't want a team ID because it caused errors when other people pull the code down. If I put a team ID in anyways, the automatic preview hangs and times out.

We need to fix this to improve productivity among project contributors.

Set up a group of volunteers to do code reviews, as also mentioned in the Discord.

https://discord.com/channels/951544472238444645/954084547694325861/954116870024343603

Currently in the project navigator in the sidebar, files and folders are listed together. Folders need to all go above files. Maybe we have a setting that controls this behavior, but folders above files should be the default behavior.

One unique thing about Apple devices whether it be the iPhone iPad or Mac, they conform their UI to your wallpaper. Between vibrancy effects and window tinting. So that being in the case why not follow suit with syntax highlighting?

We could provide an option to automatically generate a theme based on the users window tint color. We could give the user the option of using different strategies – complementary, monochromatic, analogous, triadic, tetriadic etc.

When trying to open a recent file from the list on Welcome Screen it will not open. It prints an error message in the console:

Error Domain=NSCocoaErrorDomain Code=257 "The file “NodeJS” couldn’t be opened because you don’t have permission to view it." 
UserInfo={NSURL=file:///[...]/NodeJS, NSFilePath=[...]/NodeJS, NSUnderlyingError=0x6000038b80c0 {Error Domain=NSPOSIXErrorDomain Code=1 "Operation not permitted"}}

We need to be able to set the font size for the editor. There should be a setting in the preferences window and Cmd + and Cmd - should do this when the editor is in focus.

Do we plan on building a create project screen similar to that of Xcode? And if we are is someone busy building it if not im willing to give a go at it!

If the app is closed without first closing project window(s), we should remember which directory was open and which tabs were open so when the user starts the app again, instead of displaying the welcome screen, it will open in the state you were in so you can pick up where you left off.

It takes a few seconds to open files once clicked (See #20). Before fixing this, let's take this opportunity to handle large files that may take a while to load.

If the file takes a while to open, the UI should respond to the users action immediately, otherwise they will think the app is frozen/broken.

I'd recommend opening an empty tab with a label of filename from the file tree in the sidebar. Then we would display a loading spinner in place of the icon. If hovered the loading spinner is replaced with a close icon button to close the tab if it is taking too long. Either that or simply display a loading spinner in the center of the content area.

Once loading is complete, the file contents are displayed.

This way the UI is responsive to user action and it will not feel as laggy or broken.

Overview

Support for JS/TS extensions is planned for the initial release of CodeEdit. The extension system will provide similar capabilities to that of other editors, such as VS Code.

Contributing

If you wish to contribute to building the CodeEdit extension architecture, please see the tasks below and review the relevant parts of the API documentation repository. This documentation should be used as the guide for development.

PLEASE NOTE THE DOCUMENTATION IS STILL WORK IN PROGRESS. TASKS AND THEIR RELATED GITHUB ISSUES WILL BE UPDATED AS THE RELEVANT DOCUMENTATION IS COMPLETED.

Each API feature functionality first needs to be built into CodeEdit so that it can be used internally by the application and then later exposed to extensions through the API.

Tasks

• #180
• #183
• #167
• CodeEditApp/CodeEditTextView#32
• #391
• #222
• #220
• CodeEditApp/CodeEditTextView#40
• #224
• #262
• #392
• Data Storage
• Display Notifications
• Themes
• Custom UI support with React Components
• Extension Debug Console
• #107

References

• Atom Extension API
• VS Code Extension API
• VS Code Extension Examples
• Raycast Extension API
• Nova Extension API
• Sketch Extension API

Notice the height of each item in Xcode is 22px while in CodeEdit it is 28. We need to use a more compact item size to match. This will be useful in large projects. This should also be a setting so that the user could choose list item density across the app (will affect more than just the project navigator). The default should be compact.

Since the platform version of CodeEditModules currently is .v11 and prohibits using recent SwiftUI additions like background materials, we decided to bump it to .v12.

The problem with this is that GitHub Actions yet only works with macOS 11 and thus tests will fail.

We need to figure out a way to run the workflow on macOS 12 somehow.

@MarcoCarnevali said he will have a look at it soon.

Now the Github Action's lint is strict mode but not local. Should we open strict mode local too?

And do we need adding a SwiftLint pre-commit hook to check before commit?

Icons in each sidebar’s dock needs to be able to be reordered via drag and drop.

Please note that this will need to be applied to the navigator sidebar (left) and the inspector sidebar (right).

Also, keep in mind that we will eventually need the ability to drag these icons down to create a split sidebar like this. This is not required for this PR but we will need this at some point.

This should be saved and synced across all open workspaces, persisting after the app is closed and reopened. It should not be in the preferences UI or in preferences.json. In the View menu, we should have an item labeled “Reset Workspace Layout To Default” that resets this setting to default.

This setting should track icon location per pane, per sidebar. So for example, it can look like this:

• Navigator Sidebar
  • panel 1
    • project
    • source control
    • find
  • panel 2
    • debug
    • tasks
    • symbols
• Inspector Sidebar
  • panel 1
    • source control
    • file
    • quick help

This should be togglable between visible and hidden in the view menu and in preferences.

Overview

We need to implement a fully featured editor view. This view sits inside the Workspace UI (#346). We need to determine if we should roll our own or use an existing solution.

Features

Our code editor view should include the following features

• Syntax Highlighting
  • CodeEditApp/CodeEditLanguages#10
• #189
• #98
• CodeEditApp/CodeEditSourceEditor#30
• CodeEditApp/CodeEditSourceEditor#46
• CodeEditApp/CodeEditSourceEditor#47
• CodeEditApp/CodeEditSourceEditor#29
• CodeEditApp/CodeEditSourceEditor#32
• Code Validation
• Messages - errors, warnings, info
• CodeEditApp/CodeEditSourceEditor#33
• Line Numbers
• CodeEditApp/CodeEditSourceEditor#34
• Change Indicator
• Diff comparison

Resources

• Tree-sitter
• SwiftTreeSitter
• STTextView
• Neon

Packages to consider

• CodeEditorView
• CodeViewer
• CodeEditor
• Sourceful
• SavannaKit
• CotEditor

This will make things more efficient for project contributors and will ensure that issues and PR's have sufficient information.

If user attempts to close a file that has been edited but not saved, we need to warn them and give them the chance to save or disregard their changes.

When clicking the disclosure button next to a folder, it doesn't animate open but it animates closed. It needs to animate open as well.

Hi, when I open the project, the process of swift-frontend will take a lot of memory. Do you have any ideas?

Xcode version: Version 13.1 (13A1030d)
Device info: MacBook Pro(16-inch, 2021) M1 Max 64g

Overview

Help documentation will be needed for the CodeEdit application and Extension API. @austincondiff and I discussed using the DocC documentation compiler, which converts Markdown-based text into documentation for Swift projects. This is the same documentation framework used by Xcode.

DocC is being used for internal documentation. GitBook is being used for the extension API documentation and is WIP. Please see the Extension API Repository.

It takes a few seconds to open a folder in the sidebar, to open files once clicked in the sidebar, or even when clicking another tab. We need to improve load times for near instant results as expected by the user.

We may fix #21 first.

In order to make the sidebar more adaptable and customizable we probably need to implement a completely custom one.

The target is to move away from using NavigationLink to display the CodeFileView

Steps that need to be taken:

• New Custom Sidebar should be added as a Module to CodeEditModules

  Requires to move Documents into a separate Module

• move CodeFileView to WorkspaceView and display if workspace.selectedId is set.
• in WorkspaceView add a new SidebarView in a HStack with the CodeFileView.
• vibrancy background on new Sidebar.
• custom tree structure for folders and files (keep in mind that in large projects performance is acceptable).
• each item should be selectable.
• selection state should be updated in order to represent workspace.selectedId. ( #137 )
• when a file is selected from different UI (tabBar, quick open, …) the folders containing the file should expand and the file should move to focus.

  Xcode doesn't do this. Should we?

• selection background should take up the full width of the sidebar - padding (like in Xcode).
• folders need to be collapsable (mind the animation).
• files/folders can be dragged into other folders.
• consider #100

It would be nice to be able to toggle between monochromatic and color icons. We should include this as a setting to be applied to icons in the sidebar and breadcrumb bar. This would also mean each file type be associated with a color.

See PR #91

• Decide on a keyboard shortcut to use to evoke a quick open search bar.
  • Xcode: Cmd+Shift+O
  • VS Code, Atom, Sublime Text: Cmd+Opt+P
• Build search bar similar to Apple Spotlight or Xcode quick open
• Build file list of search results
• Keyboard navigation to navigate list and select option, or escape

With the current main I cannot open a folder anymore. I select one but nothing happens.

Last working version after #95

2022-03-20 00:22:53.833278+0100 CodeEdit[59436:7532095] [General] readFromFileWrapper:ofType:error: must be overridden by class CodeFileDocument for your application to handle file packages.
2022-03-20 00:22:53.834714+0100 CodeEdit[59436:7532095] [General] (
	0   CoreFoundation                      0x00000001b1146b08 __exceptionPreprocess + 240
	1   libobjc.A.dylib                     0x00000001b0e91e14 objc_exception_throw + 60
	2   CoreFoundation                      0x00000001b1146954 +[NSException exceptionWithName:reason:userInfo:] + 0
	3   AppKit                              0x00000001b414f43c -[NSDocument readFromFileWrapper:ofType:error:] + 368
	4   AppKit                              0x00000001b414f260 -[NSDocument readFromURL:ofType:error:] + 576
	5   AppKit                              0x00000001b3f0d930 -[NSDocument _initWithContentsOfURL:ofType:error:] + 184
	6   AppKit                              0x00000001b3f0d804 -[NSDocument initWithContentsOfURL:ofType:error:] + 228
	7   AppKit                              0x00000001b3f72c28 -[NSDocumentController makeDocumentWithContentsOfURL:ofType:error:] + 460
	8   AppKit                              0x00000001b417f884 __97-[NSDocumentController makeDocumentWithContentsOfURL:alternateContents:ofType:completionHandler:]_block_invoke + 92
	9   AppKit                              0x00000001b417f814 -[NSDocumentController makeDocumentWithContentsOfURL:alternateContents:ofType:completionHandler:] + 188
	10  AppKit                              0x00000001b3f71f0c __80-[NSDocumentController openDocumentWithContentsOfURL:display:completionHandler:]_block_invoke + 804
	11  AppKit                              0x00000001b417e7b4 __144-[NSDocumentController _coordinateReadingAndGetAlternateContentsForOpeningDocumentAtURL:resolvingSymlinks:thenContinueOnMainThreadWithAccessor:]_block_invoke_4 + 36
	12  AppKit                              0x00000001b417ea74 __144-[NSDocumentController _coordinateReadingAndGetAlternateContentsForOpeningDocumentAtURL:resolvingSymlinks:thenContinueOnMainThreadWithAccessor:]_block_invoke.778 + 176
	13  AppKit                              0x00000001b417e964 __144-[NSDocumentController _coordinateReadingAndGetAlternateContentsForOpeningDocumentAtURL:resolvingSymlinks:thenContinueOnMainThreadWithAccessor:]_block_invoke.774 + 308
	14  AppKit                              0x00000001b4189640 ___NSMainRunLoopPerformBlockInModes_block_invoke + 44
	15  CoreFoundation                      0x00000001b10c6460 __CFRUNLOOP_IS_CALLING_OUT_TO_A_BLOCK__ + 28
	16  CoreFoundation                      0x00000001b10c62d8 __CFRunLoopDoBlocks + 412
	17  CoreFoundation                      0x00000001b10c4f58 __CFRunLoopRun + 808
	18  CoreFoundation                      0x00000001b10c4490 CFRunLoopRunSpecific + 600
	19  HIToolbox                           0x00000001b9ce4dd8 RunCurrentEventLoopInMode + 292
	20  HIToolbox                           0x00000001b9ce4a64 ReceiveNextEventCommon + 324
	21  HIToolbox                           0x00000001b9ce4908 _BlockUntilNextEventMatchingListInModeWithFilter + 72
	22  AppKit                              0x00000001b3c23bcc _DPSNextEvent + 860
	23  AppKit                              0x00000001b3c224c4 -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 1328
	24  AppKit                              0x00000001b3c14690 -[NSApplication run] + 596
	25  AppKit                              0x00000001b3be5da8 NSApplicationMain + 1132
	26  CodeEdit                            0x00000001008cde60 main + 12
	27  dyld                                0x0000000100d99088 start + 516
)

When opening a large file the editor takes a massive hit in performance and ends up using a lot of resources on thread one. Also when you try to scroll it needs to load the file every time due to its size.

Tabs

When trying to close multiple tabs fast the editor breaks due it not being able to remove the tabs fast enough.

You can reproduce this by opening multiple tabs and closing them fast.

Please add VsCode and Xcode editor themes

The Welcome Screen can be opened multiple times using Window > Welcome to CodeEdit or pressing ⇧+⌘+0. This should not be possible.

Why don't we add a get started screen when the user opens the editor directly instead of from the welcome screen or when the user has disabled the welcome screen. Because currently if you open Xcode without the welcome screen you don't really notice the editor is open unless you look at menu section at the top and open a project from there.

The idea I have is to go along the the routes of VS Code but with Apple Design principles.

If this gets the go ahead let me know and i'll make a mock up and make a Draft PR

How do we want to manage preferences? Let's get a discussion going so we can arrive to the best solution for our users.

Do we want to sync via iCloud between devices?

Can project specific settings override global settings?

How do we want to display these settings?

Option A

Option B

Option C

The toolbar is nearly white in Xcode and Finder in light mode while in CodeEdit it is light gray.

The toolbar is lighter gray in Xcode and Finder in dark mode while in CodeEdit it is a darker gray.

Notice the difference in tabs on both light and dark mode compared to Finder. We are opting for a more native tab style so that needs to look exactly like native tabs found in Finder. At some point it may be nice to have a setting to toggle between native style or Xcode style tabs.

Also notice the vibrancy effects, hover states and transition effects.

A homebrew formula for this project would be really useful. This should make updating to the newest version way more convenient.

Is it planned to create one in this early phase of the project?

⌘W Should close active tab instead of window.

The sidebar should always show the selection state to the currently open file.

But when opening a file through Shift+Cmd+O or selecting it through the TabBar it will not change.

Consider fix in #123

When you close or save file temporary file is created before saving to original file's URL. It's shown in the sidebar for a fraction of a second. It's a little bit annoying as I think.

The Problem

Hi! I was trying to join the discord using the link(s) in the README, but it appears that they are expired. Can you please update them? Thanks!

It may be good to be able to open a file or directory from the command line with a command like codeedit . or codeedit index.js etc.

I am unable to open files without an extension like .zshrc. We need to be able to open these files.

We need to be able to save a file once edited.