-
-
Notifications
You must be signed in to change notification settings - Fork 176
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
legit: add simple Mercurial support #1198
Conversation
- see current changes, current branch, untracked files - see latest commits - commit
@@ -1,7 +1,8 @@ | |||
(defpackage :lem/legit | |||
(:use :cl | |||
:lem) | |||
(:export :legit-status) | |||
(:export :legit-status | |||
:*prompt-for-commit-abort-p*) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a better way than exporting this variable and making it part of the API?
For example, how about using lem:config?
Also, I personally think that the p suffix in naming should only be used for functions or function parameters (e.g. read's recursive-p).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like the idea to put user-facing variables into lem:config, but this system currently has no support for documentation strings, and it has no namespace system (unlike package:*variable*). Is lem:config really appropriate? It stores values for stuff that we changed with a global command, such as the color theme, the font size, isearch-previous-string.
@@ -388,7 +621,7 @@ M src/ext/porcelain.lisp | |||
(defun %maybe-lem-home () |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it possible that the lem package does not exist?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is actually possible: I develop for Lem both in Lem and in Emacs. And in Emacs, I don't load Lem because… it is not clear to me how to do it, if I ever knew. Quickloading Lem isn't enough, one has to add its dependencies, etc.
So it's necessary for me that the porcelain package doesn't depend on Lem. And I think it's a good separation of concerns.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay, I see why.
However, the dependency on lem is still there, just hidden and not statically obvious.
Ideally, porcelain.lisp should be loosely coupled to lem, but with this, wouldn't it be better to be able to resolve symbols statically with lem:lem-home?
That should be solved with just (ql:quickload :lem)
.
Or I guess you could define defgeneric in the package on this side and define that method in legit.lisp to keep loose coupling.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think your comments are very thoughtful and well-written.
I focused my comments on the API with external parties, so please check it out if you like.
I will merge this PR. |
and I'll handle your reviews. |
This has been laying on a branch for some weeks, I think it's better put in use.
Support is simple, and it will be hard to have great support for different VCSs, but starting support for 3 of them helped me modularize my code and spot some missing cases in Git. So it's beneficial to have it IMO.