Re: [mentoring] a darkroom/writeroom mode for Emacs

[joaotavora@gmail.com (João Távora)]

Rasmus <rasmus@gmx.us> writes:
> joaotavora@gmail.com (João Távora) writes:
>
>>    [ Hi Rasmus, I took it from your thorough review of the code that you
>>    accept to mentor this, in the framework discussed earlier. In the
>>    future, perhaps change the subject line to "mentoring".
> I hit F, write the message and then click C-c C-c.  Did you not include
> the [mentoring] line to begin with?

No, I didn't. I used "[mentor-request]" hoping that a mentor would reply
with "[mentoring]" to make the commitment. After a few "Re: [mentoring]"
iterations, when it's done, change the subject again to "[mentored]". I
state that you mentored it and ask for final comments or stuff you
couldn't help with. If no blockers appear then, I or someone else
commits it. We can document this somewhere later if we find it warrants
it. Maybe it is too complicated, but think it's useful.

By the way I dropped the [] comments this time around.

>> Rasmus <rasmus@gmx.us> writes:
>>     [ How convincing must the would-be-contributor be at this stage?
>>     Won't opening with this question intimidate him/her? ]
> Maybe.  This is the question my supervisor asks me every time I come up
> with a new idea.  Indeed, it's a very unpleasant question, but one that
> you need to consider no matter if you do code or try to write a thesis.

OK. But he/she shouldn't be forced to make a bullet-proof case at this
point, the main goal is to cleanup the contribution of blockers. After
that its pertinence can be reevaluated. Of course, an objection would
be: "why do all the mentoring work then?". I don't have an answer, but I
still think its useful.

>>> Did you take care of the FSF paperwork?
>>     [ I've contributed to Emacs earlier, so yes. Again should this
>>       question be on top?]
> Yeah, 'cause it takes time.  So the earlier the process the better.  If
> you have not signed papers and do not intend to, I won't read your
> patch.

OK. Clearly, discovering if the author does not intend to do it is very
important. But if he doesn't object, reading the patch is probably still
useful in the meantime.

>> Where?
> Check: http://www.emacswiki.org/emacs/ELPA#toc2

Looks good indeed, though it states simply "Now you can push to the
repo". A look at the linked "Making Packages" should tell where to place
the file, for example, it doesn't. Perhaps I just need to mimic what
other packages do there in the repo. Anyway I think those intructions
could be improved, and made into a tutorial on how to add foo-mode.el to
the ELPA repo.

>>> I guess it should go to ELPA, but you need to improve it.
>> OK, I'll improve it. Once it's in ELPA, how do I maintain it? Can I keep
>> using github for the upstream since I'm so familiar with it?
> I guess, but it would require more work as you'd need to manually push it.
> Perhaps Dmitry (of Company) could explain how he handles it.

Yes, good idea. We can ask him after this mentoring phase: that's not a
blocker.

>>> (defvar darkroom-turns-on-visual-line-mode t
>> See above.  I think providing a hook is better.  People can add this
>> themselves 
> Yes, I got rid of it.  You probably also need a hook when exiting.  Or the
> functions in the hook are called with different argument when entering and
> exiting the minor-mode.

I didn't provide the hook. There is the minor mode hook that is normally
provided. Do you think any more are needed?

> (I did not reread your code).

I more or less expected you to, at least the diffs, or at least the new
"Commentary" header at the top, which explains the main functionality
that wasn't clear to you.

> Well, I'm going through your code.  Since my time is scare, I would rather
> get a quick hint about what the function is doing.  I won't have to guess
> everything then.

OK. Though, I would say understanding every little detail of the code is
unimportant at this step if you capture the overall functionality. You
didn't capture it, because I didn't describe it. Hence your other
questions, which I find more pertinent than this one at this stage.

>> I've removed it, since it didn't work very well, but the idea is that a
>> buffer in visual-line-mode (with soft wrapping of long lines), will
>> always enter darkroom-mode with nice margins that perfectly center the
>> text on the screen. A buffer with hard linebreaks (like this message) is
>> not perfect for darkroom-mode, since the margins won't center it.
> I agree.  Indeed if you can solve this issue it would be pretty cool.
>  [...]
> To me, larger font would be essential.  And indeed, a problem is the
> combination of auto-fill and larger font.  ATM I don't have a good idea on
> how to solve this.

We can ask here for solutions after this mentoring step is done: I'm
sure someone can come up with a solution.

>> Well, minus typo I did very briefly. But it should be clearer now from
>> the commits I did.
> OK, as long as your document it, it's fine.

I did. Hopefully well enough. But if you had a final quick look it would
be good. Then I can send another message to the list with the subject
line prefixed "[mentored]", with the final questions about the
outstanding problems and push it. (I should have write access to the
repo.).

>> It did. [ It did. ]
> both of you are happy, that's good!
We are all one now muahaha

João