From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Rasmus Newsgroups: gmane.emacs.devel Subject: Re: [mentoring] a darkroom/writeroom mode for Emacs Date: Tue, 09 Dec 2014 13:20:17 +0100 Message-ID: <878uihhv5q.fsf@gmx.us> 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> 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 1418127662 4590 80.91.229.3 (9 Dec 2014 12:21:02 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 9 Dec 2014 12:21:02 +0000 (UTC) Cc: emacs-devel@gnu.org To: joaotavora@gmail.com Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Dec 09 13:20:56 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 1XyJmh-0000i6-60 for ged-emacs-devel@m.gmane.org; Tue, 09 Dec 2014 13:20:55 +0100 Original-Received: from localhost ([::1]:39263 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XyJmg-0002hs-O3 for ged-emacs-devel@m.gmane.org; Tue, 09 Dec 2014 07:20:54 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38751) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XyJmI-0002hV-Td for emacs-devel@gnu.org; Tue, 09 Dec 2014 07:20:36 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XyJmD-0007Sf-8Y for emacs-devel@gnu.org; Tue, 09 Dec 2014 07:20:30 -0500 Original-Received: from mout.gmx.net ([212.227.15.15]:60850) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XyJmC-0007SC-UZ for emacs-devel@gnu.org; Tue, 09 Dec 2014 07:20:25 -0500 Original-Received: from x200s ([109.201.154.210]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0LZynd-1XZ7NZ1Q1F-00lig2; Tue, 09 Dec 2014 13:20:20 +0100 Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAElBMVEUvLy91dXVUVFSRkZGs rKzQ0NCgYj8zAAACUUlEQVQ4y2XTXZKbMAwAYONeAEn03RJ7gAiZ9ya235sG3/8qFbBkd1oNM5nx F/1YDOEdUUDC/xHBlNTpH4ymYOACsMX0DchAgcDI2uPx7XzYz00NaessGObxKmRGpkWxtQfjOJer kAI1bQvCdvdOAsu7EE39Y4uaoLUXAbwTtKzPducUIgGDJoZxTyBbresLJTAmAQA2DR5s9PrZOfe+ Fe/mD5+1QFddnx99AzOVPVjTsQxYoY+Mnqvc+mYo8ZgJ9MmKAmbL3D2qzntC+gHTAsF7kg59j4JH BxkIOEURQPzZe+v9BemYaVBEAD+n2+qD+YMHDIKSOLCQ/drB8obHCiOyAQZhstvUu6UIJwzC++TM cMB9nyccECUFBgQqt9o7Sojp7DFIFAYgssVb8J/A59IjSHIgpbzDimH+84YkDlYfza99j9MznHGA qeX9HkV5fX0Bk4HV24ePe4f6BYGpgOXxR+8ZJG/neXQAulPN4+yvCjn376C5rH7BWpLUnk6IDqbF m081q0DMnyBfYAUHQvnsfUKu+UZkKIDXUFEOKHkk0iQSLhAH1bU2gQlE+Hm18JpkVLctggFKkfAF s1ltfyIZyLxckE7o/RbYkCco10JGDNFy75wiKVh7nT1Y0Oebc3+Keor/436CCLK/x/YShsUl3/EC 8Z0MJkILLUHAp79gGMOsDoakIfr51WMeYzaUbAr0O15frESkNGfVyZeigNHeACC5bVZrMc+Jt/AG +ah1K1RrLgV4/ASMMNRWt1qglloVbm/AyY+9jlL2H3yc1/gLV++FkXU0IfkAAAAASUVORK5CYII= In-Reply-To: (=?utf-8?Q?=22Jo=C3=A3o_T=C3=A1v?= =?utf-8?Q?ora=22's?= message of "Tue, 09 Dec 2014 11:28:22 +0000") User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/24.4.51 (gnu/linux) X-Provags-ID: V03:K0:h8A0naHfz1rkl0pxYya1d0zqlf+Q6Iztjaxl6EXA8nMSbQNsyZ7 f5GLmSdirAD9araThs6qzFmQm9Szh6oYXLU8tUC++BYQdqd+0lOJVqzJR5pxc4LMfqnWifc P+vx2BqieWA1qmlVqA12Pfzim+R0/bp8jTFDvvjKiux39UlaT9nFSp61BAncTj4fwJYvWmq bvKdFCIRfTv2DlFSqONrg== X-UI-Out-Filterresults: notjunk:1; X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [generic] X-Received-From: 212.227.15.15 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:179548 Archived-At: 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? > Rasmus writes: >> Why is your mode preferable? > > [ 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. > I haven't done a thorough survey of other extensions, but I remember > trying some that don't deal well with the margins, and none provide > something like `darkroom-tentative-mode'. > >> 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. >>> I'm looking for pointers on how to clone the Emacs repository after the >>> recent Git transition, whether to use Emacs or ELPA for it, plus any >>> other tips that increase my chances. >> This is surely documented somewhere. > > [ Either provide a pointer better than "somewhere", or defer to the > future if you can't.] OK. > Where? Check: http://www.emacswiki.org/emacs/ELPA#toc2 >> 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. >> (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 did not reread your code). >>> (defun darkroom-float-to-columns (f) >> As above [docstring]. > > Will do in the future. [ Is this essential? ] 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. Take org-mode. We have a bunch of weird little functions. I do C-h f on them. If they have no docstring, I have to go a read the source (which I probably don't care about). >> Please add docstring, last argument. > > I made these internal variables (used the "--"), do I still need a > docstring? IMO: Yes. I don't know if there's an establish consensus. >>> (defun darkroom-visual-mode-maybe-enable () >> Docstring. I don't understand the need of this feature. > > 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. > But I've added a utility function `darkroom-guess-margins' that can be > set as the value for `darkroom-margins' and attempts to guess that. In > the writing of this message, for example, where I `fill-pargraph' all > the time, it has guessed the "correct" margins (see screenshot). In > code, it normally defaults to 15% margins. The screenshot looks nice. > It's not perfect, and could be improved. Unfortunately, and more > seriously, it doesn't work when the text scale is increase with > `darkroom-text-scale-increase' set to anything but 0, because > `window-width' doesn't know about text scaling > apparently. `window-width' can return pixels, but then how can I know > the pixel width of the current buffer's font? `frame-char-width' was > promising, but also always returns a constant value. 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. >>> (cond ((and (not darkroom-mode) (=3D (count-windows) 1)) >> why count-windows? Why would it not just use the buffer in focus? > > The idea in `darkroom-tentative-mode' here is that `darkroom-mode' is > entered if and only if all but one window on the frame are deleted. >=20 >>> (define-minor-mode darkroom-tentative-mode >>> "Minor mode that enters `darkroom-mode' when all windws are deleted" >> Again, this seems like a feature and I have no idea about it cause you >> never explain the intended design. > > 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. >> Hope it helps, > > It did. [ It did. ] both of you are happy, that's good!=20 =E2=80=94Rasmus --=20 A page of history is worth a volume of logic