From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: Taming some chaos Date: Fri, 16 Oct 2015 18:36:58 +0300 Message-ID: <5621199A.1030109@yandex.ru> References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1445009859 14473 80.91.229.3 (16 Oct 2015 15:37:39 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 16 Oct 2015 15:37:39 +0000 (UTC) To: John Yates , Emacs developers Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Oct 16 17:37:34 2015 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 1Zn74Q-0007mw-Ke for ged-emacs-devel@m.gmane.org; Fri, 16 Oct 2015 17:37:26 +0200 Original-Received: from localhost ([::1]:54503 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zn74K-0007X6-Vq for ged-emacs-devel@m.gmane.org; Fri, 16 Oct 2015 11:37:20 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50126) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zn747-0007X1-QK for emacs-devel@gnu.org; Fri, 16 Oct 2015 11:37:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zn742-0007vL-Pt for emacs-devel@gnu.org; Fri, 16 Oct 2015 11:37:07 -0400 Original-Received: from mail-wi0-x229.google.com ([2a00:1450:400c:c05::229]:34673) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zn742-0007v9-JH for emacs-devel@gnu.org; Fri, 16 Oct 2015 11:37:02 -0400 Original-Received: by wicgb1 with SMTP id gb1so14458394wic.1 for ; Fri, 16 Oct 2015 08:37:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:to:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=OO7kLagZojjvVdg/HqqLaOLmxpktmQPVKvCaJvya13w=; b=LxX3g2shFG0VZCAMQGLv7+0DXhrcmIuiAWtmOm5XB2EEfSvcYpCwNXL1YuaQuImX0U Fr1GEafDHI7imDpaGqWG+TG0+GqC1h5X86iJDV6/oxzoWxKWVqboABwHUrMMgmY7v+yG HTIEqgdolr9RYV7hbX4IIASvIFy9H7v1BfKjF+K2U+bKdnrZKEZr/RKYEZ5U1sQ7c09C lM+Bl9lzyeY9BxclFzR/dbd/JP1JGVmcUBdUHN84GTfWgvgC09TQ8V8+1SqmdKFnh4VK rxpmy1shIYmwkSOdWJUAY4PwmIrZ18+In/L2cncHd+uDH9ozy0u+YQIORIA+TCiUhDOV 6aYg== X-Received: by 10.195.13.164 with SMTP id ez4mr17460190wjd.112.1445009821466; Fri, 16 Oct 2015 08:37:01 -0700 (PDT) Original-Received: from [10.9.0.103] (nat.webazilla.com. [78.140.128.228]) by smtp.googlemail.com with ESMTPSA id bf8sm23167843wjc.22.2015.10.16.08.37.00 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 16 Oct 2015 08:37:00 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:42.0) Gecko/20100101 Thunderbird/42.0 In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c05::229 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:191769 Archived-At: On 10/14/2015 02:47 PM, John Yates wrote: > Window management > > Too many packages explicitly choreograph how windows are managed, > where and when they should be split, where buffers should be displayed > and whether or not any previous window configuration should be restored. > Such logic is articulated in terms of detailed manipulation of a simplistic > "current-window / other-window" model no matter how poorly it maps to > the user's actual configuration. In essence such packages have taken on > managing the presentation layer even when that is not their main focus. I agree. One could point to display-buffer-alist, a third-party packages like shackle or popwin, but even then the user has to operate lower-level primitives of window management. Some higher abstraction and UI would do us some good. But it's not like it's trivial to even design that. > It does not have to be that way. In the X world there are any number of > window manages (both tiling and overlapping). The overwhelming majority > of applications run correctly irrespective of the user's choice of Wm. X has it easier: each application usually gets its own frame. And they can have modal windows (there's nothing really corresponding to that in Emacs). > Fonts and colors schemes > ... > Surely given Emacs' support for > inheritance within the faces framework we should be able to introduce a > vocabulary of basic concept faces from which packages then would be > encouraged to inherit. font-lock-*-face? And faces in lisp/faces.el, the list of which can be extended. > Trying to wrestle that many faces into a coherent color scheme > and trying to achieve any degree of commonality across packages is > excruciating. I have to believe there are members of our community who > are familiar with color palette UX strategies and technologies (e.g. iPhone > or Android Material style guidelines). Hopefully someone will come forward > and propose a model. In my vision an Emacs user would choose a palette > (likely along with a mapping of palette items to visual roles). That would be nice as well.