From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: TEC Newsgroups: gmane.emacs.devel Subject: Re: Changes for emacs 28 Date: Thu, 10 Sep 2020 00:45:18 +0800 Message-ID: <87h7s6c31d.fsf@gmail.com> References: <87y2lkb6kb.fsf@gmail.com> <9A4FA038-CCFD-45DF-8B57-E348AFF951D9@gmail.com> <87sgbsb0eb.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="1202"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: mu4e 1.4.13; emacs 27.1 Cc: Gregory Heytings , Yuan Fu , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Sep 09 18:46:04 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 1kG3ER-00007H-I5 for ged-emacs-devel@m.gmane-mx.org; Wed, 09 Sep 2020 18:46:03 +0200 Original-Received: from localhost ([::1]:55356 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kG3EQ-0000zc-DS for ged-emacs-devel@m.gmane-mx.org; Wed, 09 Sep 2020 12:46:02 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:33812) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kG3Ds-0000Sg-3X for emacs-devel@gnu.org; Wed, 09 Sep 2020 12:45:28 -0400 Original-Received: from mail-pf1-x433.google.com ([2607:f8b0:4864:20::433]:39325) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kG3Do-0002px-Hu for emacs-devel@gnu.org; Wed, 09 Sep 2020 12:45:27 -0400 Original-Received: by mail-pf1-x433.google.com with SMTP id n14so2657404pff.6 for ; Wed, 09 Sep 2020 09:45:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=references:user-agent:from:to:cc:subject:in-reply-to:message-id :date:mime-version:content-transfer-encoding; bh=wllIkLeGZmNOQ8qgKCD+4wSZSaiynMp8+kjYYiD+FkI=; b=LBmrjRsb1eCDskSFMfIlyMfjz6Y1/+QO2Hh76DGiIt39SVl8uvp3dvP5Aabmzj/mFC gQXWchcuiKn2ZOOLW0GT0133WbDbGg9uL/xHzqw76XiOohD9xS5fSol5NRfP/Bsmxbk1 7OsG7znJ2QDM5xlvwwHdUoswwPRZ4WbRfRhas7EPwjNYFzPXEdpeTxwknGT7IJTEkMeq vG/CJlAc+IS+kBt0uEvCAys3Wyd9Vxqng8lT1NLYWFURY2Rtx1fKdHoXF5z8QjT64qh6 wmMJV369pTP53qxTCblu5WdZZg7GCnkkYfMZaUaK/qF5qXXEZifVhtvLHuHh5EToaR/N xk3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:references:user-agent:from:to:cc:subject :in-reply-to:message-id:date:mime-version:content-transfer-encoding; bh=wllIkLeGZmNOQ8qgKCD+4wSZSaiynMp8+kjYYiD+FkI=; b=iGt/vBjwoy01ejCm2+iljTV/16X5hJ6WuPTFVNyAMBbPwmijakUvEt31VOsuGlylv/ KLxUrKKWlUjQhT7AEX2QpHLglFK0Er7G4qkr2ZZ+8cX77IN6dgtm/OBUS5vrRwDGyK3v FKkGCSj+9BXvqNT8Um85nrOMC+ENgGYlpyxxliFNPm9wRRzN6mcrP7Ta9BcP2if7TCjH AdWRuiOgMMj6c9PFEHIWcPunJ3dQ5Cbu64/U+Xcg+A5mc8VliBgHJ1yFqfnmcu58TrF4 XmG+9QzNgctQwPJ2czTPMkdFfQjof5bmFm47DFcsecHR8YTzgE/Sw4cA5E9k7SUxFFYK 6KSw== X-Gm-Message-State: AOAM530/XMsiwACjSowoawTqtZqa2J0V00Dv8rEt5gx38kIYYCyK5xTg Kpqlc2lwmzX1cvzP3LsQSdo= X-Google-Smtp-Source: ABdhPJwszMRB+Ijc52F8cmV2k/p/dMGhBXjkOT9SJvnaL37bLmgFDCnjm5uYkoUmiYLvfjJCEt1aOw== X-Received: by 2002:a17:902:d201:b029:d0:cbe1:e73e with SMTP id t1-20020a170902d201b02900d0cbe1e73emr1811486ply.25.1599669922930; Wed, 09 Sep 2020 09:45:22 -0700 (PDT) Original-Received: from localhost (180-150-91-8.b4965b.per.nbn.aussiebb.net. [180.150.91.8]) by smtp.gmail.com with ESMTPSA id h35sm2812764pgl.31.2020.09.09.09.45.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 09 Sep 2020 09:45:22 -0700 (PDT) In-reply-to: Received-SPF: pass client-ip=2607:f8b0:4864:20::433; envelope-from=tecosaur@gmail.com; helo=mail-pf1-x433.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: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no 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:254907 Archived-At: Stefan Monnier writes: > Thanks, TEC, I found it quite useful. Further comments and questions bel= ow. Happy to (try) to help. I'll see if I can elaborate on your points/queries :) >> - Oh, this looks old. > > Fair enough. I don't think we (Emacs community) are in a position to > make it look "modern" and sexy. I know I'm not because my notion of > "modern and sexy" is quite outmoded ;-) > > But "looks old" is usually not a deal breaker, just a negative > first impression. This is a tricky thing. You see, I don't think it's inherently bad. However, for me at least, most of the editors I've used have had a good degree of 'visual polish' and 'modern snazziness' that Vanilla Emacs currently lacks. The editors I've used which haven't are - IDLE - Nano - BlueJ (for all of 30 seconts) All of which I ended up finding quite lacking. So the 'issue' here isn't a direct "this doesn't look good so I won't use this" but a case of association. When I see the vanilla Emacs splash screen I'm reminded of the *worst* editors I have experienced, which is (as we both know) completely inaccurate, but first impressions are coloured by a myriad of factors. Vim of course also lacks a splash screen, but it's also known as a terminal-exclusive editor. I know I tend to set different expectations TUIs and GUIs, so I'd imagine I'd find this less of a subconscious red-flag. >> - Successfully opened a file >> + Where are the line numbers? > > Interesting. It would never occur to me to expect line numbers in > a text editor. When and why did line numbers become fashionable? > [ My guess is something like "ever since shortscreens became the only > option, creating a void in the horizontal space that needed > filling" ;-) ] > > I don't oppose enabling line numbers by default, but I do find line > numbers to be an awful waste of valuable screen real estate. This really is quite minor, and not something to get hung up about in my opinion. This was more a surprise than anything else, having just been made used to line numbers by my previous editors. >> + Why aren't I given much information on the file > > Could you be more specific in terms of the particular information that > you felt Emacs failed to give (and maybe how you expected it to be given)? It's almost got all the main attributes, just an issue of clarity and expected functionality not coming with vanilla Emacs. - Unsaved changes, I see this is now present but the you have to know what you're looking for somewhat - linter checks/status (of course, I now know this is because there is no linter by default) >> + Where's the completion, the linting, etc. > > Do I understand you right that you expected company+eglot+flymake to be > enabled (and configured) by default? > > I personally find this to be the most glaring concrete problem in > Emacs nowadays. Yep. This is the main item, no doubt in my mind. Not having /any/ completion or linting was a bit of a shock. >> - Tried to execute a command interactively (forget which command) >> + Typed M-x >> + Wait, this is just a text box >> + I don't know commands off by heart! >> + I want to be able to type key terms and see options! > > How much of this would be satisfied by icomplete-mode together with the > `substring` completion-style (which would be a smaller change to > the UI than something like helm-M-x or counsel-M-x). I'm frankly not sure. Just trying icomplete now for the first time the horizontal display of options seems a bit odd to my sensibilities. >> - Having an initialisation=E2=80=A0 file, well commented such that *with= out knowing >> anything about Emacs* I could have Emacs be set up such that I could >> actually try it with familiar tasks and not be underwhelmed, or have >> to deal with sudden troubleshooting > > Maybe we could have a "default init file" (consisting of nothing but > commented out code snippets, accompanied by actual comments explaining > them)? I feel like this could be a good thing, with the most common/immediate settings described and commented out. For example, doom has this: ----- ;; Some functionality uses this to identify you, e.g. GPG configuration, em= ail ;; clients, file templates and snippets. (setq user-full-name "John Doe" user-mail-address "john@doe.com") ... ;; This determines the style of line numbers in effect. If set to `nil', li= ne ;; numbers are disabled. For relative line numbers, set this to `relative'. (setq display-line-numbers-type t) ----- >> =E2=80=A0The important bit about this file is that it let me declare w= hich >> bundles of functionality I want easily, and without having to parse >> much unfamiliar lisp (both Spacemacs and Vanilla fail in this regard, >> but in different ways). > > Hmm... a "default init file" would still use "unfamiliar Lisp", I'm afrai= d. This was mostly a comparison to spacemacs. Doom's init.el is mostly lines like this: ----- :lang ;;agda ; types of types of types of types... ;;cc ; C/C++/Obj-C madness ;;clojure ; java with a lisp ;;common-lisp ; if you've seen one lisp, you've seen them all ----- Which as a lisp-noob I didn't find intimidating. >> - Having good 'discoverability enhancements' used by default >> - counsel for M-x > > IIUC this is similar to enabling icomplete-vertical and > icomplete-show-matches-on-no-input, and maybe using a regexp > completion style? This sounds like a change I would have appreciated. >> - Used Discord for it's community, a recent chat-app which I recognised >> (I'm still warming up to mailing lists). > > Definitely a non-starter since it's proprietary. > There are obviously acceptable alternatives. Oh, I don't expect Emacs' community at large (particularly individuals like the cheif GNUsance) to switch to discord or anything like that, but a non-IRC IM platform could make asking quick newbie questions seem more appreciable. Unfortunately, I feel that a lot of youngsters (myself included) tend to /expect/ projects to: - be on github - have public forums - use popluar IM services I'm not saying Email+IRC isn't fit for purpose, it's simply not something I was used to using like this (until months after I got into Emacs). I think we can somewhat see this effect in the benefits that being on GitHub seems to have had for NeoVim, in terms of visibility and engagement. I'm not saying that Emacs should follow suit, simply that IMO this seems like a matter worthy of some consideration. > I think an important aspect is to find a communication medium that can > be used from Emacs. IRC and Email do satisfy this criteria. Indeed. Though I think that when trying to make Emacs inviting, having services that a curious user feels comfortable just jumping onto (Discord, Gitter, Slack, Discorse,...) may also have value. Feel free to follow up with more questions, I'll do my best to answer them :) Timothy.