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: Fri, 12 Dec 2014 11:16:24 +0000 Message-ID: References: <20141203142859.24393.98673@vcs.savannah.gnu.org> <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> <87bnnczcjg.fsf@gmx.us> <87bnna11ez.fsf@pank.eu> 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 1418383237 21757 80.91.229.3 (12 Dec 2014 11:20:37 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 12 Dec 2014 11:20:37 +0000 (UTC) Cc: emacs-devel@gnu.org To: Rasmus Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Dec 12 12:20:30 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 1XzOGs-0003Gk-GL for ged-emacs-devel@m.gmane.org; Fri, 12 Dec 2014 12:20:30 +0100 Original-Received: from localhost ([::1]:56623 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XzOGs-00036B-0z for ged-emacs-devel@m.gmane.org; Fri, 12 Dec 2014 06:20:30 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51133) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XzOD9-0006oM-UK for emacs-devel@gnu.org; Fri, 12 Dec 2014 06:16:45 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XzOD3-0005wo-UZ for emacs-devel@gnu.org; Fri, 12 Dec 2014 06:16:39 -0500 Original-Received: from mail-wg0-x22b.google.com ([2a00:1450:400c:c00::22b]:51752) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XzOD3-0005wY-Hv for emacs-devel@gnu.org; Fri, 12 Dec 2014 06:16:33 -0500 Original-Received: by mail-wg0-f43.google.com with SMTP id l18so8759355wgh.30 for ; Fri, 12 Dec 2014 03:16:33 -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=qmWzGSqQHEpkn2a24ccdAWfiwjiaHWFSMJbS1WDPWPw=; b=S3+EkzhnDMMYAIr19xY/NLNcP5RGF3wpAcYwMqPAnm+bf+BSQaKCH5DBeVQEXPwWgS f5a3gOoyr81YrRqNaQJsflI/8DUJN7nCSVYF4SJsB/GymPGQ/Jv4VLKQcPtewW3Q4rZ3 BAsJnRW9h0Qj9+L58p2O67/QRDQP5qxzfwgx1619YuXQ6I3Ub6VYE07l0iZvxkKFdX0I 8IMOvlBTTmVloRTkvEmqbbN4gFEQ3WnKT4qtpJ3NwrFtV39ywj5YldS0/7zTSyxlIIrV 2bqb819TOQhRUzo6aU9Fb9sM8+PuRcZRcp1IgN/UPEfIq4cD+dgDqrg4eo/9kiExnouL +++g== X-Received: by 10.194.234.40 with SMTP id ub8mr26931211wjc.100.1418382992973; Fri, 12 Dec 2014 03:16:32 -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 bs2sm1383577wjc.43.2014.12.12.03.16.30 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 12 Dec 2014 03:16:31 -0800 (PST) In-Reply-To: <87bnna11ez.fsf@pank.eu> (rasmus@gmx.us's message of "Thu, 11 Dec 2014 19:33:56 +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::22b 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:179884 Archived-At: Rasmus writes: > This also shows the problem with the hook that I spoke of earlier. If I > for some reason have variable-pitch-mode enabled I will get disabled. 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. > Changing theme could be another possibility, though I'm not sure one can > load a theme for single buffer... I don't think one can, at least with "custom themes". I think "color themes" used to provide that possibility, so the needed functionality should be in Emacs. Perhaps someone wants to open that can of worms. > Dogfooding you code, I find that the margin adjustment (still?) does not > work well on small screens when font-size is increased. And font-size > increase is pretty central, IMO. Can you provide a specific example? > In the screenshot I have Emacs take up half of my screen (1440x900). As > you can see, for this setting the margin is way to big. This is using the > standard setting. So the heuristic is not very good. You write Is the image provided in the screenshot resized? What did you expect the image to be? > "If the buffer's paragraphs are mostly filled to `fill-column', > margins should center it on the window, otherwise, margins of 0.15 p= ercent > are used." > > When you have at least auto-fill, the objective should be something like > this I guess (I didn't think carefully about it): We may be miscommunicating. I'm not checking for `auto-fill-mode' anywhere. In `darkroom-guess-margins', I'm looking at statistics for the real line lengths and estimating if the paragraphs are (mostly) filled to `fill-column', be it with manual `fill-paragraph' or `auto-fill-mode' maybe. The intent of `darkroom-guess-margins' is then to choose suitable margins to center on the window (not necessarily the "screen" or the "frame"), without truncation, what it thinks are the main parts of your text, possibly truncating (or adding "continuation lines") on any spurious or exceptionally long lines. This it does iff visual-line-mode is inactive. If it is active, it just assumes that you want 0.15 (or `darkroom-margins-if-failed-guess'). It also uses 0.15 if the guessing somehow "fails". > (*) Margin* =3D argmin abs{real-line-with - shown-line-width(margin; fo= nt-size)} > > where ";" reads "given" or "for fixed". Maybe with some weight on margin > itself as well for aesthetic reasons (so + =CE=BB f(margin)). In the > screenshot the margins are definitely too wide as it hinders a good > writing environment contrary to the objective. > > I guess this is why I talk about the width of virtual lines (which are > functions of font-size and actual width). Of course, the easiest way to > solve (*) is recursively. I don't know if that works well with the > display engine, though. > > I will go through `darkroom-guess-margins' again later. I havne't got the > time right now. Well, I'm not following your algorithm (though I admit I didn't try super hard). Best would be to create fixture files that we know should produce a certain correct behaviour. So, if I send you this very paragraph, and run `darkroom-guess-margins' in a window that is 100 columns long (assuming `window-width' now knows afound font size), I should (at least I want to) get left and right margins of 15 columns each. So I could place this text in a file called "darkroom-fixture-a-100-15-15.txt" and use that in an automated test. Can you provide me with "darkroom-fixture----.txt" so I can understand what kind of margin calculations you are talking about? I can then create automated tests from this with ert-deftest. > See discussion above. IMO, this is not working well (but probably *also* > *not worse* than other packages with the same objective!). If we later find that we disagree in the heuristic, we can provide two and let the user decide which one he wants. Anyway I have a big thinko in darkroom.el. Window margins must be calculated by window, not by buffer, because they're a property of windows. I'm fixing that first. >> To make time for southpark. Also it's cold, typing hurts and naming >> variables is hard. I've fixed it. > It's getting colder, yes, and it's flabbergasting how Iberian[or at least > Catalonian(?)] houses do not have heating! Iberian peninsula is big and has many weather types. The coldest it gets in portugal is about +5c for about a month, so unless you're rich and enjoy tshirting in the winter and think global warming is a cool new club, you don't have heating and pine for the summer. I'm just lazy to get a blanket. >> to please my mentor, I added a docstring :-) > I find the title uncomfortable as it suggests I'd have greater insights, > which is probably (as in =E2=86=92=E2=82=90=E2=82=9B) not the case; rathe= r it's peer > reviewing. Sorry, but play along. Though I'll include this factor in the mentoring conclusions, perhaps "[peer review]" would make a better tag. Anyway this review (also tellingly) got very sidetracked into the implementation details. 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've already cloned the repo and have a reasonable idea how to commit it. Then others that others can chime in about the implementation (Stefan has already been doing so). J