Re: Changes for emacs 28

[Stefan Monnier]

>> But "looks old" is usually not a deal breaker, just a negative
>> first impression.
> This is a tricky thing.

I fully agree with you that it can be important.
All I meant is that I'll let others figure out what to do with this part
of the problem.

>>> - 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.

I'm not getting "hung up on" but I'm curious to know if it's really
something that's expected nowadays (just like a tool-bar was expected
at some point and maybe a tab-bar is expected nowadays, tho I find
both of them completely useless in Emacs for my usage pattern).

And it does make it clear that regardless if we change the default, it
should be very easy and obvious how to enable (or disable) it.

>> 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

Any hint how (else) you expected it to be shown at that point?

> - linter checks/status (of course, I now know this is because there is
>   no linter by default)

Ah, yes, that ;-)

>>>   + 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.

I'm glad we agree.

>> 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:

Right, that was the idea.  Of course, in my world, Emacs is installed by
the admin so the init file of the users initially just doesn't exist at all.
So we'd need some magic to fill it with this initial template upon first visit.

> -----
>        :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
> -----

Oh, cool, I didn't expect "agda" to be there!

> Which as a lisp-noob I didn't find intimidating.

I see.  Not sure if I'd want to go in this direction for configuration.
But for selection of packages to install, it looks fine, indeed.

> Unfortunately, I feel that a lot of youngsters (myself included) tend to
> /expect/ projects to:
>  - be on github

This is one we won't satisfy because it doesn't just mean "a github-like
model" but "on github itself", so it's incompatible with our philosophy.

But we hopefully will (sooner rather than later) move our development to
something that offers a nicer web UI for merge requests and bug reports.
This is not going very fast, tho.
[ Currently I'm personally hoping we'll move to SourceHut.  ]

>  - have public forums

Hmm... emacs-devel is definitely public.  Do you not consider it a forum?
Do you mean "web forum"?

>  - use popluar IM services

I oppose all the most popular IM services because they make money using
(y)our data, so using them would be unethical (even if we decided we were
OK with implicitly selling our data, by using such forums we'd be
forcing other people to make this choice as well).

> 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).

Yup.  So the only possible meeting point is one that is ethically
acceptable (Free Software, open protocol, non-centralized control), and
can be accessed from within Emacs as well as via more popular UIs.

Any suggestion what this could be?

> I'm not saying that Emacs should follow suit, simply that IMO this seems
> like a matter worthy of some consideration.

Indeed, but there are strong commercial forces that strive to keep the
acceptable solutions unpopular ;-(

>> 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.

Value or not, Discord and Slack are not part of the Free Software world,
so they're definitely not an option.  Gitter and Discourse are
possible, OTOH.  I haven't had an opportunity to use them from with
Emacs yet, so I don't know if the regulars of emacs-devel would find it
sufficiently palatable, but I'd be happy to try it out if someone sets
up such a service for us.


        Stefan