From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: delete-selection-mode as default Date: Sun, 16 Sep 2018 10:52:25 +0000 Message-ID: <20180916105225.GA4579@ACM> References: <8736udkuit.fsf@toy.adminart.net> <20180914104833.GA4103@ACM> <83k1nojgia.fsf@gnu.org> <7bed1f76-5bae-44cb-9b22-206b513043be@default> <83d0tfkj77.fsf@gnu.org> <1c393214-c186-4760-9a37-e0450c946446@default> <83zhwji4hx.fsf@gnu.org> <20180915102016.GA15443@ACM> <20180915194419.bty3fzs5tnjez3pq@Ergus> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1537095233 13405 195.159.176.226 (16 Sep 2018 10:53:53 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 16 Sep 2018 10:53:53 +0000 (UTC) User-Agent: Mutt/1.10.1 (2018-07-13) Cc: hw@adminart.net, joostkremers@fastmail.fm, npostavs@gmail.com, emacs-devel@gnu.org, yurivkhan@gmail.com, Eli Zaretskii , Drew Adams , phillip.lord@russet.org.uk To: Ergus Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Sep 16 12:53:48 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1g1UgV-0003LL-51 for ged-emacs-devel@m.gmane.org; Sun, 16 Sep 2018 12:53:47 +0200 Original-Received: from localhost ([::1]:58600 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g1Uib-0000oZ-F9 for ged-emacs-devel@m.gmane.org; Sun, 16 Sep 2018 06:55:57 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48311) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g1UiV-0000oH-Ie for emacs-devel@gnu.org; Sun, 16 Sep 2018 06:55:52 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1g1UiS-0000zf-6d for emacs-devel@gnu.org; Sun, 16 Sep 2018 06:55:51 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:53943 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1g1UiR-0000yy-Qu for emacs-devel@gnu.org; Sun, 16 Sep 2018 06:55:48 -0400 Original-Received: (qmail 63766 invoked by uid 3782); 16 Sep 2018 10:55:46 -0000 Original-Received: from acm.muc.de (p5B1464F1.dip0.t-ipconnect.de [91.20.100.241]) by colin.muc.de (tmda-ofmipd) with ESMTP; Sun, 16 Sep 2018 12:55:42 +0200 Original-Received: (qmail 4758 invoked by uid 1000); 16 Sep 2018 10:52:25 -0000 Content-Disposition: inline In-Reply-To: <20180915194419.bty3fzs5tnjez3pq@Ergus> X-Delivery-Agent: TMDA/1.1.12 (Macallan) X-Primary-Address: acm@muc.de X-detected-operating-system: by eggs.gnu.org: FreeBSD 9.x [fuzzy] X-Received-From: 193.149.48.1 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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" Xref: news.gmane.org gmane.emacs.devel:229840 Archived-At: Hello, Ergus. On Sat, Sep 15, 2018 at 21:44:19 +0200, Ergus wrote: > I have also interacted with hw and I totally disagree that he doesn't > want to use emacs. Maybe it is because I am a "younger" emacs users > too, or that I have tried many other editors & IDEs, but I understand > what he says and the fear the first time a user opens emacs comparing > to other similar tools. He just perceives the same than I: Emacs needs > changes to simplify the user experience, but any key change faces too > much resistance. > My approach is > 1) To keep the default things AS SIMPLE AS POSSIBLE for the user in > any case, specially in a basic software like a text editor. (SIMPLE > and INTUITIVE if possible) By "simple and intuitive" I think you just mean "like other editors the user may have already used". What could be simpler than Emacs's point, mark and region scheme, and still get the job done? > 2) I agree with the Eli's approach to find a mean point that makes > less unhappy most of the people (if possible). That means, I think, being able to customise Emacs to suit ones' own preferences. > 3) But interface changes are needed to survive, they require care to > avoid conflicts and reduce the collapse with backward compatibility, > but are needed. > NEVERTHELESS > The mark-point approach is not a fundamental emacs thing, it is just a > design choice enforced for technical limitations 40 years ago (like the > vi modes, the meta-hyper-syntax and so on) This means that (citing Bill > Joy about vi) it was created for a world that doesn't exist anymore. So > it can (and should) be updated/upgraded as many other things in emacs > and any long living project. I can't let this pass without comment. The point, mark, region approach (I'm considering it here without the complications introduced by transient-mark-mode) is a stroke of genius, combining austere simplicity with great flexibility and ease of use. How well do you understand this approach? Just what were these technical limitations which you assert gave rise to point/mark/region? The world which gave rise to it may no longer exist, but the idea is so good that it remains powerful and relevant. Analogously, the worlds which gave rise to the pottery which archaeologists dig up are no more, but we still make and use pottery today. I fear that by "updated/upgraded" you really mean "made more complicated, less flexible, and (possibly) dumbed down". You say "it should be updated/upgraded". Somebody has to do this work. Are you prepared to contribute, yourself? Proposals for changes, particularly drastic changes, tend to be much better received here when they come in the form of patches rather than just vague ideas. [ .... ] -- Alan Mackenzie (Nuremberg, Germany).