Re: Taming some chaos

[Dmitry Gutov <dgutov@yandex.ru>]

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.