emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: display-buffer-alist simplifications


From: David Kastrup
Subject: Re: display-buffer-alist simplifications
Date: Tue, 26 Jul 2011 12:50:32 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux)

"Stephen J. Turnbull" <address@hidden> writes:

> David Kastrup writes:
>
>  > One aim of the GNU project is empowering users.  An interface that
>  > requires relying on highly competent special users and/or extensive
>  > experimentation (which often leads to results relying on undefined
>  > artifacts of the current behavior) is not conducive in that regard.
>
> That criticism applies to all of Emacs in greater or lesser degree,
> mostly greater IMHO.

There is a qualitative difference between requiring leads and pointers,
and requiring somebody else to do the work.

> But that's not important.  My main claim is that the important
> question is not "is the interface complex?"  Rather it is, "is the
> power available with a simpler interface?"  If the answer is "no" (and
> I believe that is true for the problems addressed by XEmacs specifiers
> -- a generalization of "defface" as Juri points out -- and by Martin's
> specifiers), then the question becomes, "shall we have a complex
> interface that empowers some users more than others, or shall we have
> a procrustean interface that ensures all users have equal and low
> capability?"  Emacs obviously has to go for the former; we'll never be
> able to equal "Notepad" in the latter. ;-)

Sometimes the right question is "where did we go wrong that we require
this sort of power in the first place?".  When did we fall off the cliff
of diminishing returns?  It is, in my opinion, the main question to be
solved in the energy, climate, waste, law&order crisises.

> Different case, IIUC.  AIUI the resource CEDET is missing is a central
> piece of "the preferred form for making changes to the software."  I
> find it incomprehensible that CEDET was permitted to be installed in
> Emacs in that state (or perhaps I misunderstand the issue), but it's
> not my problem.

The rationale as far as I understand was "it is useful, this is just
transitory, and we are going to fix this when the version control
migrations are past, quite certainly before the next major release".

The cases are related in as far that they frustrate me by keeping me
from having the power to work with the software on my system.

> The SXEmacs developers understand fine, as do many XEmacs users.  Your
> situation is different; you aren't an XEmacs user except to the extent
> that you support a few XEmacs users who also happen to use AUCTeX.

I am no longer doing that.

> You had every right to complain, although it was less than gracious of
> you to refuse to review the rewrite of the documents you complained so
> vociferously about.

There would be little point to reviewing XEmacs programming documents
when I don't have a copy of XEmacs installed anymore.

-- 
David Kastrup




reply via email to

[Prev in Thread] Current Thread [Next in Thread]