From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: joaotavora@gmail.com (=?utf-8?B?Sm/Do28gVMOhdm9yYQ==?=) Newsgroups: gmane.emacs.devel Subject: Re: [mentoring] a darkroom/writeroom mode for Emacs Date: Tue, 09 Dec 2014 13:11:16 +0000 Message-ID: References: <20141203142859.24393.98673@vcs.savannah.gnu.org> <20141203193110.GF12748@thyrsus.com> <20141203215426.GA15791@thyrsus.com> <87ppbzplcw.fsf@newcastle.ac.uk> <83iohr48kr.fsf@gnu.org> <83388u4bps.fsf@gnu.org> <83y4qm2uz9.fsf@gnu.org> <83vblq2los.fsf@gnu.org> <87vblpjq24.fsf@uwakimon.sk.tsukuba.ac.jp> <83mw7119yz.fsf@gnu.org> <87sigqiaaz.fsf@gmx.us> <878uihhv5q.fsf@gmx.us> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1418130707 22895 80.91.229.3 (9 Dec 2014 13:11:47 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 9 Dec 2014 13:11:47 +0000 (UTC) Cc: emacs-devel@gnu.org To: Rasmus Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Dec 09 14:11:41 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XyKZl-0008KW-Dg for ged-emacs-devel@m.gmane.org; Tue, 09 Dec 2014 14:11:37 +0100 Original-Received: from localhost ([::1]:40419 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XyKZk-0007EI-Uu for ged-emacs-devel@m.gmane.org; Tue, 09 Dec 2014 08:11:36 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33520) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XyKZb-0007De-N9 for emacs-devel@gnu.org; Tue, 09 Dec 2014 08:11:32 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XyKZW-0003To-LW for emacs-devel@gnu.org; Tue, 09 Dec 2014 08:11:27 -0500 Original-Received: from mail-wg0-x236.google.com ([2a00:1450:400c:c00::236]:48535) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XyKZV-0003Sb-JO for emacs-devel@gnu.org; Tue, 09 Dec 2014 08:11:22 -0500 Original-Received: by mail-wg0-f54.google.com with SMTP id l2so776622wgh.13 for ; Tue, 09 Dec 2014 05:11:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type:content-transfer-encoding; bh=hmCKaUGvUL1OsZuqqzmZ1WENSl1tWtoCvhioljlBXkc=; b=TVX4siV6xykaZn8f0Wjv2RrI+OADaZJFH71XqHl1l7EFTLgqCNy4zdZH8MKhmw/0Of uLrCmRm9X0dIlQBjkhDxB88jjrjnARbS3cdz6qWDZzBaX2HjQW72gditY74BGrmAI/fv a9OgT+Qif4Tj/ElEXnAuYILftiLSowOfANEJuh0FGCB6kuryz8qgxPJMCzHZWqtZjYSI bE7UqjbkZBy77BznXgjpeuxP+gj5OrmEfj/me2k2FELwJxVW2TCFsW3B4teA0JF4tjwk HqZA5oRPn+Pcy9rHWqvfoAA8fPfEM4/lCVrvUEaHECcjUVFc+T280PJfIN0UqkIEU2PK Yemg== X-Received: by 10.194.78.3 with SMTP id x3mr4631668wjw.127.1418130680782; Tue, 09 Dec 2014 05:11:20 -0800 (PST) Original-Received: from king.lan.yourcompany.com (31.57.37.188.rev.vodafone.pt. [188.37.57.31]) by mx.google.com with ESMTPSA id wa5sm1716218wjc.8.2014.12.09.05.11.19 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 09 Dec 2014 05:11:19 -0800 (PST) In-Reply-To: <878uihhv5q.fsf@gmx.us> (rasmus@gmx.us's message of "Tue, 09 Dec 2014 13:20:17 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.92 (darwin) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c00::236 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:179557 Archived-At: Rasmus writes: > joaotavora@gmail.com (Jo=C3=A3o T=C3=A1vora) 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 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=20 > 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=C3=A3o