> (defun darkroom-visual-mode-maybe-enable () I made these internal variables (used the "-"), do I still need a > (defvar darkroom-saved-visual-line-mode nil) > (defvar darkroom-saved-header-line-format nil) > (defvar darkroom-saved-mode-line-format nil) Yes, it's opinionated and not very useful. > sense in the docstring and preferably in the commentary as well.
> behavior? You need to document these features an explain why they make Why the need to deviate from ordinary Emacs > (defun darkroom-fill-paragraph-maybe (really) `darkroom-increase/decrease-margins' to tweak its decision. Is used only when entering `darkroom-mode', then the user can use > Also, you provide three ways of setting margins. > 0.05 should at the very least be a defconst but better a defcustom or from > (setq darkroom-margins (+ 0.05 darkroom-margins)) I've renamed this function `darkroom-compute-margins' and added a > (defvar darkroom-fringes-outside-margins t > (defvar darkroom-turns-on-visual-line-mode t See (info "(elisp) Variable Definitions") [ I used the badly named M-x auto-insert, but yours was a good See the top of any file in your ~/.emacs.d/elpa/ folder.ĭone. Further, for ELPA dependencies, version etc. > You need to start with a proper head of the file, including the commentary [ There is no format, we're trying to figure it out. I'm not sure if this is the intended format of
Note, I'm not an expert, especially on the Using github for the upstream since I'm so familiar with it? Once it's in ELPA, how do I maintain it? Can I keep > I guess it should go to ELPA, but you need to improve it. [ Either provide a pointer better than "somewhere", or defer to the > recent Git transition, whether to use Emacs or ELPA for it, plus any
WRITEROOM FEATURES HOW TO
> I'm looking for pointers on how to clone the Emacs repository after the [ I've contributed to Emacs earlier, so yes. > Did you take care of the FSF paperwork? Something like `darkroom-tentative-mode'. Trying some that don't deal well with the margins, and none provide I haven't done a thorough survey of other extensions, but I remember Won't opening with this question intimidate him/her? ] [ How convincing must the would-be-contributor be at this stage? To comment on the mentoring meta-process :-)] I'll be using these double-personality comments throughout my reply
WRITEROOM FEATURES CODE
The code was indeed sketchy, a bit on purpose, and I've integratedĪlmost all your suggestions, but read on. In theįuture, perhaps change the subject line to "mentoring". [ Hi Rasmus, I took it from your thorough review of the code that youĪccept to mentor this, in the framework discussed earlier.
0 kommentar(er)
