From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: joaotavora@gmail.com (=?iso-8859-1?Q?Jo=E3o_T=E1vora?=) Newsgroups: gmane.emacs.devel Subject: Re: [mentoring-done] a darkroom/writeroom mode for Emacs Date: Mon, 15 Dec 2014 12:01:23 +0000 Message-ID: References: <20141203142859.24393.98673@vcs.savannah.gnu.org> <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> <87bnnczcjg.fsf@gmx.us> <87bnna11ez.fsf@pank.eu> <87wq5xxe6g.fsf@gmx.us> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1418644919 29130 80.91.229.3 (15 Dec 2014 12:01:59 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 15 Dec 2014 12:01:59 +0000 (UTC) To: emacs-devel@gnu.org, Rasmus Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Dec 15 13:01:53 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 1Y0ULZ-00081M-AP for ged-emacs-devel@m.gmane.org; Mon, 15 Dec 2014 13:01:53 +0100 Original-Received: from localhost ([::1]:39109 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y0ULY-0000xV-VP for ged-emacs-devel@m.gmane.org; Mon, 15 Dec 2014 07:01:52 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51155) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y0ULH-0000xL-DJ for emacs-devel@gnu.org; Mon, 15 Dec 2014 07:01:40 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Y0ULC-0006Ul-I1 for emacs-devel@gnu.org; Mon, 15 Dec 2014 07:01:35 -0500 Original-Received: from mail-wi0-x231.google.com ([2a00:1450:400c:c05::231]:65156) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y0ULC-0006UM-6e for emacs-devel@gnu.org; Mon, 15 Dec 2014 07:01:30 -0500 Original-Received: by mail-wi0-f177.google.com with SMTP id l15so8751853wiw.10 for ; Mon, 15 Dec 2014 04:01:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:in-reply-to:references:user-agent:date:message-id :mime-version:content-type:content-transfer-encoding; bh=ERzN8uQZPY49gxis3OxyZ9FIeH7HBtYMUk0r+P0NCWY=; b=qOi/0F0wpL/9Y+C3hdNyh2JJrbAe+thuC21rSZrvDeGl8TyRq4zXegkAXj95bpSWzV pYM7nRbwrjz/75TbBnQ34wyGl3bWyOt1oHh5urwjfS7Z4iIMJvJ81UjnUFN6Lt2jcHwu M8l7a6Bc4kJn9ADaJZiUeadQCUDAOnvfq2ErsAhB8rUsX1dlsIsVXhb8VrR9vp+9pbD8 p0aPokqlsK2PSa5Rznr6GO21ZjmuODnsQ6gDI3EjAsyBl0zU6GmSqvapm7tbFWkHPmRB HxQgMrJhXN/Bm2Z6+p4t3zlEDpdcVWt4HrRCFJm+7TxvT+EjwK7FIAogqgZMd7bdJwW6 S1gg== X-Received: by 10.194.88.228 with SMTP id bj4mr13303318wjb.18.1418644888364; Mon, 15 Dec 2014 04:01:28 -0800 (PST) Original-Received: from GONDOMAR.yourcompany.com (53.236.108.93.rev.vodafone.pt. [93.108.236.53]) by mx.google.com with ESMTPSA id wz5sm12770181wjc.29.2014.12.15.04.01.26 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 15 Dec 2014 04:01:26 -0800 (PST) In-Reply-To: <87wq5xxe6g.fsf@gmx.us> (rasmus@gmx.us's message of "Fri, 12 Dec 2014 13:09:27 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4 (windows-nt) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c05::231 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:180138 Archived-At: Hi List, After some iterations with Rasmus, I have cleaned up darkroom.el library of its most obvious problems and now consider it ready to push to ELPA.git (as was suggested) if no-one objects. The library lives in https://github.com/capitaomorte/darkroom if someone is interesting in double checking or commenting. The library still has an outstanding problem with "window-width", which I have solved with an isolated hack. See the docstring for `darkroom--real-window-width' for an explanation. Jo=E3o Rasmus writes: >> I going to say this is a bug in `variable-pitch-mode', since I read >> somewhere (Stefan?) that a minor mode should always turn itself *on* when >> called with a nil argument, precisely to support use cases such as >> yours. > Perhaps, the correct name would be `toggle-variable-pitch-mode'. Which is > what is needed here. I don't know if that would help you much, with just the minor-mode hook. Saving the buffer's state and restoring is not trivial. Darkroom implements it for the variables in the (internal) `darkroom--saved-variables', but anything more complicated one has to implement `darkroom-mode-hook' with some sophistication. This hook is run when entering or leaving the minor mode. > IMO this is wrong (but I guess what all other similar modes does as well). > It should choose margin so that the realized line with is approximately > the same as the real line width or so that the difference is as small as > possible. This matters for small windows. So, to center you need the > window geometry. To choose the width, IMO, you need to look at the > difference between line width (be it visual or not) and realized width (in > the same of visual-line-mode). > As above, margin should /not/ be fixed a priori. Rather, (and IMO) they > should be set to not be intrusive given the text. Then centered. what I > want is maybe too complicated, but I think it would be nice. I still don't understand, but I suspect it's related to your intent to use variable pitch with darkroom-mode. In that scenario, indeed, the concepts of "real line length" and "visual line length" start to make a little sense to me, more or less. Also your idea of recursiveness. I'll welcome an implementation for a "guess margins" function when you have the time. >> Anyway this review (also tellingly) got very sidetracked into the >> implementation details.=20 > > I don't understand the 'tellingly' here. In the context of the "mentoring" experiment, it's "telling" that this discussion, initially supposed to be a relatively isolated, well-defined and expedite step for cleaning up the proposed change in compliance with Emacs procedures, quickly entered into the implementation details. It "tells" me that maybe that separation may be too ambitious, at least given the current awareness of the original "mentoring" intention. But it's certainly not "your fault" or anything like that, it's just the way it went. >> Can I assume you are more or less happy with the procedural and cosmetic >> aspects of darkroom.el that the "mentoring" part is over? Then I might >> officially propose darkroom.el to elpa.git.n I'v already cloned the repo >> and have a reasonable idea how to commit it. > > As you prefer. Updates in ELPA are cheap. Just change the version number > and push. As far as I understand it, this is the strategy to develop the upstream on Github and publish to ELPA.git periodically. I will "git merge --no-commit" my github repo into ELPA.git. Then issue whatever necessary "git mv" I have to to place "darkroom.el" and any other files in the correct place. Then commit with a suitable commit message. The following updates also use "git merge --no commit". > It also comes down to interest in the reviewed code. Yes. I also suspected it, and I'll include this factor in my quick debriefing of the "mentoring" experiment.