Project Context - Githubissues

subethaedit / SubEthaEdit

General purpose plain text editor for macOS. Widely known for its live collaboration feature.

https://subethaedit.net

MIT License

1.37k stars 112 forks source link

Project Context #1

Open monkeydom opened 5 years ago

monkeydom commented 5 years ago

One big missing Feature of SubEthaEdit is the lack of a project context. This is an Umbrella bug for making this happen.

What I have in mind is a lightweight directory display that should be rooted in the SCM (usually git nowadays) directory up from the current file. Ideally we don't litter the file system with yet another .file but either intelligently infer this, or react to opening folders this way.

The Project context should be in line with SubEthaEdit in general, that means that it should be its own window that can be docked. It could serve as the basis for great functionality:

powerful project wide search and replace
constrain autocomplete for files in the same context
simple access and recognition of build and linting scripts for the project opened
project wide navigation (e.g. opening up of imported files, etc)
SCM integration

keehun commented 5 years ago

👍 and +1. With the open source release of SubEthaEdit 5, I went to check it out. (The last time I checked it out was a long time ago.) This ticket was my immediate thought upon trying to use SEE5 in my daily workflow.

fourplusone commented 5 years ago

I wonder how to implement this obeying the App Sandbox constraints. Here are some options (and objections) that came to my mind

Ask the user to select a project root (not a great UX)
Create a privileged helper (not AppStore compliant (?) )
Drop App Sandbox (not AppStore compliant (!) )
Only use a project context if the user selects a folder (too implicit?)

I wonder whats your preferred way @monkeydom

monkeydom commented 5 years ago

I wonder how to implement this obeying the App Sandbox constraints. Here are some options (and objections) that came to my mind

Ask the user to select a project root (not a great UX)

Create a privileged helper (not AppStore compliant (?) )

Drop App Sandbox (not AppStore compliant (!) )

Only use a project context if the user selects a folder (too implicit?)

I wonder whats your preferred way @monkeydom

I want us to stay AppStore and Sandbox compliant. Currently I see 2 ways for us: a) make the user open the root of the workspace/project context b) make the user give us full disk access privileges (like e.g. Alfred does) c) make the user give us disk access by an open dialog (like e.g. BBEdit does it)

This is probably an ongoing discussion as use of local tools/language servers, plugin infrastructure, etc. is important as well for follow up features.

dwt commented 5 years ago

Textmate in the interaction with it's mate shell integration utility implements it by opening a a folder as a project, and opening single files as single files. I quite like the simplicity and predictability of this and would advise to go a similar route.