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: Mon, 17 Sep 2018 02:17:05 +0000 Message-ID: <20180917021705.GA4043@ACM> References: <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> <20180916105225.GA4579@ACM> <3D72B095-01EC-4E7D-90F9-5691AEFE16DC@aol.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1537150724 14636 195.159.176.226 (17 Sep 2018 02:18:44 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 17 Sep 2018 02:18:44 +0000 (UTC) User-Agent: Mutt/1.10.1 (2018-07-13) Cc: emacs-devel@gnu.org To: Ergus Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Sep 17 04:18:40 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 1g1j7X-0003h7-WB for ged-emacs-devel@m.gmane.org; Mon, 17 Sep 2018 04:18:40 +0200 Original-Received: from localhost ([::1]:33346 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g1j9e-0000sN-CB for ged-emacs-devel@m.gmane.org; Sun, 16 Sep 2018 22:20:50 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50918) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g1j9Q-0000s5-EE for emacs-devel@gnu.org; Sun, 16 Sep 2018 22:20:37 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1g1j9K-0001S0-Hy for emacs-devel@gnu.org; Sun, 16 Sep 2018 22:20:34 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:23351 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1g1j9K-0001RW-Ae for emacs-devel@gnu.org; Sun, 16 Sep 2018 22:20:30 -0400 Original-Received: (qmail 25361 invoked by uid 3782); 17 Sep 2018 02:20:28 -0000 Original-Received: from acm.muc.de (p5B14752A.dip0.t-ipconnect.de [91.20.117.42]) by colin.muc.de (tmda-ofmipd) with ESMTP; Mon, 17 Sep 2018 04:20:27 +0200 Original-Received: (qmail 4133 invoked by uid 1000); 17 Sep 2018 02:17:05 -0000 Content-Disposition: inline In-Reply-To: <3D72B095-01EC-4E7D-90F9-5691AEFE16DC@aol.com> 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:229878 Archived-At: On Sun, Sep 16, 2018 at 17:18:53 +0200, Ergus wrote: > On 16 September 2018 12:52:25 CEST, Alan Mackenzie wrote: > >Hello, Ergus. > >On Sat, Sep 15, 2018 at 21:44:19 +0200, Ergus wrote: > >> 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". > There is a reason why all the other editors use similar aproach > different to this. So it shouldnt be that bad. I suggest that reason is to be easily learnable with the minimum of mental effort. Emacs's priority is to be as easily usable with the minimum of effort. Hence the different approaches. > >What could be simpler than Emacs's point, mark and region scheme, and > >still get the job done? > There are many options but depends of the users and the use case. Modes > like vim, cua-mode and similar aproaches for rectangular work, multiple > cursors. A real selection as anything else... highlighted. Don't have a > region when you dont want a region... > It depends on the workflow... Simple for me may not be simpler for you. You've completely misconstrued my meaning. By simple, I meant something like the aesthetic of minimality. Point and mark define a region. There is nothing left in that set of concepts that you could take away and still have a usable editor. At the same time, point and mark are fully adequate for efficient working. That's not to say that some people prefer less elegance and more elaborate facilities (such as transient-mark-mode). That's fine. > >> 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. > Also agree. For example: If i dont like to have always a region do I > have an alternative? The region is simply a portion of your buffer. What you're suggesting is epistemologically incoherent. It's "if I don't like always to have a portion of my buffer do I have an alternative?". No, Emacs can't support such nonsense. Sorry. I wonder just how widespread this misconception is in Emacs users. > >> 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? > This is your very personal opinion. It is a good approach, but there > are others equally good and in my opinion some better and more logical > for some use cases. (Or just faster) It's not just my personal opinion, it's objective, too. Your assertion that "the mark-point approach is not a fundamental emacs thing" is, I think, a personal wish, but unfounded. This approach is baked into so many Emacs primitives and higher level commands that to try to remove it would be essentially impossible. It would likely be less work to write a new editor from scratch. > Some people likes to use vim with its insert and copy modes. Some > people likes to use the mouse... They are much much more than the ones > that likes emacs in tty... Some people uses windows... Emacs aims to cater for all these user preferences, and, I think, does a reasonable job at this. How many other modern editors support a tty? > There are standards in all the interfaces and programs. A user dont > need to read anything to know how to do basic stuf anywhere. Even gnu > programs have created many of these standards. (Screen tmux bash xterm) Emacs is about more than just doing basic stuff. It's a powerful tool with extreme user friendliness. This necessarily means it's not going to be beginner friendly, or easy to learn. > In my telegram emacs group 80 % of the users use evil mode or > spacemacs... Does it means something to you as a developer? If that usage pattern is widespread, then it suggests that these facilities are worth maintaining, or possibly incorporating into the Emacs core, as the case may be. > >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. > In this thread I only see you with so strong feelings that it is a kind > of divine perfect iluminated idea and should be as is for the universal > equilibrium. Again, what were these supposed technical limitations which you say gave rise to point/mark/region? I suggest to you that there were and are no such technical limitations. [ .... ] > >I fear that by "updated/upgraded" you really mean "made more > >complicated, less flexible, and (possibly) dumbed down". > You dont know... Maybe after all eli or anyone comes with a most genius > and iluminated idea. Or if we ask the users they can propose > alternatives that we havent even imagined. Emacs is an open project. Anybody is welcome to contribute and implement new ideas, and if they are coherent and worthwhile will likely be incorporated into Emacs. transient-mark-mode was such an idea, which was quickly incorporated, eventually becoming the default setting (something I think was unwise). > >You say "it should be updated/upgraded". Somebody has to do this > >work. > I didnt say that. In fact i dont have actually any urgent problem with > this. But i dont like the orthodox idea of consider it as perfect and > better than anything else, because it isnt. Perfect, no, but better than anything else, for some values of "better", then yes. But, as just said, anybody who considers the point/mark mechanism inadequate is welcome to enhance it, or to add some other mechanism. > I am not ready to contribute... But this kind of aptitude and strong > strict opinions about a simple detail dont help to attract new > developers. Doesn't it? There has been a steady stream of new people actively contributing in the last few years. > The same if you suggest to use a different editor when anyone proposes > to change something because you consider it is a fundamental axiom. Point/mark _is_ fundamental to Emacs, and hardly possible to remove. And good as Emacs is, I would not maintain it is suitable for everybody. > >Are you prepared to contribute, yourself? > WIP. > >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. > Totaly right. -- Alan Mackenzie (Nuremberg, Germany).