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

[Rasmus]

First things first.

address@hidden (João Távora) writes:

>> (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.

OK, I will check this later.  ATM I need to work towards a deadline.

> Rasmus <address@hidden> writes:
>> address@hidden (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.

I guess it's nice, but it might be a bit to optimistic!

>>> Rasmus <address@hidden> 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.

Nobody talks about bulletproof.  Here's a reason for your project: "the
current implementations do not center the contents and works poorly with
auto-fill-mode".  The idea is the first step, IMO.  Implementation can
then follow.  This is also why the commentary section is important.

>>>> 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.

Sure.  The key is: "... have not signed papers *and do not intend to*".

>>> 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.

OK.  I don't know the details (I don't have any ELPA-stuff), but the gist
is probably along:
     - You get access to the ELPA repo.
     - git clone <membername>@git.sv.gnu.org:/srv/git/emacs/elpa.git
     - make sure to read
       http://git.savannah.gnu.org/cgit/emacs/elpa.git/tree/README
     - do your work and push it.  I think pixies rebuild packages
       automatically, but check the README.

>> 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?

IMO: Yes.  Cdlatex-org-mode is also a minor mode.  So is paredit.  I'm not
sure we want to use the same functions for these three projects.
E.g. visual-line-mode may be of interest to your mode, but not to paredit.
See `run-hook-with-args' and `run-hooks' and the like.

>> 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" could be your future self.  You just wrote 3 sentences about this
issue.  It's an opinion thing.  Gnus and Org has bunch of undocumented
functions, but it's nicer is there's one sentence on each function.

>>> 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.

I will see if I can find a way to think about the centering display issue.
I do wonder if the window-width independence of font-size is a bug.  Note:
you might be able to estimate the actual width using `string-width` and
`{beginning, end}-of-visual-line'.

BTW: I remember having seen issues with auto-fill and large fonts.  Do you
have a reproducible example at hand?

> 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.).

You are very keen on changing subject lines.  I will try to check your
code tonight.

—Rasmus

-- 
. . . It begins of course with The Internet.  A Net of Peers