Skip to content
Open
Changes from 2 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
159 changes: 159 additions & 0 deletions rfcs/0003-languages.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,159 @@
---
feature: (languages)
Comment thread
shahrukh330 marked this conversation as resolved.
Outdated
start-date: (2021-04-30)
author: (Shahrukh Khan)
related-issues: (None)
Comment thread
shahrukh330 marked this conversation as resolved.
Outdated
---

# Summary
[summary]: #summary

This RFC describes how language support is to be implemented in Soxin. This
Comment thread
shahrukh330 marked this conversation as resolved.
Outdated
breaks down in two areas:

* How languages are defined, i-e how to define the language and its properties
i-e its compiler, tools, editor plugins etc. How the user can define the
defualt plugins for a language in his editor(s).
Comment thread
shahrukh330 marked this conversation as resolved.
Outdated
* How the user can select default set of languages and its required tools in
his editor, and how to override default settings on the editor.
Comment thread
shahrukh330 marked this conversation as resolved.
Outdated

# Motivation
[motivation]: #motivation

As Soxin is aimed at providing its users with easy-to-configure software, while
allowing for great customization, an RFC describing how such an important
feature integrates with the project was needed.

# Detailed design
[design]: #detailed-design

## Language definition

Languages would be defined in a module named `soxin.programming.languages`.
Each language, would be an attribute set in this module:

```

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Examples are more appropriate in the Example section of the RFC.

soxin.programming.languages = {
go = { /* ... */ };
java = { /* ... */ };
python = { /* ... */ };
Comment on lines +37 to +39

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What would these attribute contain?

}
```
## Tools defination

Programming tools will be defined in a module named `soxin.programming.tools`.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If I recall correctly, we discussed the name of this option with @kalbasit two weeks ago, and concluded it would be better named soxin.tools, as some of the tools we would put in there are not only used for programming.
We might also consider renaming soxin.programming.languages to soxin.programmingLanguages, along with the appropriate options in soxin.settings and per-module, of course.

Each tool will be an attribute set in this module.

```
soxin.programming.tools = {
git = { /* ... */ };
tmux = { /* ... */ };
Comment on lines +49 to +50

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What would these attribute contain?

}
```
This allows soxin to define its own support for languages and tools, while

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
This allows soxin to define its own support for languages and tools, while
This allows Soxin to define its own support for languages and tools, while

allowing room for user customization as well.

Similar to RFC 2, each programming language must include a key for each editor
which will support that language. For instance, it could be a plugin for that
editor that installs support for that language, plus some extra configuration
to configure that plugin.

## User interaction

### Globally

Similar to RFC 2, a `soxin.settings.programming.languages` and
`soxin.settings.programming.tools` option would be introduced to allow the user

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
`soxin.settings.programming.tools` option would be introduced to allow the user
`soxin.settings.tools` option would be introduced to allow the user

See above.

to choose his programming stack. The only permitted values here shall be the
Comment thread
shahrukh330 marked this conversation as resolved.
Outdated
defined in `config.soxin.programming.<type>`. This option shall be of type
`Array` of `str`, with apply function which iterate over the array and find

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
`Array` of `str`, with apply function which iterate over the array and find
`Array` of `str`, with an apply function which iterates over the array and finds

appropriate language or tool.
Comment thread
shahrukh330 marked this conversation as resolved.
Outdated

### Per-editor

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That would probably not be editor specific. When you enable go, for example, you might want to have the Go compiler in your environment. It might also configure your shell prompt to change depending on whether you are in a Python virtual environment. It would probably be per-program or per-module.
Note: this is not the only place in the RFC where that nomenclature should be changed.


Each editor that supports a language must provide a
`soxin.programs.<editor-name>.language` and `soxin.programs.<editor-name>.tool`

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So shouldn't it be soxin.programs.<editor-name>.programming.language?

option to allow the user to override the programming stack settings per editor.
These options will default to `config.soxin.settings.programming.<type>`,
and thus will be of type `attrs`. Similar to RFC 2, they will also have will
also allow `str` and have an `apply` function that will lookup the theme
from `config.soxin.programming.<type>` for each option.

# Examples and Interactions
[examples-and-interactions]: #examples-and-interactions

Here's how one could define a language and a tool implementing only the `neovim`
editor:

```
{ pkgs, ... }:

{
config.soxin.programming.languages = {
go = {
neovim = {
plugins = [ pkgs.neovim.go ];
extraRC = ''
'';
};
};

config.soxin.programming.tools = {
git = {
plugins = [ pkgs.neovim.fugitive ];
extraRc = ''
'';
};
};
};
}
```

Here's how this would be implemented on the editor side:

```
{ config, lib, ... }:

let
cfg = config.soxin.programs.neovim;
goSupportRc = cfg.programming.languages.go ? "";

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The returned type of this is an attrset, not a string; Shouldn't it be .go ? {}?

gitSupportRc = cfg.programming.tools.git ? "";
goSupportPlugins = cfg.programming.languages.go.plugins ? [];
gitSupportPlugins = cfg.programming.tools.git.plugins ? [];
{
config.program.neovim = lib.mkIf soxin.programs.neovim.enable {
enable = true;
configure = ''
/* Some configuration */
${goSupportRc}
${gitSupportRc}
'';

plugins = [ /* Some plugins */ ] ++ goSupportPlugins ++ gitSupportPlugins;

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thinking about this, I don't think it should say go or git, instead, it should add the RC and plugins of all enabled language and tools in soxin's settings.

};
}
```

The options of the `programs.neovim` have been modified for simplicity's sake.


# Examples and Interactions
[examples-and-interactions]: #examples-and-interactions

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is duplicated.



# Drawbacks
[drawbacks]: #drawbacks
Comment on lines +177 to +178

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One drawback I might add, is that we might not make the difference between soxin.programs and soxin.tools. What would it be and what are the criteria for putting a module under programs rather than tools?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we add a definition section at the top of the RFC to explain this?

My 2cents: go is a language but gorename is not, it's a tool. Go like any other language may also enable one or more tools.



# Alternatives
[alternatives]: #alternatives


# Unresolved questions
[unresolved]: #unresolved-questions


# Future work
[future]: #future-work