emacs-devel
[Top][All Lists]
Advanced

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

Re: Changes for emacs 28


From: TEC
Subject: Re: Changes for emacs 28
Date: Thu, 10 Sep 2020 00:45:18 +0800
User-agent: mu4e 1.4.13; emacs 27.1

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Thanks, TEC, I found it quite useful.  Further comments and questions below.

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† file, well commented such that *without 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, email
;; 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', line
;; numbers are disabled. For relative line numbers, set this to `relative'.
(setq display-line-numbers-type t)

-----

>>   †The important bit about this file is that it let me declare which
>>   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 afraid.

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.



reply via email to

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