From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.help Subject: Re: Render a buffer or string to a simpler string? Date: Mon, 27 May 2013 03:20:00 +0400 Message-ID: <871u8tcorj.fsf@yandex.ru> References: <87bo7yq2az.fsf@yandex.ru> <83d2serd46.fsf@gnu.org> <87vc66d96b.fsf@yandex.ru> <83a9niqwsa.fsf@gnu.org> <87y5b2tnpl.fsf@yandex.ru> <834ndprd1z.fsf@gnu.org> <87sj19sqb2.fsf@yandex.ru> <83zjvhpvjn.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1369610451 22710 80.91.229.3 (26 May 2013 23:20:51 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 26 May 2013 23:20:51 +0000 (UTC) Cc: help-gnu-emacs@gnu.org To: Eli Zaretskii Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Mon May 27 01:20:52 2013 Return-path: Envelope-to: geh-help-gnu-emacs@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 1UgkF8-00041c-4e for geh-help-gnu-emacs@m.gmane.org; Mon, 27 May 2013 01:20:50 +0200 Original-Received: from localhost ([::1]:42861 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UgkF7-00039z-Jz for geh-help-gnu-emacs@m.gmane.org; Sun, 26 May 2013 19:20:49 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:39701) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UgkEi-00038e-Ue for help-gnu-emacs@gnu.org; Sun, 26 May 2013 19:20:36 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UgkEU-0003WJ-CW for help-gnu-emacs@gnu.org; Sun, 26 May 2013 19:20:24 -0400 Original-Received: from mail-la0-x232.google.com ([2a00:1450:4010:c03::232]:51688) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UgkEU-0003Vg-1m; Sun, 26 May 2013 19:20:10 -0400 Original-Received: by mail-la0-f50.google.com with SMTP id ed20so5874572lab.23 for ; Sun, 26 May 2013 16:20:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type:x-antivirus:x-antivirus-status; bh=8R7S48lD5jdkTHucoOS6E3ukVSpgVz437Z9qEicaGCA=; b=N7oMBJmPRGfffm3SH0hny7AadrCmTzYl2Ldy5syNv3ad8xN3dfQuTMJA+cEruAqPJT 50k4ccPziPOxgObhCyjRabqUwHBTOmkYNovalLMrGujULzWA53ZsUQBFAfzQbpRRkt26 wFT9Rz4/u+xeewEiKaIYlgblSUvFx+Wy2isPwK3RNONxAkmuG5l4UY+17Df5IT7WKL4B tFk4VSziFYWYAKX6TYKW8ep4CvO1x8Z31GmJIs+FlNWMt0qz2An3CoMFvuo3SKfdP/bZ SJNZftMLnd56XJGmuQ9gEtWFlDR6q+zumbWPBEVU7x3jFpwglnXhwzuzYbm5plKQo8fk 3pIg== X-Received: by 10.152.4.234 with SMTP id n10mr6267894lan.5.1369610408630; Sun, 26 May 2013 16:20:08 -0700 (PDT) Original-Received: from SOL ([178.252.98.87]) by mx.google.com with ESMTPSA id w3sm10876679lae.7.2013.05.26.16.20.06 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 26 May 2013 16:20:07 -0700 (PDT) In-Reply-To: <83zjvhpvjn.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 26 May 2013 19:15:08 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (windows-nt) X-Antivirus: avast! (VPS 130526-0, 26.05.2013), Outbound message X-Antivirus-Status: Clean X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:4010:c03::232 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:91078 Archived-At: Eli Zaretskii writes: >> Pixel-granular alignment would probably be ignored, `face' properties >> would be either ignored, or just kept as-is in the rendered string. > > Keeping the faces makes sense if they are automatically generated, but > not if they are put by explicit Lisp code, since then you just get > whatever the code put. There's no easy way to compare faces, save for rendering to some external format like images or html. So yeah, this mechanism by itself would be unsuitable for testing i.e. syntax highlighting. If you recall, I gave some examples of text properties that *could* be tested with it. I'll admit that `before-string', `display', etc, are not used too much by packages everywhere, but they do get used, and other packages sometimes have to interoperate with those that do. (*) (**) >> A human has to write these tests, and then come back later, be able to >> read and modify them. Try doing that efficiently with screen grabs. > > UI testing people do that all the time: you compare the grab with some > baseline. I'm not saying it can't be done with grabs. http://en.wikipedia.org/wiki/Efficiency And if you're suggesting just comparing screenshots, even font rendering is very different across platforms, and it's affected by many settings, so each such reference image would be platform- and settings-specific. Good luck writing a portable test suite. >> The only means of building interface widgets exposed to Elisp are text >> properties, AFAIK. They do include some graphical-only features, but >> those aren't used as often as one might expect. > > Try looking at Customize, and you will see a different story. Customize is just one package. By "often", I meant the percentage of packages that do, compared to the total amount, not "number of interactions by users per hour". But Customize still works with -nw, right? It might be helpful to test just how it looks in non-graphical terminal, and verify any additional features separately. (*) Two examples: - `outlne-minor-mode' hides a portion of buffer text, our overlay covers it (https://github.com/company-mode/company-mode/issues/16), we'd like to make sure the rectangle is still still drawn in the right shape. - `org-indent-mode' uses `line-prefix' and `wrap-prefix' text properties, and they seep into strings we collect from the buffer before drawing over them (https://github.com/company-mode/company-mode/issues/24). We'd like to make sure the lines still look fine, even when there are such text properties inside the overlay's `before-string'. I ended up removing `line-prefix' from all collected lines, prepending the values physically to the strings that get collected, but it's not fun that I need to look up the property value at the beginning of the line and act on it, instead of just asking "gimme the line like it looks!" (actually, I should search the whole line, but that's more work, so I'm not doing that until someone else asks). I don't handle `wrap-prefix' here at all because it's one more special case, and luckily, org-mode buffers truncate lines by default. Another thing I found lacking is a version of `current-column' that's aware of those text properties. (**) Another feature that would render better to strings is visual line folding (when truncation is off). For example, the candidates popup in Company needs to work with visual lines, not physical ones, so writing a test that ensures that popup overlay took the requires lines and painted over them, without jumping over folded lines, woult be useful. Although, in this case, the harder part is setting up the test data the right way to make sure the line does get wrapped where it should.