From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: John Yates Newsgroups: gmane.emacs.devel Subject: Taming some chaos Date: Wed, 14 Oct 2015 07:47:33 -0400 Message-ID: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a11343ec0ccae9e05220f20d9 X-Trace: ger.gmane.org 1444823382 30301 80.91.229.3 (14 Oct 2015 11:49:42 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 14 Oct 2015 11:49:42 +0000 (UTC) To: Emacs developers Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Oct 14 13:49:27 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 1ZmKYc-00042z-MN for ged-emacs-devel@m.gmane.org; Wed, 14 Oct 2015 13:49:22 +0200 Original-Received: from localhost ([::1]:41823 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZmKYc-0000CT-8v for ged-emacs-devel@m.gmane.org; Wed, 14 Oct 2015 07:49:22 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57781) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZmKWu-00083H-Cc for emacs-devel@gnu.org; Wed, 14 Oct 2015 07:47:38 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZmKWs-0007bO-Li for emacs-devel@gnu.org; Wed, 14 Oct 2015 07:47:36 -0400 Original-Received: from mail-pa0-x230.google.com ([2607:f8b0:400e:c03::230]:35595) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZmKWs-0007bC-Cn for emacs-devel@gnu.org; Wed, 14 Oct 2015 07:47:34 -0400 Original-Received: by padcn9 with SMTP id cn9so21605829pad.2 for ; Wed, 14 Oct 2015 04:47:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=HlHRqmuIMvYQmjMXe01oXL33Y9dOoV61TJ4C7YRSsdg=; b=tKzHwkLsDtxZjHdtyP+WWzmzXzlNqDzmvQi1oGS669+9VkgfVFxBHZJNHEfMGRX9Dd TRp5nbQQeo2TxQzdUV4v8iiw3rnvmSJHkemXWtKEgypJ3eOEFKFTwHeL/uF7WB1pSO2A cR4TpQGE6jz2joC2ermtDUHypuJJI51im21zQ/ArML7A4IQDe1SSA548CXYLz6JX/Wo2 q8rQ+M5qrdFu29SGrxCBh6J+RDcDrPwtqyadLCYzsFhAtEgNfe15gEMWzvd3NlunIFJ7 OxHE9+r33k0Crs7Ru9109fNrCfv22yT3ZeDrcpegWL9ETwSj/uG4Sh5dAGkCUcIfZCkO arcQ== X-Received: by 10.67.23.165 with SMTP id ib5mr3328012pad.26.1444823253668; Wed, 14 Oct 2015 04:47:33 -0700 (PDT) Original-Received: by 10.66.159.101 with HTTP; Wed, 14 Oct 2015 04:47:33 -0700 (PDT) X-Google-Sender-Auth: dPm0vj6QbwwlfdGhZ7zfA-IwpeY X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:400e:c03::230 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:191549 Archived-At: --001a11343ec0ccae9e05220f20d9 Content-Type: text/plain; charset=UTF-8 On Sat, Oct 10, 2015 at 2:31 PM, John Wiegley wrote: > We should define what we want from a "more IDE" Emacs. For example, I do > not > want window-layout functionality. That's a presentation aspect of IDEs > that's > entirely separate from what I want from them. > ... > To reiterate: I think Emacs becomes more of an IDE when it provides the > backbone of an IDE, and not when it looks like one. We have some pieces of > that backbone already, which have avoided fragmentation in those areas, > but we > need more. A standardized way to do tooltips, popups, visual completion > selection (or at least the structure), REPLs that interact with buffer > contents, etc., would give us a foundation to move to the next step. Apart from any IDE functionality there are general weaknesses in Emacs' current collection of packages that I think represents a significant barrier to bringing in new recruits, both users and developers. I want to argue that most packages dabble in too many areas and are coded in too imperative a manner. Such shortcoming can be understood in light of the era and technological setting in which many Emacs conventions and paradigms were first developed. But that does not alter the fact that the state of computing / UX / what-have-you has advanced significantly. >From a user's POV too many Emacs packages violate the Unix paradigm of simple composable tools that perform a single task well. Instead of being supported by a framework or an environment in which a user registers global policies and preferences and wherein an executing package requests services in terms of high-level abstractions too many Emacs packages implement large swashes of concrete, detailed UI logic. Here are two examples: 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 have been developing a small package to maintain a persistent horizontal window (PHW) akin to ECB's persistent shell window. My default layout on a 30" 2560x1600 screen now includes a shallow full width PHW plus two, three or four additional, balanced vertical "user" or "edit" windows. I am struck by how many packages behave poorly in this setting. When I am lucky a package I want to use provides sufficient config settings and hooks that I can achieve satisfactory behavior in my less typical environment. When I am unlucky I have to add ad-hoc logic into my window manager to accommodate a number of packages. Predictably the more window manipulation a package performs the more likely I am to have to resort to such ad-hoc solutions. 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. In fact users have a sufficient expectation of correct inter-operation that when it breaks they do not accept that breakage as "just the way things are", as we might do in the Emacs world. Instead it is viewed as an outright bug, be it in the WM or in the application (most likely its toolkit or framework). Fonts and colors schemes The "angry salad" meme is only a way of brushing off a truly awful aspect of adopting a new Emacs package. Here again we suffer from a lack of abstractions. In the realm of text markup technologies we all recognize the merits of declarative ("this is a first level heading", "this is an element of an numbered list", "emphasize this text") over imperative (render this text in a specific font at a particular point size and weight, prefix this paragraph with '3.' and indent it by 1/2", use italics). 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. That said I am not so naive as to think that a finite set of base faces mapped to semantic concepts will cover the needs of the rich packages we have. Ediff has nearly 20 faces and the current version of magit has over 90. 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). Then an Emacs provided service could generate faces on demand based on application requested attributes / properties. /john --001a11343ec0ccae9e05220f20d9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sat, Oct 10, 2015 at 2:31 PM= , John Wiegley=C2=A0<johnw@newartisans.com>=C2=A0wrote:<= br>
We should define what we want from a "more IDE&quo= t; Emacs. For example, I do not
want window-layout functionality. That&#= 39;s a presentation aspect of IDEs that's
entirely separate from wha= t I want from them.
...
To reite= rate: I think Emacs becomes more of an IDE when it provides the
backbone= of an IDE, and not when it looks like one. We have some pieces of
that = backbone already, which have avoided fragmentation in those areas, but weneed more. A standardized way to do tooltips, popups, visual completionselection (or at least the structure), REPLs that interact with buffercontents, etc., would give us a foundation to move to the next step.

Apart from any IDE functionality there are gener= al weaknesses in Emacs'
current collection of packages that I= think represents a significant barrier to
bringing in new recrui= ts, both users and developers.=C2=A0 I want to argue that most
pa= ckages dabble in too many areas and are coded in too imperative a manner.
Such shortcoming can be understood in light of the era and technol= ogical
setting in which many Emacs conventions and paradigms were= first =C2=A0developed.
But that does not alter the fact that the= state of computing / UX / what-have-you
has advanced significant= ly.

From a user's POV too many Emacs pack= ages violate the Unix paradigm
of simple composable tools that pe= rform a single task well.=C2=A0 Instead of being
supported by a f= ramework or an environment in which a user registers global
polic= ies and preferences and wherein an executing package requests services
in terms of high-level abstractions too many Emacs packages implement=
large swashes of concrete, detailed UI logic.=C2=A0 Here are two= examples:

Window management

<= div>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 r= estored.
Such logic is articulated in terms of detailed manipulat= ion of a simplistic
=C2=A0"current-window / other-window&quo= t; model no matter how poorly it maps to
the user's actual co= nfiguration.=C2=A0 In essence such packages have taken on
managin= g the presentation layer even when that is not their main focus.

I have been developing a small package to maintain a p= ersistent horizontal
window (PHW) akin to ECB's persistent sh= ell window.=C2=A0 My default layout on
a 30" 2560x1600 scree= n now includes a shallow full width PHW plus two,
three or four a= dditional, balanced vertical "user" or "edit" windows.= =C2=A0 I am
struck by how many packages behave poorly in this set= ting.=C2=A0 When I am
lucky a package I want to use provides suff= icient config settings and hooks
that I can achieve satisfactory = behavior in my less typical environment.
When I am unlucky I have= to add ad-hoc logic into my window manager
to accommodate a numb= er of packages.=C2=A0 Predictably the more window
manipulation a = package performs the more likely I am to have to resort to
such a= d-hoc solutions.

It does not have to be that way.= =C2=A0 In the X world there are any number of
window manages (bot= h tiling and overlapping).=C2=A0 The overwhelming majority
of app= lications run correctly irrespective of the user's choice of Wm.=C2=A0 = In fact
users have a sufficient expectation of correct inter-oper= ation that when it
breaks they do not accept that breakage as &qu= ot;just the way things are", as
we might do in the Emacs wor= ld.=C2=A0 Instead it is viewed as an outright bug,
be it in the W= M or in the application (most likely its toolkit or framework).
<= br>
Fonts and colors schemes

The "a= ngry salad" meme is only a way of brushing off a truly awful aspect
of adopting a new Emacs package.=C2=A0 Here again we suffer from a = lack of
abstractions.=C2=A0 In the realm of text markup technolog= ies we all recognize the
merits of declarative ("this is a f= irst level heading", "this is an element of an
numbered= list", "emphasize this text") over imperative (render this = text in
a specific font at a particular point size and weight, pr= efix this paragraph
with '3.' and indent it by 1/2",= use italics).=C2=A0 Surely given Emacs' support for
inherita= nce within the faces framework we should be able to introduce a
v= ocabulary of basic concept faces from which packages then would be
encouraged to inherit.

That said I am not so nai= ve as to think that a finite set of base faces
mapped to semantic= concepts will cover the needs of the rich packages
we have.=C2= =A0 Ediff has nearly 20 faces and the current version of magit has
over 90.=C2=A0 Trying to wrestle that many faces into a coherent color sc= heme
and trying to achieve any degree of commonality across packa= ges is
excruciating.=C2=A0 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 guideline= s).=C2=A0 Hopefully someone will come forward
and propose a model= .=C2=A0 In my vision an Emacs user would choose a palette
(likely= along with a mapping of palette items to visual roles).=C2=A0 Then an Emac= s
provided service could generate faces on demand based on applic= ation
requested attributes / properties.

/john

--001a11343ec0ccae9e05220f20d9--