Re: "Why is emacs so square?"

Re: "Why is emacs so square?"

[Jeff Norden]

Copied below is what I've posted to lwn.net in response to the article "Making
Emacs popular again" (https://lwn.net/Articles/819452/) about this thread.
Some of it, particularly the last part, is in response to that article rather
than anything that anyone has or would say on the emacs-devel list.
------------------------------
I'm late to this party, but as a longtime user of Gnu emacs, I feel obligated
to weigh in.  I've been using emacs on an almost daily basis for 30+ years.  I
use rmail for about 90% of my email.  I use a customized version of TeX mode
for composing documents, which include exams/quizzes/handout for the classes I
teach, research-related work, as well as mundane letters, memos, notes, etc.
I use emacs for all of the software that I write and/or dabble with, mostly
Perl and C.  I use shell-mode about as often as I use a terminal window
(currently mate-terminal, a fork of the pre-gnome-3 gnome-terminal).

To start with, the idea that emacs "needs" to have more users to prevent it
from becoming "extinct" is basically absurd.  Free software, by its very
nature, *can't* become extinct.  Even if current trends/fads mean that there
is a lull in the number of people using Gnu emacs today, the source code will
still be available for future generations to discover and use.  It's about
like saying that we must find a way to make the "Early New English" language
of the 17th century more appealing and widely spoken in order to prevent the
works of Shakespeare from becoming extinct.  Even if, for some reason, people
stopped reading and producing Shakespeare's plays for a number of years, they
would undoubtedly be re-discovered and become popular again.

This all seems to be part of the current insane attitude that software, and
technology in general, is some sort of perishable commodity with the shelf
life of milk.  Somehow, if it isn't updated every month or so, it just isn't
any good any more, even though it still does what it used to and your needs
for it haven't changed.

Emacs has never been an editor for "casual" user.  It doesn't compete with
notepad, any of the various "office" editors (open source or not), or even
vi/vim.  Gnu emacs is for people that want an extensible editor that gives
them complete control over how it operates, and can be easily and freely
customized to accomplish any sort of task that they want it to.  This sort of
freedom comes with a price - you need to invest some time and effort in order
to learn how to use it effectively.  But for many of us, it is an effort that
has been more than worthwhile.

In my opinion, it would be incredibly counterproductive to try to attract
people who don't need the functionality that emacs provides, or who aren't
willing to put forth the effort required to learn how to effectively use that
functionality.  I believe this means that any person who's decision on whether
or not to use an editor is swayed by the appearance of buttons or rounded
corners is someone who should *not* be encouraged to start using emacs.  If
you are not attracted to emacs by the features it provides and the tasks it
can accomplish, then please find an editor that will better suit your needs.

On the other hand, if someone wants to add such features for their own
benefit, perhaps because they feel it will enhance their own aesthetic
experience while using emacs, then by all means do so.  That is the whole
point of free software, after all.  But adding these in an attempt to attract
more users is a bad idea.

My *fear* is that a major effort to increase the "user base" will lead to the
transformation of emacs into something that doesn't serve anybody's needs very
well.  This is happening in many open source projects, where all sorts of
functionality has been deprecated and then removed because of the perception
that it isn't needed or being used by a large enough fraction of users.  The
recent loss of malloc_get_state() and malloc_set_state() are examples that are
particularly relevant to emacs.

Even in emacs, I personally found it a bit annoying to type "M-x count lines
region" only to be told in the mini-buffer that:
  ‘count-lines-region’ is obsolete; use ‘count-words-region’ instead.
But this was easily fixed by adding a single line to my .emacs file.  However,
if large blocks of code start disappearing from the source, or changes are
made that render existing elisp files unusable, then emacs really will run the
risk of becoming extinct.

For example, a package of elisp functions that I wrote 30 years ago for
emacs-18, which I use to record and average student grades, still works just
fine with emacs-26.  TeX is the only other software that I know of with this
level of stability.  It seems that there are very few people today who, like
Knuth and Stallman, take a long-term view of what they are trying to
accomplish.  I could go on along these lines, but this is probably sufficient.

----

However, I feel that I must respond directly to some of the comments about RMS
that have been made, along the lines of "emacs would be better without him" or
his "signature tantrums."  I'll respond in a way that RMS never would, because
he is far too polite:

   Do you have any idea who the f*** you are talking about!!?

When Richard founded the FSF, which basically started the free software
movement, people tried to write him off as some sort of extremest nutcase.
"Nobody will write software and just give it away" was a common criticism.
Well, history has shown that Stallman was correct, and his critics were the
nutcases.  It's quite possible that there would be almost no free software, no
linux or lwn.net, no gitlab/github, etc, etc, if it had not been for his
unfailing efforts and unwavering belief in free software though the years.  My
own opinion is that, if anything, Richard's opinions and views are a bit too
mild and conservative.

The arrogance of youth is natural.  I was certainly guilty of it when I was
young.  But there is no excuse for disrespecting the people who basically
built the universe that you currently enjoy inhabiting.

-Jeff

Re: "Why is emacs so square?"

[Dmitry Gutov]

On 26.05.2020 20:09, Jeff Norden wrote:
> This all seems to be part of the current insane attitude that software, and
> technology in general, is some sort of perishable commodity with the shelf
> life of milk.  Somehow, if it isn't updated every month or so, it just isn't
> any good any more, even though it still does what it used to and your needs
> for it haven't changed.

By that logic, you shouldn't worry too much about what happens to its 
development either: after all, you could continue to use one of the 
versions already released for 10 or 20 or however more years.

Re: "Why is emacs so square?"

[Arthur Miller]

Jeff Norden <jnorden@math.tntech.edu> writes:

Interesting read, but there are some fallacies, or maybe not a fallacies
but implicit assumptions that maybe are not justified:


>   Free software, by its very
> nature, *can't* become extinct.  Even if current trends/fads mean that there
> is a lull in the number of people using Gnu emacs today, the source code will
> still be available for future generations to discover and use.  It's about
> like saying that we must find a way to make the "Early New English" language
> of the 17th century more appealing and widely spoken in order to prevent the
> works of Shakespeare from becoming extinct.  Even if, for some reason, people
> stopped reading and producing Shakespeare's plays for a number of years, they
> would undoubtedly be re-discovered and become popular again.
Njah, but software is not a literar work. I don't think that people are
even reading Shakespeare with same enthusiasm and appreciation as they
did back in his own time. I don't think they appreciate him less today,
but they probably appreciate him in a different way. I don't think this
analogy works for software though, since software is written to be used,
practially.

> This all seems to be part of the current insane attitude that software, and
> technology in general, is some sort of perishable commodity with the shelf
> life of milk.  Somehow, if it isn't updated every month or so, it just isn't
> any good any more, even though it still does what it used to and your needs
> for it haven't changed.
As a continuation of above, the software is not written to be just
appreciated.

If it ain't developed it will stop to work when the machine it works on
stops to exist, or the OS, or the ABIs changes etc. So to be continually
used software has to be continually updated as the system below it
updates. If we got stabile systems that will continues to work unchanged
then maybe the above would hold. I don't think though that current
hardware/OS/lib eco system is there yet. Also software is hard to write
have I heard somewhere and there will be bugs. Butgs needs to be fixed!
A bug fix means update. As we use software more and discover and fix
more bugs, updates will be needed. One can maybe stop adding features,
sure, but somehow people come with more desires and feature requests all
the time, so yet again, more updates, more bugs, more updates ... ehh. I
don't know, I don't see really analogy with literal work here. Evergreen
software has developed as an answer to certain human patterns, it ain't
come out from thin air, so I don't think it is really insane attitude as
the professor, with all the respect, writes.

> Emacs has never been an editor for "casual" user.  It doesn't compete with
> notepad, any of the various "office" editors (open source or not), or even
> vi/vim.  Gnu emacs is for people that want an extensible editor that gives
> them complete control over how it operates, and can be easily and freely
> customized to accomplish any sort of task that they want it to.
Sure, but what says that one does have to exclude the other?

> This sort of
> freedom comes with a price - you need to invest some time and effort in order
> to learn how to use it effectively.  But for many of us, it is an effort that
> has been more than worthwhile.
Why? What says price is mandated? Why can't easy things be easy,
no-effort, and complicated things left for people who wish to dive in? I
feel there is some prejudice and assumption there simply based on how
computer usage looks today. But what says things have to be as they are?
Can't we change the world? :-)

> In my opinion, it would be incredibly counterproductive to try to attract
> people who don't need the functionality that emacs provides, or who aren't
> willing to put forth the effort required to learn how to effectively use that
> functionality.  I believe this means that any person who's decision on whether
> or not to use an editor is swayed by the appearance of buttons or rounded
> corners is someone who should *not* be encouraged to start using emacs.  If
> you are not attracted to emacs by the features it provides and the tasks it
> can accomplish, then please find an editor that will better suit your needs.
I think rounded buttons were more of a joke, but anyway, I don't
understand why it would be counterproductive to attract people who are
not willing to become finger octopusses just to use Emacs? More people
means more eyes, more usage scenarios, more bugs descovered, more users
becomming with time power users, more functionality added, better
software in the long term and maybe more momentum to free world. I don't
understand how someone can see bigger grass roots as a diminutive. 

> Even in emacs, I personally found it a bit annoying to type "M-x count lines
> region" only to be told in the mini-buffer that:
>   ‘count-lines-region’ is obsolete; use ‘count-words-region’ instead.
> But this was easily fixed by adding a single line to my .emacs file.
Poor you, I really feel your pain.

> However,
> if large blocks of code start disappearing from the source, or changes are
> made that render existing elisp files unusable, then emacs really will run the
> risk of becoming extinct.
Why would large blocks of code disappear? Nobody said Emacs should go
rewritten from scratch, stuff should get thrown away etc.

> For example, a package of elisp functions that I wrote 30 years ago for
> emacs-18, which I use to record and average student grades, still works just
> fine with emacs-26.  TeX is the only other software that I know of with this
> level of stability.  It seems that there are very few people today who, like
> Knuth and Stallman, take a long-term view of what they are trying to
> accomplish.  I could go on along these lines, but this is probably sufficient.
I don't know, I think we have never before had so many textbooks on how
to design and write software, especially libraries and APIs so they are
easy to change and modify withouth affecting existing adopters? Isn't
entire OOP an answer to that? Are you really sure there are so few
people today who takes long term stability that lightly? 

> ----
>
> However, I feel that I must respond directly to some of the comments about RMS
> that have been made, along the lines of "emacs would be better without him" or
> his "signature tantrums."  I'll respond in a way that RMS never would, because
> he is far too polite:
>
>    Do you have any idea who the f*** you are talking about!!?
>
> When Richard founded the FSF, which basically started the free software
> movement, people tried to write him off as some sort of extremest nutcase.
> "Nobody will write software and just give it away" was a common criticism.
> Well, history has shown that Stallman was correct, and his critics were the
> nutcases.  It's quite possible that there would be almost no free software, no
> linux or lwn.net, no gitlab/github, etc, etc, if it had not been for his
> unfailing efforts and unwavering belief in free software though the years.  My
> own opinion is that, if anything, Richard's opinions and views are a bit too
> mild and conservative.
>
> The arrogance of youth is natural.  I was certainly guilty of it when I was
> young.  But there is no excuse for disrespecting the people who basically
> built the universe that you currently enjoy inhabiting.
>
> -Jeff
I completely agree here. I don't know though if it is relevant, since
making Emacs more of a in-time player in 21st century is by no mean a
dissrespect to RMS or anyone else.

Re: "Why is emacs so square?"

[Jeff Norden]

This is a follow-up to may post from May, plus a concrete suggestion.

Of course, my Shakespere analogy was a bit tongue-in-cheek.  But software
and literature are both artistic human activities, and have more
similarities than you might think.  This would be more apparent if Knuth's
concept of Literate Programming were used more widely.

Of course, software *must* be updated regularly.  But I still contend that
the current pace borders on insanity.  Updates often seem to be done merely
to satisfy some current "ui" or "ux" trends.  In other projects, including
GPL ones, this has resulted in removing functionality and stripping out
large swaths of source code.  I would hate to see that happen to emacs.
There is a Doonsbury cartoon that I like, even though it refers to the most
un-free software platform in existence:
  https://www.gocomics.com/doonesbury/2014/03/16

I think the risk of emacs becoming extinct because of a lack of users is
overblown.  But, I probably overstepped in arguing for some sort of elitist
attitude.  I still think it would be counterproductive to concentrate on
superficial changes, like button shapes, just to attract more "warm
bodies."  On the other hand, anything that makes it easier for a person to
reach the point where they say:

   Hey, I never realized that you could do *that* with an editor!

is absolutely worth pursuing.  This would, hopefully, help convince them of
the value of not just emacs, but free software more generally.

----------
In this last regard, it occurs to me that a small defun from my personal
dot-emacs might help.  Everyone starting out with emacs eventually finds
themselves in some sort of state that they need to get out of.  Often a
recursive edit, sometimes several level deep.  I've never been a big fan of
ESC ESC ESC. For a while, I got in the habit of typing "M-X top-level" a
lot.  Then I added the following to my dot-emacs, and have been quite happy
with it:

    (defun keyboard-quit-strong ()
      "Run `keyboard-quit' to return emacs to a more responsive state.
    If repeated twice in a row, run `top-level' instead, to also exit
    any recursive editing levels."
      (interactive)
      (when (eq last-command 'keyboard-quit-strong)
	(setq this-command 'top-level) ;dis-arm a 3rd C-g
	(ding)
	(top-level))
      ;; Not reached after `top-level'. (A rare behavior in lisp.)
      (keyboard-quit))

    (global-set-key "\C-g" 'keyboard-quit-strong)

Here are my reasons for preferring this over ESC ESC ESC:

1) Everyone using emacs has to learn C-g, since it is the only way to
interrupt the interpreter.  One less thing to remember is always good.

2) If you manage to get yourself 10-levels deep in recursive edits somehow,
ESC ESC ESC ESC... is pretty tedious, since it only exits one level for each
three ESC's.

3) When the first ESC ESC ESC doesn't work for some reason, and you try more,
it's easy to lose count and wind up with an extra ESC.  You might type another
key before 'ESC-' appears in the echo area, with some unintended (albeit
usually benign) consequence.

4) Some of the ESC ESC ESC actions, especially delete-other-windows, seem
unexpected to me.  Isn't it more confusing, rather than helpful, to have the
window configuration you've carefully set up suddenly disappear?  I suppose it
might make sense after *Help* pops up, unless you've moved the point into the
*Help* buffer.  It seems to me that 'C-x 1' and 'C-x 2' are bindings that just
about everyone learns early on anyway, but I could be wrong.

A few other points:

If you repeatedly type C-g, the echo area toggles between "Quit" and
"Back to top level."  This nicely indicates what is going on.

If emacs is stuck in the interpreter, it takes at least three C-g's, to get
top-level to run.  Despite this, I have yet to break the 'G' key on any of my
keyboards, no matter how frustrated I've gotten :-).

I don't think I have ever accidentally exited from a recursive edit that I
wanted to keep using, such as a backtrace, by unintentionally typing C-g too
many times.  But this it is something to be considered.  On the other hand,
I've recently used this binding *a lot* along with debug-on-entry.

----------
Hope this helps, and that anyone reading this is healthy and staying safe.

-Jeff Norden

Re: "Why is emacs so square?"

[Jeff Norden]

Oops, that first line should read "...my post from May,"
Also, it looks like the list-archive software didn't pick this up as
continuing that thread, so here is a link:
  https://lists.gnu.org/archive/html/emacs-devel/2020-05/msg03191.html

-Jeff

longtime user of emacs (was: "Why is emacs so square?")

[andres.ramirez]

Hi. Jeff.
>>>>> "Jeff" == Jeff Norden <jnorden@math.tntech.edu> writes:

    Jeff> Oops, that first line should read "...my post from May," Also, it looks like the
    Jeff> list-archive software didn't pick this up as continuing that thread, so here is a link:
    Jeff> https://lists.gnu.org/archive/html/emacs-devel/2020-05/msg03191.html

Thanks for pointing to the link. I have lost the idea about what You were
talking about. I started with emacs22. But I have run recently emacs20.

This is just a curious question.
How many years an  emacs user needs for being considered a longtime
emacs user?.

Other questions.
Do You think vanilla emacs has good defaults?
If your answer to the previous question is "No". What would You change on
vanilla emacs defaults?

BTW. I agree with this:
--8<---------------cut here---------------start------------->8---
There is no excuse for disrespecting  people.
--8<---------------cut here---------------end--------------->8---

I use rmail for reading mbox files. gnus when reading debbugs (bug
reports). wanderlust for reading email and message-mode for composing
this email.

Best Regards

Re: longtime user of emacs

[Po Lu]

andres.ramirez <rrandresf@gmail.com> writes:

> This is just a curious question.  How many years an emacs user needs
> for being considered a longtime emacs user?.

I don't think there ever was a standard for this, so we shouldn't really
compare people based on how 'long' they have used Emacs for.

> Other questions.  Do You think vanilla emacs has good defaults?  If
> your answer to the previous question is "No". What would You change on
> vanilla emacs defaults?

I think the Emacs defaults are reasonable.  They might not be good, but
they have stood the test of time for nearly 4 (!) decades, and it
probably isn't a very good idea to change them.

There have been various platforms over the past 4 decades, most with
very different user interface 'standards' and trends.  Emacs in one form
or the other has run on all of them, and has run in a consistent way.
I don't believe it's a very good idea to change that.

Also, here's some anecdotal experience:
Modern software changing every once in a while to fullfill trends is one
of the reasons many users use Emacs.  If Emacs starts changing to
fullfill the latest UI trends, I'm reasonably sure many people would leave.

Re: longtime user of emacs (was: "Why is emacs so square?")

[Jeff Norden]

> Do You think vanilla emacs has good defaults?  If your answer to the
> previous question is "No". What would You change on vanilla emacs
> defaults?

I agree with Po Lu that the defaults are reasonable and should certainly
not be changed lightly.  I'll go further and say that, since emacs is
designed at its core to be customizable and extensible, the "vanilla
defaults" are far less critical than they would otherwise be.  Everyone
has their own preferences.  But it's easy to change any that differ from
the defaults.  If I'm using a "vanilla" emacs, I usually change scroll-step
(or -conservatively), but this just takes a moment.  And, if I can't
recall the variable name, I just do M-x set-variable scroll- [TAB], and
there they are.

So, I probably wouldn't argue for having the keyboard-quit-strong that I
posted above become a replacement for keyboard-quit.  Instead, if folks
think it is a worthwhile idea, maybe a customizable variable could
control the default behavior of C-g.  Then it just becomes the
relatively minor question of what the default value should be for this
variable.

-Jeff

Re: longtime user of emacs (was: "Why is emacs so square?")

[Ihor Radchenko]

> I agree with Po Lu that the defaults are reasonable and should certainly
> not be changed lightly.  I'll go further and say that, since emacs is
> designed at its core to be customizable and extensible, the "vanilla
> defaults" are far less critical than they would otherwise be.  Everyone
> has their own preferences.  But it's easy to change any that differ from
> the defaults.  If I'm using a "vanilla" emacs, I usually change scroll-step
> (or -conservatively), but this just takes a moment.  And, if I can't
> recall the variable name, I just do M-x set-variable scroll- [TAB], and
> there they are.

While I agree that the existing Emacs defaults are reasonable in
general, I do not think that they are good for users coming from an
arbitrary background.

Emacs is a very versatile tool and can be used for programming, creative
writing, research, note-taking, todo management, and many more different
fields. I do not think that a single set of defaults can satisfy users
aiming for every single use-case. Moreover, changes required to tweak
Emacs towards a specific use-case are often much more than "just takes a
moment". No surprise that we have a whole spectrum of Emacs startup kits,
which offer predefined set of tweaks for different styles of using
Emacs.

I do think that the existing Emacs defaults are a good starting point
for a new user with unknown workflows. They are generic enough to tweak
Emacs in any possible direction. However, I believe that it would be a
good option to have several sets of defaults, which would better fit
some common use-cases, like programming, note-taking, tramp, git, etc.
Then, the existing defaults will represent "Generic" use-case, but a new
user (who may or may not have programming background) might easily
select other set of defaults, which is more suitable for the user's
background and expected use-cases.

Best,
Ihor

Jeff Norden <jnorden@tntech.edu> writes:

>> Do You think vanilla emacs has good defaults?  If your answer to the
>> previous question is "No". What would You change on vanilla emacs
>> defaults?
>
> I agree with Po Lu that the defaults are reasonable and should certainly
> not be changed lightly.  I'll go further and say that, since emacs is
> designed at its core to be customizable and extensible, the "vanilla
> defaults" are far less critical than they would otherwise be.  Everyone
> has their own preferences.  But it's easy to change any that differ from
> the defaults.  If I'm using a "vanilla" emacs, I usually change scroll-step
> (or -conservatively), but this just takes a moment.  And, if I can't
> recall the variable name, I just do M-x set-variable scroll- [TAB], and
> there they are.
>
> So, I probably wouldn't argue for having the keyboard-quit-strong that I
> posted above become a replacement for keyboard-quit.  Instead, if folks
> think it is a worthwhile idea, maybe a customizable variable could
> control the default behavior of C-g.  Then it just becomes the
> relatively minor question of what the default value should be for this
> variable.
>
> -Jeff
>

-- 
Ihor Radchenko,
PhD,
Center for Advancing Materials Performance from the Nanoscale (CAMP-nano)
State Key Laboratory for Mechanical Behavior of Materials, Xi'an Jiaotong University, Xi'an, China
Email: yantar92@gmail.com, ihor_radchenko@alumni.sutd.edu.sg

Re: longtime user of emacs (was: "Why is emacs so square?")

[andrés ramírez]

Hi. Jeff.

>>>>> "Jeff" == Jeff Norden <jnorden@tntech.edu> writes:


[...]

    Jeff> If I'm using a "vanilla" emacs, I usually change scroll-step
    Jeff> (or -conservatively), but this just takes a moment.  And, if I can't recall the variable
    Jeff> name, I just do M-x set-variable scroll- [TAB], and there they are.

I tend to use vanilla emacs once per month (not regularly). One of the
things I would change would be:
--8<---------------cut here---------------start------------->8---
(defalias 'yes-or-no-p 'y-or-n-p)
--8<---------------cut here---------------end--------------->8---

The idea, is not changing it. For me It is just mentioning some things ouf of
our experience as emacs users who from time to time experience|use
vanilla-emacs. Perhaps another person who use vanilla-emacs would say
'+1' to one of our suggestions (who knows).


Best Regards

Re: longtime user of emacs

[Po Lu]

Ihor Radchenko <yantar92@gmail.com> writes:

> I do think that the existing Emacs defaults are a good starting point
> for a new user with unknown workflows. They are generic enough to tweak
> Emacs in any possible direction. However, I believe that it would be a
> good option to have several sets of defaults, which would better fit
> some common use-cases, like programming, note-taking, tramp, git, etc.
> Then, the existing defaults will represent "Generic" use-case, but a new
> user (who may or may not have programming background) might easily
> select other set of defaults, which is more suitable for the user's
> background and expected use-cases.

I think this solution was proposed by a few people a few months back,
when this discussion started.  It would be nice if people came up with
an idea as to how exactly this functionality is to be implemented, and a
set of better usecases than just 'programming' or 'note-taking' or
'TRAMP' or 'git'.

P.S: Please don't suggest things like `use-git-mode' or
`use-tramp-mode'. That kind of thinking doesn't work out.

Re: longtime user of emacs

[Ihor Radchenko]

> I think this solution was proposed by a few people a few months back,
> when this discussion started.  

Could you point me to relevant thread? I lost track of that discussion
at some point.

> It would be nice if people came up with
> an idea as to how exactly this functionality is to be implemented, 
> and a
> set of better usecases than just 'programming' or 'note-taking' or
> 'TRAMP' or 'git'.

As one possibility, we can try to extend "A guided tour to Emacs" and
make it more interactive.

Some thoughts:
1. The link to the tour in the welcome page is not easy to spot for a
new user. There is too much information. I might be better to show it by
default on first startup after installation.
2. Currently, the tour is one long web-page, which is not very easy to
read. I imagine that a presentation-like style (with prev/next buttons
on each page) showing one concept at a time would be easier to read.
3. The tour may as well include interactive customisation. For example,
'Migrating to Emacs' part of the tour may as well contain a clickable
element to turn on CUA mode by default.
4. The tour might ask user questions if the user is going to work with
source code, email, web-browsing, shell, etc. If the user is not
planning to work with certain things, they may as well be hidden from
menu and customisation pages. By hidden I don't mean completely hidden,
but rather "folded" - the user should be able to show them back.
For a newcomer, Emacs offers very too many different options. I believe
that it makes more sense to restrict the customisation and menus to what
user explicitly plans to do. It should be already more than enough to
start learning.
5. Similar guided tours may be created for most popular Emacs features:
   - working with source code
   - org-mode
   - version-control and collaboration
   - remote file access
   - mail
   Those tours might also offer some initial customisation, so that the
   user may disable/enable some features which are not relevant to
   his/her workflow.
   The guides should be easily accessible from menu.
6. Some new users might be confused by default file open dialogie
involving mode-line. I believe that similarly to CUA-mode, Emacs can
emulate more standard approach by offering dired as a way to open files
(not enabled by default, but offered as a customisation together with
CUA-mode).

Best,
Ihor

Po Lu <luangruo@yahoo.com> writes:

> Ihor Radchenko <yantar92@gmail.com> writes:
>
>> I do think that the existing Emacs defaults are a good starting point
>> for a new user with unknown workflows. They are generic enough to tweak
>> Emacs in any possible direction. However, I believe that it would be a
>> good option to have several sets of defaults, which would better fit
>> some common use-cases, like programming, note-taking, tramp, git, etc.
>> Then, the existing defaults will represent "Generic" use-case, but a new
>> user (who may or may not have programming background) might easily
>> select other set of defaults, which is more suitable for the user's
>> background and expected use-cases.
>
> I think this solution was proposed by a few people a few months back,
> when this discussion started.  It would be nice if people came up with
> an idea as to how exactly this functionality is to be implemented, and a
> set of better usecases than just 'programming' or 'note-taking' or
> 'TRAMP' or 'git'.
>
> P.S: Please don't suggest things like `use-git-mode' or
> `use-tramp-mode'. That kind of thinking doesn't work out.

-- 
Ihor Radchenko,
PhD,
Center for Advancing Materials Performance from the Nanoscale (CAMP-nano)
State Key Laboratory for Mechanical Behavior of Materials, Xi'an Jiaotong University, Xi'an, China
Email: yantar92@gmail.com, ihor_radchenko@alumni.sutd.edu.sg

Re: longtime user of emacs

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@gmail.com>
> Date: Wed, 15 Jul 2020 15:10:34 +0800
> Cc: "andres.ramirez" <rrandresf@gmail.com>, Jeff Norden <jnorden@tntech.edu>,
>  emacs-devel@gnu.org
> 
> Some thoughts:
> 1. The link to the tour in the welcome page is not easy to spot for a
> new user. There is too much information. I might be better to show it by
> default on first startup after installation.
> 2. Currently, the tour is one long web-page, which is not very easy to
> read. I imagine that a presentation-like style (with prev/next buttons
> on each page) showing one concept at a time would be easier to read.
> 3. The tour may as well include interactive customisation. For example,
> 'Migrating to Emacs' part of the tour may as well contain a clickable
> element to turn on CUA mode by default.
> 4. The tour might ask user questions if the user is going to work with
> source code, email, web-browsing, shell, etc. If the user is not
> planning to work with certain things, they may as well be hidden from
> menu and customisation pages. By hidden I don't mean completely hidden,
> but rather "folded" - the user should be able to show them back.
> For a newcomer, Emacs offers very too many different options. I believe
> that it makes more sense to restrict the customisation and menus to what
> user explicitly plans to do. It should be already more than enough to
> start learning.
> 5. Similar guided tours may be created for most popular Emacs features:
>    - working with source code
>    - org-mode
>    - version-control and collaboration
>    - remote file access
>    - mail
>    Those tours might also offer some initial customisation, so that the
>    user may disable/enable some features which are not relevant to
>    his/her workflow.
>    The guides should be easily accessible from menu.
> 6. Some new users might be confused by default file open dialogie
> involving mode-line. I believe that similarly to CUA-mode, Emacs can
> emulate more standard approach by offering dired as a way to open files
> (not enabled by default, but offered as a customisation together with
> CUA-mode).

Thank you for writing this.  I would encourage interested people to
work on some of these ideas.