[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Representation of the Emacs userbase on emacs-devel
From: |
Arthur Miller |
Subject: |
Re: Representation of the Emacs userbase on emacs-devel |
Date: |
Mon, 06 Sep 2021 13:26:05 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) |
Hugo Thunnissen <devel@hugot.nl> writes:
> Arthur Miller <arthur.miller@live.com> writes:
>
>> With other words, emacs devs already think that default options are sane. So
>> I
>> don't think that wording here should be "enable sane defaults", but "enable
>> different defaults". For example enable "VSCode like defaults" or enable
>> "Eclipse like defaults" or something else.
>
> Is it really different defaults that are required for users who come
> from other editors to feel accommodated? Being a younger generatio
I think that is quite personal. Evil is a big thing, and that is vim
layer. Obviously some people prefer different interaction models. I personally
have been using emacs keys for like 20 years now, so I am happy with that and
get annoyed when I press C-w to cut text in FFX and kill the tab. But we are all
different people, and different people prefer different things. That should be
OK, people should be allowed to be different. As Eli wrote in some earlier
message, Emacs can accomodate for different options quite well, so I don't see
why they wouldn't be avaiable. Viper (vi) and CUA ("contemporary"?) keybinding
are already included in Emacs. If someone else made some other emulation layer,
I don't see why would someone object to include it, provided that it meets some
quality criteria and fsf princples.
> from other editors to feel accommodated? Being a younger generation
> emacs user and coming from other editors myself, the different keybinds
> themselves weren't a problem for me.
For you maybe not, wasn't for me neither, but there are people who complain on
keybdings, terminology used etc. I myself think that terminology could be
updated to more "contemporary" as Dmitri calls it (cut/paste instead of
kill/yank).
> themselves weren't a problem for me. Finding out what they were though,
> was more of a challenge. Of course there is C-h m to find about keybinds
> in the current mode and C-h k to find out what a keybind does, but those
> are not things someone knows about right off the bat. Especially when
Indeed. Some applications have animated (scripted) gui tutorials and "newbie"
modes where things are highlighted extra to make it easier to learn the
application. Emacs does not have such things unfortunately. Also the situation
where people are shown to disable gui from the start does not make it better.
> people are my age, reading a manual about an editor before using it is
> not a common thing to do. Because of the way UI/UX is these days, we
> often expect to be guided into information. In that vain, what about
> creating a keybind sheet in similar fashion to, but less comprehensive
> than the one found here
> https://www.gnu.org/software/emacs/refcards/pdf/refcard.pdf and making
> that the startup screen for new users?
Yes, that is good idea. There are such attempts. Rougier has nice one:
https://github.com/rougier/elegant-emacs
if you haven't seen it. I have seen other attempts but don't remember
those. Which key helps a lot. I think it should be included in Emacs. Or at
least the idea. I think that has already been suggested about year or so ago.
> On another note, people coming from other editors often have some
> default settings that they want to have replicated in emacs. Things like
> tab or space indentation, tab size, dark or light theme, word wrapping
> etc. VScode and Atom store general settings like that in a config.json
> (vscode) or config.bson (atom) file that users are also allowed to
> hand-edit. Maybe emacs can provide some conversion functionality that
> lets a user paste in their config.json and tells them the equivalent
> emacs configuration values for general default settings like that. I'm
> not suggesting providing a completely similar experience to vscode, but
> just the basic configuration that most users will want to carry over
> between editors.
Emacs is good at text processing, it is just to write a converter ;-).
I think the problem here is that people who need such converter does not know
enough of elisp to write one, and by the time they learned enough elisp to write
such, they don't need it any more and don't care :).
Jokes aside, yes that could be a thing for some people.
- Re: Representation of the Emacs userbase on emacs-devel, (continued)
- Re: Representation of the Emacs userbase on emacs-devel, Dmitry Gutov, 2021/09/07
- Re: Representation of the Emacs userbase on emacs-devel, Stefan Kangas, 2021/09/07
- Re: Representation of the Emacs userbase on emacs-devel, Richard Stallman, 2021/09/08
- Re: Representation of the Emacs userbase on emacs-devel, Arthur Miller, 2021/09/07
- Re: Representation of the Emacs userbase on emacs-devel, Richard Stallman, 2021/09/07
- Re: Representation of the Emacs userbase on emacs-devel, Arthur Miller, 2021/09/08
- Re: Representation of the Emacs userbase on emacs-devel, Hugo Thunnissen, 2021/09/06
- Re: Representation of the Emacs userbase on emacs-devel,
Arthur Miller <=
- Re: Representation of the Emacs userbase on emacs-devel, Richard Stallman, 2021/09/04
- Re: Representation of the Emacs userbase on emacs-devel, Dmitry Gutov, 2021/09/06
- Re: Representation of the Emacs userbase on emacs-devel, Richard Stallman, 2021/09/07
- Re: Representation of the Emacs userbase on emacs-devel, Dmitry Gutov, 2021/09/08
- Re: Representation of the Emacs userbase on emacs-devel, Richard Stallman, 2021/09/08
- Re: Representation of the Emacs userbase on emacs-devel, Dmitry Gutov, 2021/09/09
- Re: Representation of the Emacs userbase on emacs-devel, Richard Stallman, 2021/09/11
- Re: Representation of the Emacs userbase on emacs-devel, Dmitry Gutov, 2021/09/11
- Re: Representation of the Emacs userbase on emacs-devel, Dmitry Gutov, 2021/09/27
- Re: Representation of the Emacs userbase on emacs-devel, Qiantan Hong, 2021/09/02