Skip to content

Commit 525fb00

Browse files
committed
Change order or sections.
1 parent 340eca5 commit 525fb00

File tree

1 file changed

+97
-97
lines changed

1 file changed

+97
-97
lines changed

README.md

Lines changed: 97 additions & 97 deletions
Original file line numberDiff line numberDiff line change
@@ -135,6 +135,103 @@ The project name is always *ecode* (so if you are building with make, you'll nee
135135

136136
Nightly builds are being distributed [here](https://github.com/SpartanJ/eepp/releases/tag/nightly) for the more impatient users. ecode is being developed actively, nightly builds may not be stable for daily usage unless there's a pending unreleased fix required for the user.
137137

138+
## Plugins
139+
140+
Plugins extend the base code editor functionality. Currently all plugins are enabled by default, but
141+
they are optional and they can be disabled at any time. *ecode* implements an internal protocol that
142+
allow plugins to communicate with each other. The LSP protocol is going to be used as a base to implement
143+
the plugin communication. And, for example, the Linter plugin will consume the LSP to improve its diagnostics.
144+
Also the Auto Complete module will request assistance from the LSP, if available, to improve the
145+
completions and to provide signature help.
146+
147+
#### Linter
148+
149+
Linter support is provided by executing already stablished linters from each language.
150+
*ecode* provides support for several languages by default and can be extended easily by expanding the
151+
`linters.json` configuration.
152+
153+
For more information [read the linter documentation](docs/linter.md).
154+
155+
#### LSP Client
156+
157+
LSP support is provided by executing already stablished LSP from each language.
158+
*ecode* provides support for several languages by default and can be extended easily by expanding the
159+
`lspclient.json` configuration.
160+
161+
For more information [read the lsp client documentation](docs/lsp.md).
162+
163+
#### Debugger
164+
165+
Debugger support is provided by the implementation the [Debug Adapter Protocol](https://microsoft.github.io/debug-adapter-protocol).
166+
ecode is able to debug any language implementing this protocol, although the protocol is generic sometimes
167+
requires to support some of the languages some specific adaptation is needed, so initially the support
168+
is limited to the languages mentoined in the support list.
169+
170+
For more information on how to use the debugger [read the debugger documentation](docs/debugger.md).
171+
172+
#### Git integration
173+
174+
*ecode* provides some basic Git integration (more features will come in the future). Its main purpose
175+
is to help the user to do the most basics operations with Git. Some of the current features supported:
176+
git status and stats visualization (files states), commit, push, checkout, pull, fetch, fast-forward
177+
merge, creating+renaming+deleting branches, managing stashes. All stats will be automatically
178+
updated/refreshed in real time. There's also some basic configuration available.
179+
180+
For more information [read the git integration documentation](docs/git.md).
181+
182+
#### Auto Formatter
183+
184+
The formatter plugin works exactly like the linter plugin, but it will execute tools that auto-format code.
185+
*ecode* provides support for several languages by default with can be extended easily by expanding the
186+
`formatters.json` configuration.
187+
188+
For more information [read the formatter documentation](docs/formatter.md).
189+
190+
#### Auto Complete
191+
192+
The auto-complete plugin is in charge of providing suggestions for code-completion and signature help.
193+
194+
For more information [read the auto-complete documentation](docs/autocomplete.md).
195+
196+
#### AI Assistant
197+
198+
The AI Assistant is a simple but effective LLM Chat UI. You'll be able to chat with different models
199+
from within the editor.
200+
201+
For more information [read the AI assistant documentation](docs/aiassistant.md).
202+
203+
#### XML Tools
204+
205+
The XML Tools plugin (disabled by default) provides some nice to have improvements when editing XML
206+
content.
207+
208+
For more information [read the xml tools documentation](docs/xmltools.md).
209+
210+
### Plugins configuration files location
211+
212+
*ecode* respects the standard configuration paths on each OS:
213+
214+
* *Linux*: uses `XDG_CONFIG_HOME`, usually translates to `~/.config/ecode/plugins`
215+
* *macOS*: uses `Application Support` folder in `HOME`, usually translates to `~/Library/Application Support/ecode/plugins`
216+
* *Windows*: uses `APPDATA`, usually translates to `C:\Users\{username}\AppData\Roaming\ecode\plugins`
217+
218+
### Plugins important behaviors
219+
220+
All plugin configurations are designed to be overwriteable by the user. This means that the default
221+
configuration can be replaced with custom configurations from the user. For example, if the user
222+
wants to use a different linter, it just needs to declare a new linter definition in its own linter
223+
configuration file. The same applies to formatters and LSPs servers.
224+
Plugins will always implement a "config" for plugins customization, and will always implement a
225+
"keybindings" key to configure custom keybindings.
226+
227+
## UI Customizations
228+
229+
*ecode* is highly customizable and extendable thanks to its several configuration files.
230+
If you're interested in creating new color schemes for the editor or terminal, or in creating new
231+
UI themes please check our documentation:
232+
233+
For more information [read the UI Customization documentation](docs/uicustomizations.md).
234+
138235
## Language support
139236

140237
ecode is constantly adding more languages support and also supports extending it's language support
@@ -297,103 +394,6 @@ Use the health check flag to troubleshoot missing language servers, linters and
297394
Check the health of all languages with `ecode --health` or ask for details about a specific language
298395
with `ecode --health-lang=<lang>`.
299396

300-
## Plugins
301-
302-
Plugins extend the base code editor functionality. Currently all plugins are enabled by default, but
303-
they are optional and they can be disabled at any time. *ecode* implements an internal protocol that
304-
allow plugins to communicate with each other. The LSP protocol is going to be used as a base to implement
305-
the plugin communication. And, for example, the Linter plugin will consume the LSP to improve its diagnostics.
306-
Also the Auto Complete module will request assistance from the LSP, if available, to improve the
307-
completions and to provide signature help.
308-
309-
#### Linter
310-
311-
Linter support is provided by executing already stablished linters from each language.
312-
*ecode* provides support for several languages by default and can be extended easily by expanding the
313-
`linters.json` configuration.
314-
315-
For more information [read the linter documentation](docs/linter.md).
316-
317-
#### LSP Client
318-
319-
LSP support is provided by executing already stablished LSP from each language.
320-
*ecode* provides support for several languages by default and can be extended easily by expanding the
321-
`lspclient.json` configuration.
322-
323-
For more information [read the lsp client documentation](docs/lsp.md).
324-
325-
#### Debugger
326-
327-
Debugger support is provided by the implementation the [Debug Adapter Protocol](https://microsoft.github.io/debug-adapter-protocol).
328-
ecode is able to debug any language implementing this protocol, although the protocol is generic sometimes
329-
requires to support some of the languages some specific adaptation is needed, so initially the support
330-
is limited to the languages mentoined in the support list.
331-
332-
For more information on how to use the debugger [read the debugger documentation](docs/debugger.md).
333-
334-
#### Git integration
335-
336-
*ecode* provides some basic Git integration (more features will come in the future). Its main purpose
337-
is to help the user to do the most basics operations with Git. Some of the current features supported:
338-
git status and stats visualization (files states), commit, push, checkout, pull, fetch, fast-forward
339-
merge, creating+renaming+deleting branches, managing stashes. All stats will be automatically
340-
updated/refreshed in real time. There's also some basic configuration available.
341-
342-
For more information [read the git integration documentation](docs/git.md).
343-
344-
#### Auto Formatter
345-
346-
The formatter plugin works exactly like the linter plugin, but it will execute tools that auto-format code.
347-
*ecode* provides support for several languages by default with can be extended easily by expanding the
348-
`formatters.json` configuration.
349-
350-
For more information [read the formatter documentation](docs/formatter.md).
351-
352-
#### Auto Complete
353-
354-
The auto-complete plugin is in charge of providing suggestions for code-completion and signature help.
355-
356-
For more information [read the auto-complete documentation](docs/autocomplete.md).
357-
358-
#### AI Assistant
359-
360-
The AI Assistant is a simple but effective LLM Chat UI. You'll be able to chat with different models
361-
from within the editor.
362-
363-
For more information [read the AI assistant documentation](docs/aiassistant.md).
364-
365-
#### XML Tools
366-
367-
The XML Tools plugin (disabled by default) provides some nice to have improvements when editing XML
368-
content.
369-
370-
For more information [read the xml tools documentation](docs/xmltools.md).
371-
372-
### Plugins configuration files location
373-
374-
*ecode* respects the standard configuration paths on each OS:
375-
376-
* *Linux*: uses `XDG_CONFIG_HOME`, usually translates to `~/.config/ecode/plugins`
377-
* *macOS*: uses `Application Support` folder in `HOME`, usually translates to `~/Library/Application Support/ecode/plugins`
378-
* *Windows*: uses `APPDATA`, usually translates to `C:\Users\{username}\AppData\Roaming\ecode\plugins`
379-
380-
### Plugins important behaviors
381-
382-
All plugin configurations are designed to be overwriteable by the user. This means that the default
383-
configuration can be replaced with custom configurations from the user. For example, if the user
384-
wants to use a different linter, it just needs to declare a new linter definition in its own linter
385-
configuration file. The same applies to formatters and LSPs servers.
386-
Plugins will always implement a "config" for plugins customization, and will always implement a
387-
"keybindings" key to configure custom keybindings.
388-
389-
## UI Customizations
390-
391-
*ecode* is highly customizable and extendable thanks to its several configuration files.
392-
If you're interested in creating new color schemes for the editor or terminal, or in creating new
393-
UI themes please check our documentation:
394-
395-
For more information [read the UI Customization documentation](docs/uicustomizations.md).
396-
397397
## Custom languages support
398398

399399
Users can add support for new languages with a very simple JSON file format.

0 commit comments

Comments
 (0)