From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: GNU Emacs raison d'etre Date: Wed, 13 May 2020 23:52:56 +0300 Message-ID: <06bcddd4-6991-e4f7-e944-93de14af263d@yandex.ru> References: <5230692c-c665-a330-7a12-e59fa25d97dd@gmail.com> <70bb51fd-447d-928c-4d69-1c9673a44471@online.de> <871rnnvmdx.fsf@red-bean.com> <87pnb7sira.fsf@red-bean.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="118644"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 Cc: emacs-devel@gnu.org To: Karl Fogel , =?UTF-8?Q?Andreas_R=c3=b6hler?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed May 13 22:53:38 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jYyNl-000UiT-OR for ged-emacs-devel@m.gmane-mx.org; Wed, 13 May 2020 22:53:37 +0200 Original-Received: from localhost ([::1]:48478 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jYyNk-0008SR-QE for ged-emacs-devel@m.gmane-mx.org; Wed, 13 May 2020 16:53:36 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:56186) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jYyND-00083b-AK for emacs-devel@gnu.org; Wed, 13 May 2020 16:53:03 -0400 Original-Received: from mail-wm1-x32d.google.com ([2a00:1450:4864:20::32d]:54560) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jYyNB-0002Cv-2G for emacs-devel@gnu.org; Wed, 13 May 2020 16:53:02 -0400 Original-Received: by mail-wm1-x32d.google.com with SMTP id h4so28032585wmb.4 for ; Wed, 13 May 2020 13:53:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=sKjlopNd/424AQcd1IiJt72oCwWb1XEV9qppKzz4zhA=; b=XP/NahFr0EOrY7O8cDf0sb8K0sOKjCEHRrw3wsqi7tEoiLoeT0Jw+eR37Ht4p2xeSp UcaU9nMd9bSrxz3ApGzoS3pUDjFmtq/S2kEKhQXwezgzKdExNH6mFaKjg7Q738RbXiwq Vb02v/BeOvF+y6TrBJRvg/Z/QEBrhw7wH6AjSE++Q4QtXRg6cL+pUreG/ZmDNOfxCGvm JD4i5ANMq4lG7GJGctnMoWF6aKLlgBUSK716Kbn8gSJHTIvfG+g6SVsN+xD06Mk4e/gO HqEMJ6jbJeB/KNWgXtTmIQmTPd5MldxAjrVnsf6BGffkxHOYcz7i6BSvQk0Z0eUEDcJ/ Ok8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=sKjlopNd/424AQcd1IiJt72oCwWb1XEV9qppKzz4zhA=; b=fEHWxmePOjz2UDz/bEDoPgXFUtCETC0MuoJ/eWesfwF+U9KwA3Sukbu5tjD0BAI3Xv SoBK8EZNdfQSJuplsWxaC6ccIcNRl8LhXDqDBM60NAlUAZ6XrEnUIbaCtNbEGZ/v346X uq3O/r4MjDMiKG0cNvydmnZGiFkqNCggD9G2Mdv3PANCcyCFMXdi6PyC3FZ5lIZQN2FS 6YaRtLr/W8SwkF+BlJWyGwwD+3sA7j+BwGCzq2YNGKVRKi6YAB0O+ffqPwYzbcEnbLY6 /3rURoHskomhV0Bf3xSWVrO+BGALEwhz9lKpA0sj6kwBIi5yGeS7+TudSpV53Z2XWlEj sDaw== X-Gm-Message-State: AOAM533LNjpNYHsCwVjsaPZYsPQ1119SBpOXINFYHWKvqu622W8L8h9j qNcncPP7Xw06H1lMg/QpqD8OfXMA X-Google-Smtp-Source: ABdhPJxZg17RAGFvVMv3lXY6s6akJk9ttDZtON2Yv42uM7LXrj3ggWIMVn5IzPJvbECD0EP/tSQp2w== X-Received: by 2002:a7b:c3da:: with SMTP id t26mr11443289wmj.146.1589403178693; Wed, 13 May 2020 13:52:58 -0700 (PDT) Original-Received: from [192.168.0.3] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id a81sm30856229wmh.7.2020.05.13.13.52.57 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 13 May 2020 13:52:58 -0700 (PDT) In-Reply-To: <87pnb7sira.fsf@red-bean.com> Content-Language: en-US Received-SPF: pass client-ip=2a00:1450:4864:20::32d; envelope-from=raaahh@gmail.com; helo=mail-wm1-x32d.google.com X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. X-Spam_score_int: -17 X-Spam_score: -1.8 X-Spam_bar: - X-Spam_report: (-1.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001 autolearn=_AUTOLEARN X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:250161 Archived-At: On 13.05.2020 23:05, Karl Fogel wrote: > Use of small symbols to indicate state in the modeline is another area. Experienced users know what "**" in the mode line means, what "%" means, etc. Newcomers are frequently confused by the mode line; it is noise to them, until they know how to interpret it -- but that takes a bit of investment. Now, we could provide bigger, more verbose signs of current state -- but then we'd be taking away screen real estate again. > > Another area is the keybinding space and the minibuffer. Just about every time I have watched a new user use Emacs, I have noticed how frequently they accidentally hit some key combination or sequence and wind up in some weird state that they never meant to be in -- and don't know how to get out of. Often they have minibuffer prompts sitting around all the time, and are unaware that Emacs is asking them for some piece of information (after all, the user didn't mean to put Emacs into that state and has no idea she did so). But having those keybindings available is*good* for experts, as we know from personal experience. I might with agree with you principle, but both examples seem suspect. First, the "low investment" editors frequently have higher density of information in the UI elements that correspond to our mode-line and fringe, margins, etc. Largely thanks to their technical capabilities (various-sized fonts, graphics, being able to fit different kinds of indicators together on a "fringe"). So it appears at least in this area Emacs has been overtaken purely on technical grounds. Regarding the key combinations and the minibuffer, there is no hard evidence that our current behavior is supremely optimal. In fact, I'm fairly sure that by being risk-averse and resistant to change, and by having no UX experts around, Emacs loses out on some possible advancements in usability. Even expert-friendly ones. So I would recommend not becoming complacent, or becoming assured that workflows you have spent some time getting accustomed to, can't be improved. > I could go on. I've taught many newcomers to Emacs, and often the things that are hardest for them are exactly the things that are*good* for the experienced user. > > These design tradeoffs cannot be avoided. It would be a fallacy to think that it's always possible to be*both* maximally newcomer-friendly and investor-friendly. The last sentence is sensible, but it's generally beside the point: I'm sure we still have a long way to go in both directions. And unfortunately, in practice around here "prioritizing invested users" somehow turns out to mean "let's not make existing users uncomfortable". By changing defaults, introducing new workflows, or changing old ones. Which, in the long run, serves neither crowd.