A proposal for a friendlier Emacs

A proposal for a friendlier Emacs

[Nicola Manca]

Dear all,

following the recent discussions about a startup wizard and modern-mode 
I try to provide a suggestion.

What about having a startup screen, opening only if no .emacs or other 
user configuration file is found just saying (the text is just an example):

Welcome!
This is the first time you run Emacs, please choose how to proceed:

[] Go Vanilla!
   (standard defaults, no customizations)

[] Start Configuration Wizard
   (set-up your .emacs configuration file interactively)

[] Try Emacs in enhanced-mode
   (run with a predefined configuration showing emacs potential)

After this screen, the normal Emacs splash screen could me presented.

This mimics what many GNU/Linux distros already do, allowing minimal 
installation, full-featured installation or Live (no-installation.

The idea is that the option number 3 also enables a first-level menu 
item allowing to select among:
- Start the configuration wizard
- How enahnced mode works? (show the corresponding .emacs so the user 
can learn how to expand it)
- whatever you like...

This would define a minor mode, as Andrea suggested, whose source code 
users may employ to start building their own .emacs.
Such minor mode would be not intended to be used normally, since it will 
be subject to change often.

This solution would prevent the problem of passing --modern to the emacs 
exacutable and, beyond that, it could also correspond to emacs -Q, since 
choosing "Vanilla" would result in a normal clean startup.

How does it sounds?

best,
Nicola

Re: A proposal for a friendlier Emacs

[Alfred M. Szmidt]

   Dear all,

   following the recent discussions about a startup wizard and modern-mode 
   I try to provide a suggestion.

I think a startup wizard balances everything, new users with
experience other editors can easily pick what they prefer in this
configuration wizard thing.  This hasn't the negative notion of
"modern", "newbie", etc.

   What about having a startup screen, opening only if no .emacs or other 
   user configuration file is found just saying (the text is just an example):

It shouldn't be super intrusive if there is no .emacs, since it is
quite common to fire up Emacs without a .emacs.

   Welcome!
   This is the first time you run Emacs, please choose how to proceed:

   [] Go Vanilla!
      (standard defaults, no customizations)

   [] Start Configuration Wizard
      (set-up your .emacs configuration file interactively)

   [] Try Emacs in enhanced-mode
      (run with a predefined configuration showing emacs potential)

   After this screen, the normal Emacs splash screen could me presented.

   This mimics what many GNU/Linux distros already do, allowing minimal 
   installation, full-featured installation or Live (no-installation.

   The idea is that the option number 3 also enables a first-level menu 
   item allowing to select among:

Any specific reason why not have those in one of the menu bars by
default instead?  this would keep the "splash" slightly simpler.

   How does it sounds?

I think this is the most sensible proposal.

Re: A proposal for a friendlier Emacs

[Nicola Manca]

On 17/09/20 11:04, Alfred M. Szmidt wrote:
>     Dear all,
> 
>     following the recent discussions about a startup wizard and modern-mode
>     I try to provide a suggestion.
> 
> I think a startup wizard balances everything, new users with
> experience other editors can easily pick what they prefer in this
> configuration wizard thing.  This hasn't the negative notion of
> "modern", "newbie", etc.

Indeed, the startup wizard could contain the "enhanced options" (I like 
the term since its quite neutral), however if we need something quick 
that work. Also, it is something new users could expect from a "first 
startup" of a software.

>     What about having a startup screen, opening only if no .emacs or other
>     user configuration file is found just saying (the text is just an example):
> 
> It shouldn't be super intrusive if there is no .emacs, since it is
> quite common to fire up Emacs without a .emacs.

I think we should find a compromise here. If an experienced user stats 
emacs without a .emacs present, he/she may disable this somehow (maybe 
with --no-splash ?)
I think we shall think to the case when someone download emacs and run 
it to try, how to identify such case?

>     Welcome!
>     This is the first time you run Emacs, please choose how to proceed:
> 
>     [] Go Vanilla!
>        (standard defaults, no customizations)
> 
>     [] Start Configuration Wizard
>        (set-up your .emacs configuration file interactively)
> 
>     [] Try Emacs in enhanced-mode
>        (run with a predefined configuration showing emacs potential)
> 
>     After this screen, the normal Emacs splash screen could me presented.
> 
>     This mimics what many GNU/Linux distros already do, allowing minimal
>     installation, full-featured installation or Live (no-installation.
> 
>     The idea is that the option number 3 also enables a first-level menu
>     item allowing to select among:
> 
> Any specific reason why not have those in one of the menu bars by
> default instead?  this would keep the "splash" slightly simpler.

Just because the idea is that this mode would be meant to show a 
configured emacs running, if you like it, you can transfer the 
configuration to your own .emacs.

>     How does it sounds?
> 
> I think this is the most sensible proposal.

thank you! :D

Re: A proposal for a friendlier Emacs

[Alfred M. Szmidt]

   > It shouldn't be super intrusive if there is no .emacs, since it is
   > quite common to fire up Emacs without a .emacs.

   I think we should find a compromise here. If an experienced user stats 
   emacs without a .emacs present, he/she may disable this somehow (maybe 
   with --no-splash ?)

I think that would be annoying -- if I log in on a new machine that
I've never used, I'm sure I wont remeber passing any special switches
to Emacs to start it.

Why not just have it on the splash screen if there is no .emacs; and
if there is a .emacs remove that blurb.  We could add one or two lines
along the lines of M-x recover-session:

   If an Emacs session crashed recently, type M-x recover-session RET
   to recover the files you were editing.

E.g., (actual wording left for someone else) if there is no .emacs, we
show:

  You do not have a personal Emacs configuration file, you can go
  [Vanilla], start the [configuration wizard], or try Emacs with a
  different theme [different-theme-mode].

And if there is, we skip it.  And have some means of getting to the
wizard from the menu-bar, maybe even a way of selecting a list of
themes there too..

This wouldn't change how Emacs behaves, but still allow new or
experienced users to fiddle.

Re: A proposal for a friendlier Emacs

[Thibaut Verron]

Le jeu. 17 sept. 2020 à 14:25, Alfred M. Szmidt <ams@gnu.org> a écrit :
>
>    > It shouldn't be super intrusive if there is no .emacs, since it is
>    > quite common to fire up Emacs without a .emacs.
>
>    I think we should find a compromise here. If an experienced user stats
>    emacs without a .emacs present, he/she may disable this somehow (maybe
>    with --no-splash ?)
>
> I think that would be annoying -- if I log in on a new machine that
> I've never used, I'm sure I wont remeber passing any special switches
> to Emacs to start it.

Is it such a big deal? In such a situation you just have to click
"make my own" if you want a -q, or the other option to get most or all
of the most common QoL variables already set, and on subsequent starts
there will be an init.el and you won't have the message anymore.

Iirc it is what Screen does, is it annoying?

> Why not just have it on the splash screen if there is no .emacs; and
> if there is a .emacs remove that blurb.  We could add one or two lines
> along the lines of M-x recover-session:

What's the difference with the original proposal?

Re: A proposal for a friendlier Emacs

[Alfred M. Szmidt]

   >    > It shouldn't be super intrusive if there is no .emacs, since it is
   >    > quite common to fire up Emacs without a .emacs.
   >
   >    I think we should find a compromise here. If an experienced user stats
   >    emacs without a .emacs present, he/she may disable this somehow (maybe
   >    with --no-splash ?)
   >
   > I think that would be annoying -- if I log in on a new machine that
   > I've never used, I'm sure I wont remeber passing any special switches
   > to Emacs to start it.

   Is it such a big deal? 

To have a different behaviour form if you have .emacs, and when you do
not? Yes, definitly -- it is fully valid to not have a .emacs file.

   In such a situation you just have to click "make my own" if you
   want a -q, or the other option to get most or all of the most
   common QoL variables already set, and on subsequent starts there
   will be an init.el and you won't have the message anymore.

-q is for "quick" -- which is a different behaviour.

   Iirc it is what Screen does, is it annoying?

I don't use screen, so no?

   > Why not just have it on the splash screen if there is no .emacs; and
   > if there is a .emacs remove that blurb.  We could add one or two lines
   > along the lines of M-x recover-session:

   What's the difference with the original proposal?

The original proposal read to me that the original splash screen would
be something different when you have .emacs, or when you do not.

Re: A proposal for a friendlier Emacs

[Thibaut Verron]

Le jeu. 17 sept. 2020 à 15:22, Alfred M. Szmidt <ams@gnu.org> a écrit :
>    Is it such a big deal?
>
> To have a different behaviour form if you have .emacs, and when you do
> not? Yes, definitly -- it is fully valid to not have a .emacs file.

As opposed to an empty one?

>
>    In such a situation you just have to click "make my own" if you
>    want a -q, or the other option to get most or all of the most
>    common QoL variables already set, and on subsequent starts there
>    will be an init.el and you won't have the message anymore.
>
> -q is for "quick" -- which is a different behaviour.

I obviously meant -Q, sorry.

>    > Why not just have it on the splash screen if there is no .emacs; and
>    > if there is a .emacs remove that blurb.  We could add one or two lines
>    > along the lines of M-x recover-session:
>
>    What's the difference with the original proposal?
>
> The original proposal read to me that the original splash screen would
> be something different when you have .emacs, or when you do not.

So is yours, no?

Re: A proposal for a friendlier Emacs

[Alfred M. Szmidt]

   >    Is it such a big deal?
   >
   > To have a different behaviour form if you have .emacs, and when you do
   > not? Yes, definitly -- it is fully valid to not have a .emacs file.

   As opposed to an empty one?

Not sure I follow.

   >    In such a situation you just have to click "make my own" if you
   >    want a -q, or the other option to get most or all of the most
   >    common QoL variables already set, and on subsequent starts there
   >    will be an init.el and you won't have the message anymore.
   >
   > -q is for "quick" -- which is a different behaviour.

   I obviously meant -Q, sorry.

Sorry, my fault -- -Q is for quick, -q is for no .emacs.  But then it
still doesn't make sense, if you start with -q then you get a "wizard
screen" -- the whole point was to not get it anything different.

   >    > Why not just have it on the splash screen if there is no .emacs; and
   >    > if there is a .emacs remove that blurb.  We could add one or two lines
   >    > along the lines of M-x recover-session:
   >
   >    What's the difference with the original proposal?
   >
   > The original proposal read to me that the original splash screen would
   > be something different when you have .emacs, or when you do not.

   So is yours, no?

No, it is the same splash screen -- just one message more or less
(like for file recovery).

Re: A proposal for a friendlier Emacs

[Thibaut Verron]

Le jeu. 17 sept. 2020 à 15:31, Alfred M. Szmidt <ams@gnu.org> a écrit :
>
>    >    Is it such a big deal?
>    >
>    > To have a different behaviour form if you have .emacs, and when you do
>    > not? Yes, definitly -- it is fully valid to not have a .emacs file.
>
>    As opposed to an empty one?
>
> Not sure I follow.

On first start, the wizard would offer the option to create an empty
.emacs and never bother you again.

>
>    >    In such a situation you just have to click "make my own" if you
>    >    want a -q, or the other option to get most or all of the most
>    >    common QoL variables already set, and on subsequent starts there
>    >    will be an init.el and you won't have the message anymore.
>    >
>    > -q is for "quick" -- which is a different behaviour.
>
>    I obviously meant -Q, sorry.
>
> Sorry, my fault -- -Q is for quick, -q is for no .emacs.  But then it
> still doesn't make sense, if you start with -q then you get a "wizard
> screen" -- the whole point was to not get it anything different.

I guess the behaviour with -q or -Q or whatever has to be decided separately.

>
>    >    > Why not just have it on the splash screen if there is no .emacs; and
>    >    > if there is a .emacs remove that blurb.  We could add one or two lines
>    >    > along the lines of M-x recover-session:
>    >
>    >    What's the difference with the original proposal?
>    >
>    > The original proposal read to me that the original splash screen would
>    > be something different when you have .emacs, or when you do not.
>
>    So is yours, no?
>
> No, it is the same splash screen -- just one message more or less
> (like for file recovery).

Okay, I call that different, but fine. So essentially you suggest to
include the current contents of the splash screen in the wizard?

Re: A proposal for a friendlier Emacs

[Alfred M. Szmidt]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1510 bytes --]


   Le jeu. 17 sept. 2020 à 15:31, Alfred M. Szmidt <ams@gnu.org> a écrit :
   >
   >    >    Is it such a big deal?
   >    >
   >    > To have a different behaviour form if you have .emacs, and when you do
   >    > not? Yes, definitly -- it is fully valid to not have a .emacs file.
   >
   >    As opposed to an empty one?
   >
   > Not sure I follow.

   On first start, the wizard would offer the option to create an empty
   .emacs and never bother you again.

The issue is that it would bother you on first start, at all.

   >    >    > Why not just have it on the splash screen if there is no .emacs; and
   >    >    > if there is a .emacs remove that blurb.  We could add one or two lines
   >    >    > along the lines of M-x recover-session:
   >    >
   >    >    What's the difference with the original proposal?
   >    >
   >    > The original proposal read to me that the original splash screen would
   >    > be something different when you have .emacs, or when you do not.
   >
   >    So is yours, no?
   >
   > No, it is the same splash screen -- just one message more or less
   > (like for file recovery).

   Okay, I call that different, but fine. So essentially you suggest to
   include the current contents of the splash screen in the wizard?

The wizard is not the splash screen.  I'm suggesting that a link to
selecting vanilla emacs as your default, or some other theme is to be
included in the splash screen; so Emacs behaves the same no matter if
you have .emacs or not.

Re: A proposal for a friendlier Emacs

[Stefan Kangas]

ams@gnu.org (Alfred M. Szmidt) writes:

>    On first start, the wizard would offer the option to create an empty
>    .emacs and never bother you again.
>
> The issue is that it would bother you on first start, at all.

On balance this a good thing, IMO.  And if you disagree, it will only
bother you once.

> The wizard is not the splash screen.  I'm suggesting that a link to
> selecting vanilla emacs as your default, or some other theme is to be
> included in the splash screen; so Emacs behaves the same no matter if
> you have .emacs or not.

Many users never see the splash screen, for example because they don't
pay attention or because they always run "emacs foo.c".

Re: A proposal for a friendlier Emacs

[Alfred M. Szmidt]

   >    On first start, the wizard would offer the option to create an empty
   >    .emacs and never bother you again.
   >
   > The issue is that it would bother you on first start, at all.

   On balance this a good thing, IMO.  And if you disagree, it will only
   bother you once.

No, it will bother _each_ and _every_ time I start a new Emacs where I
have not done so previously.  That is a fairly common situation, both
for new users, but also for experienced users who are the majority of
Emacs users.

Lets not make Emacs annoying to use, OK?

Re: A proposal for a friendlier Emacs

[Thibaut Verron]

Le ven. 18 sept. 2020 à 20:26, Alfred M. Szmidt <ams@gnu.org> a écrit :
>
>    >    On first start, the wizard would offer the option to create an empty
>    >    .emacs and never bother you again.
>    >
>    > The issue is that it would bother you on first start, at all.
>
>    On balance this a good thing, IMO.  And if you disagree, it will only
>    bother you once.
>
> No, it will bother _each_ and _every_ time I start a new Emacs where I
> have not done so previously.  That is a fairly common situation, both
> for new users, but also for experienced users who are the majority of
> Emacs users.
>
> Lets not make Emacs annoying to use, OK?

I, for one, would be happy to have a one-click option to set a bunch
of reasonable defaults whenever I start Emacs on a new device.

Re: A proposal for a friendlier Emacs

[Alfred M. Szmidt]

   >    >    On first start, the wizard would offer the option to create an empty
   >    >    .emacs and never bother you again.
   >    >
   >    > The issue is that it would bother you on first start, at all.
   >
   >    On balance this a good thing, IMO.  And if you disagree, it will only
   >    bother you once.
   >
   > No, it will bother _each_ and _every_ time I start a new Emacs where I
   > have not done so previously.  That is a fairly common situation, both
   > for new users, but also for experienced users who are the majority of
   > Emacs users.
   >
   > Lets not make Emacs annoying to use, OK?

   I, for one, would be happy to have a one-click option to set a bunch
   of reasonable defaults whenever I start Emacs on a new device.

And using the splash screen, that exact possibility is also there.  So
nothing is lost.

Re: A proposal for a friendlier Emacs

[Andrea Corallo via Emacs development discussions.]

ams@gnu.org (Alfred M. Szmidt) writes:

> And using the splash screen, that exact possibility is also there.  So
> nothing is lost.

The splash screen has already quite a number of information, hiding a
button there would make it substantially more ineffective.  If that's
the scope okay otherwise taking example from what distros are doing
since years for a first start seams way more effective to me.

  Andrea

Re: A proposal for a friendlier Emacs

[Alfred M. Szmidt]

   > And using the splash screen, that exact possibility is also there.  So
   > nothing is lost.

   The splash screen has already quite a number of information, hiding a
   button there would make it substantially more ineffective.  

Nobody said anything about hiding it, one can make it prominent.

Re: A proposal for a friendlier Emacs

[Stefan Kangas]

ams@gnu.org (Alfred M. Szmidt) writes:

>    >    On balance this a good thing, IMO.  And if you disagree, it will only
>    >    bother you once.
>    >
>    > No, it will bother _each_ and _every_ time I start a new Emacs where I
>    > have not done so previously.  That is a fairly common situation, both
>    > for new users, but also for experienced users who are the majority of
>    > Emacs users.
>    >
>    > Lets not make Emacs annoying to use, OK?
>
>    I, for one, would be happy to have a one-click option to set a bunch
>    of reasonable defaults whenever I start Emacs on a new device.
>
> And using the splash screen, that exact possibility is also there.  So
> nothing is lost.

Yes, something is lost.  No matter how you go about doing it, it is
clear that it will be significantly less visible.  That's the entire
reason why you are arguing for it, if I understand correctly.

I claim that opening Emacs on new accounts with no .emacs will be
infrequent for most users.  And for users where it is not infrequent,
such as network administrators and the like, it should be easy to turn
the question off using the site file.

Re: A proposal for a friendlier Emacs

[Alfred M. Szmidt]

   >    I, for one, would be happy to have a one-click option to set a bunch
   >    of reasonable defaults whenever I start Emacs on a new device.
   >
   > And using the splash screen, that exact possibility is also there.  So
   > nothing is lost.

   Yes, something is lost.  No matter how you go about doing it, it is
   clear that it will be significantly less visible.  That's the entire
   reason why you are arguing for it, if I understand correctly.

What is lost exactly?  You have the _exact_ same information, plus
some (that of a on-click setup).  Having a special new-user dialog
would be a loss in information since it would hide the splash screen
which provides valuable information for new and old users alike.

If users don't read the normal splash screen, there is no reason to
expect them to look at another "setup screen".

   I claim that opening Emacs on new accounts with no .emacs will be
   infrequent for most users.  

Just today I accessed four different machines where I had never logged
in (mainly for development stuff, where the machines run different
operating systems, often new VMs setup for whatever).  Sometimes it is
accessing the machine as root, sometimes it is as my self.

Re: A proposal for a friendlier Emacs

[Andrea Corallo via Emacs development discussions.]

ams@gnu.org (Alfred M. Szmidt) writes:

>    >    I, for one, would be happy to have a one-click option to set a bunch
>    >    of reasonable defaults whenever I start Emacs on a new device.
>    >
>    > And using the splash screen, that exact possibility is also there.  So
>    > nothing is lost.
>
>    Yes, something is lost.  No matter how you go about doing it, it is
>    clear that it will be significantly less visible.  That's the entire
>    reason why you are arguing for it, if I understand correctly.
>
> What is lost exactly?  You have the _exact_ same information, plus
> some (that of a on-click setup).  Having a special new-user dialog
> would be a loss in information since it would hide the splash screen
> which provides valuable information for new and old users alike.
>
> If users don't read the normal splash screen, there is no reason to
> expect them to look at another "setup screen".

I suspect they probably don't read it because there is too much
information already, adding more would just make it worst.

>    I claim that opening Emacs on new accounts with no .emacs will be
>    infrequent for most users.  
>
> Just today I accessed four different machines where I had never logged
> in (mainly for development stuff, where the machines run different
> operating systems, often new VMs setup for whatever).  Sometimes it is
> accessing the machine as root, sometimes it is as my self.

Which _exact_ part of the spash screen have you used in this process?
How this proposed menu would have made harder your job today?

Re: A proposal for a friendlier Emacs

[Eli Zaretskii]

> Cc: Stefan Kangas <stefankangas@gmail.com>, nicola.manca85@gmail.com,
>  thibaut.verron@gmail.com, emacs-devel@gnu.org
> Date: Sat, 19 Sep 2020 19:31:59 +0000
> From: Andrea Corallo via "Emacs development discussions." <emacs-devel@gnu.org>
> 
> > If users don't read the normal splash screen, there is no reason to
> > expect them to look at another "setup screen".
> 
> I suspect they probably don't read it because there is too much
> information already, adding more would just make it worst.

Are you sure you don't say this as someone who've seen that page many
times already?

That page is made for people who start Emacs for the first time.  When
they see that page for the first time, why would we assume they don't
carefully read all of it?

Re: A proposal for a friendlier Emacs

[Andrea Corallo via Emacs development discussions.]

Eli Zaretskii <eliz@gnu.org> writes:

>> Cc: Stefan Kangas <stefankangas@gmail.com>, nicola.manca85@gmail.com,
>>  thibaut.verron@gmail.com, emacs-devel@gnu.org
>> Date: Sat, 19 Sep 2020 19:31:59 +0000
>> From: Andrea Corallo via "Emacs development discussions." <emacs-devel@gnu.org>
>> 
>> > If users don't read the normal splash screen, there is no reason to
>> > expect them to look at another "setup screen".
>> 
>> I suspect they probably don't read it because there is too much
>> information already, adding more would just make it worst.
>
> Are you sure you don't say this as someone who've seen that page many
> times already?
>
> That page is made for people who start Emacs for the first time.  When
> they see that page for the first time, why would we assume they don't
> carefully read all of it?

I'm not a UI designer but my observation is that especially when these
are made to help new starters they try to give only the least (but very
important) possible information.

I think stuffing alot of information in the spash screen makes it less
effective, but I have no proof of that :)

  Andrea

Re: A proposal for a friendlier Emacs

[Alfred M. Szmidt]

   I'm not a UI designer but my observation is that especially when these
   are made to help new starters they try to give only the least (but very
   important) possible information.

If giving the user the least possible information, how can one hope
that they will learn anything?  That seems quite backwards.

   I think stuffing alot of information in the spash screen makes it less
   effective, but I have no proof of that :)

But nobody was suggesting that...

Re: A proposal for a friendlier Emacs

[Ergus via Emacs development discussions.]

On September 19, 2020 9:59:08 PM GMT+02:00, Eli Zaretskii <eliz@gnu.org> wrote:
>> Cc: Stefan Kangas <stefankangas@gmail.com>, nicola.manca85@gmail.com,
>>  thibaut.verron@gmail.com, emacs-devel@gnu.org
>> Date: Sat, 19 Sep 2020 19:31:59 +0000
>> From: Andrea Corallo via "Emacs development discussions."
><emacs-devel@gnu.org>
>> 
>> > If users don't read the normal splash screen, there is no reason to
>> > expect them to look at another "setup screen".
>> 
>> I suspect they probably don't read it because there is too much
>> information already, adding more would just make it worst.
>
>Are you sure you don't say this as someone who've seen that page many
>times already?
>
>That page is made for people who start Emacs for the first time.  When
>they see that page for the first time, why would we assume they don't
>carefully read all of it?

There have been too many years of licences nobody reads and msoffice useless splash. So people now install the programs just pressing next next next accept.

The problem is that 90% of the cases the information there is pretty useless (publicity, license, offers for an account) so most people assume that in our case it will be the same and usually ignores that.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: A proposal for a friendlier Emacs

[Eli Zaretskii]

> Date: Sun, 20 Sep 2020 09:45:43 +0200
> CC: nicola.manca85@gmail.com,ams@gnu.org,stefankangas@gmail.com,thibaut.verron@gmail.com
> From: Ergus <spacibba@aol.com>
> 
> The problem is that 90% of the cases the information there is pretty
> useless (publicity, license, offers for an account)

But that's not the case with our splash screen: there's a single line
there that shows Copyright, and 2 more lines about the license and
(lack of) warranty.  All the rest (9 lines) are useful information.

Re: A proposal for a friendlier Emacs

[Ergus]

On September 20, 2020 10:13:14 AM GMT+02:00, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Sun, 20 Sep 2020 09:45:43 +0200
>> CC:
>nicola.manca85@gmail.com,ams@gnu.org,stefankangas@gmail.com,thibaut.verron@gmail.com
>> From: Ergus <spacibba@aol.com>
>> 
>> The problem is that 90% of the cases the information there is pretty
>> useless (publicity, license, offers for an account)
>
>But that's not the case with our splash screen: there's a single line
>there that shows Copyright, and 2 more lines about the license and
>(lack of) warranty.  All the rest (9 lines) are useful information.

I agree. I just explained why people use to ignore it very often.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: A proposal for a friendlier Emacs

[Jean Louis]

* Ergus <spacibba@aol.com> [2020-09-20 03:45]:
> There have been too many years of licences nobody reads and msoffice useless splash. So people now install the programs just pressing next next next accept.
> 
> The problem is that 90% of the cases the information there is pretty useless (publicity, license, offers for an account) so most people assume that in our case it will be the same and usually ignores that.

I am not sure how you come to seach information, as it is very
general. I could present Emacs to various people and see if they have
read the splash screen, and then after 5 or 10 attempts, I could have
statistics, who read what, if they found that there is Tutorial or
not, or what else they remembered and if they have read the splash
page.

With 100 people in the test, such information would be valuable
statistics.

Without mass of people tested randomly, it is harder to say that splash
is useless for people because it was maybe useless for one msoffice
user.

I can speak for myself, as it is hard to speak for others, so I know
that I was reading licenses of proprietary software before 1999, and I
know that I was reading everything that Emacs had to offer, from
splash screen, Tutorials in few languages, and GNU news and anything
else, I did read it, and that is how I got fascinated with the free
software. 

-- 
Thanks,
Jean Louis

Re: A proposal for a friendlier Emacs

[Ergus]

On Mon, Sep 21, 2020 at 08:19:58PM +0300, Jean Louis wrote:
>* Ergus <spacibba@aol.com> [2020-09-20 03:45]:
>> There have been too many years of licences nobody reads and msoffice useless splash. So people now install the programs just pressing next next next accept.
>>
>> The problem is that 90% of the cases the information there is pretty useless (publicity, license, offers for an account) so most people assume that in our case it will be the same and usually ignores that.
>
>I am not sure how you come to seach information, as it is very
>general. I could present Emacs to various people and see if they have
>read the splash screen, and then after 5 or 10 attempts, I could have
>statistics, who read what, if they found that there is Tutorial or
>not, or what else they remembered and if they have read the splash
>page.
>
>With 100 people in the test, such information would be valuable
>statistics.
>

>Without mass of people tested randomly, it is harder to say that splash
>is useless for people because it was maybe useless for one msoffice
>user.
>
>I can speak for myself, as it is hard to speak for others, so I know
>that I was reading licenses of proprietary software before 1999, and I
>know that I was reading everything that Emacs had to offer, from
>splash screen, Tutorials in few languages, and GNU news and anything
>else, I did read it, and that is how I got fascinated with the free
>software.
>
So you are probably more the exception than the rule. As you can see
nobody these days reads the licenses anymore, not even the tutorials
(just give a look to quora questions and reddit) except professionals of
course. If they have read the licenses probably they won't be using
facebook, WP or any google service or install in their phones so many
applications full of publicity and give it access anything including
personal contacts and location. They just click yes and want it to be
working asap

I don't have anything opposed to the splash screen and I don't consider
that this kind of users are the main profile emacs should be interested
in to attract. I just say that nobody knows what is written in the
license or the splash screen. Consider also that most of the people in
the world are nor English speakers either.

>-- 
>Thanks,
>Jean Louis

Re: A proposal for a friendlier Emacs

[Jean Louis]

On September 22, 2020 12:59:38 PM UTC, Ergus <spacibba@aol.com> wrote:
>On Mon, Sep 21, 2020 at 08:19:58PM +0300, Jean Louis wrote:
>>* Ergus <spacibba@aol.com> [2020-09-20 03:45]:
>>> There have been too many years of licences nobody reads and msoffice
>useless splash. So people now install the programs just pressing next
>next next accept.
>>>
>>> The problem is that 90% of the cases the information there is pretty
>useless (publicity, license, offers for an account) so most people
>assume that in our case it will be the same and usually ignores that.
>>
>>I am not sure how you come to seach information, as it is very
>>general. I could present Emacs to various people and see if they have
>>read the splash screen, and then after 5 or 10 attempts, I could have
>>statistics, who read what, if they found that there is Tutorial or
>>not, or what else they remembered and if they have read the splash
>>page.
>>
>>With 100 people in the test, such information would be valuable
>>statistics.
>>
>
>>Without mass of people tested randomly, it is harder to say that
>splash
>>is useless for people because it was maybe useless for one msoffice
>>user.
>>
>>I can speak for myself, as it is hard to speak for others, so I know
>>that I was reading licenses of proprietary software before 1999, and I
>>know that I was reading everything that Emacs had to offer, from
>>splash screen, Tutorials in few languages, and GNU news and anything
>>else, I did read it, and that is how I got fascinated with the free
>>software.
>>
>So you are probably more the exception than the rule. As you can see
>nobody these days reads the licenses anymore, not even the tutorials

I am only asking you to be specific, like from where exactly do you draw that information they majority of nobody reads licenses?

Is there a survey result whereby at least 1000 people have been asked if they have read the license or tutorial and in which specific area for which specific group of people?

I know that in Germany we, and I mean my free friends, have been reading license as we were concerned what we can do with proprietary software, if we can make copy for ourselves and if we were allowed to share our install on multiple computers, and later me and my close friends discovered GNU derived distributions and became happy that license now allowed us. I can speak for few close people that I know. And in organization that I worked, the licensing was very much controlled, as we did not want to shift anyone's rights.

As teenager I was clicking through licenses and used warez and whatever I could without paying any license and reading such.

I do not know you, I am 47, what is your age?

I don't know if by saying that nobody reads licenses you refer to nobody teenager interested to play games, or you refer to Tanzanian student who will not care of any license because there will be no enforcement, or you refer to average German trader who needs software professionally.

I know how to make a survey and how to evaluate a survey results, and if none was made, even if it was made, days shall be based on such survey. 

> I just say that nobody knows what is  
>  written in the
>license or the splash screen. Consider also that most of the people in
>the world are nor English speakers > either.

I know you write that but I don't see fusion of such a statement. Did you count number of people not reading licenses and how that was measured, what group of people and in which geographic locations?

Without proper survey result, I don't share your opinion, just contrary, I know that today there is more free software then ever, and speaking from German and of good knowledge of Western European part of the world, I know that those people introduced to free software were especially interested in licensing terms. 

As a speaker on seminars about GNU/Linux systems, attendees in Stuttgart Mediothek, were interested in licensing terms and felt liberated, and I can say they probably read licenses, but I have not controlled them, as a speaker, from their questions I know they were interested.

Do you have more specific data?

Re: A proposal for a friendlier Emacs

[Colin Baxter]

>>>>> Jean Louis <bugs@gnu.support> writes:

    > On September 22, 2020 12:59:38 PM UTC, Ergus <spacibba@aol.com> wrote:
    >> On Mon, Sep 21, 2020 at 08:19:58PM +0300, Jean Louis wrote:
    >>> * Ergus <spacibba@aol.com> [2020-09-20 03:45]:
    >>>> There have been too many years of licences nobody reads and
    >>>> msoffice
    >> useless splash. So people now install the programs just pressing
    >> next next next accept.
    >>>> 
    >>>> The problem is that 90% of the cases the information there is
    >>>> pretty
    >> useless (publicity, license, offers for an account) so most
    >> people assume that in our case it will be the same and usually
    >> ignores that.
    >>> 
    >>> I am not sure how you come to seach information, as it is very
    >>> general. I could present Emacs to various people and see if they
    >>> have read the splash screen, and then after 5 or 10 attempts, I
    >>> could have statistics, who read what, if they found that there
    >>> is Tutorial or not, or what else they remembered and if they
    >>> have read the splash page.
    >>> 
    >>> With 100 people in the test, such information would be valuable
    >>> statistics.
    >>> 
    >> 
    >>> Without mass of people tested randomly, it is harder to say that
    >> splash
    >>> is useless for people because it was maybe useless for one
    >>> msoffice user.
    >>> 
    >>> I can speak for myself, as it is hard to speak for others, so I
    >>> know that I was reading licenses of proprietary software before
    >>> 1999, and I know that I was reading everything that Emacs had to
    >>> offer, from splash screen, Tutorials in few languages, and GNU
    >>> news and anything else, I did read it, and that is how I got
    >>> fascinated with the free software.
    >>> 
    >> So you are probably more the exception than the rule. As you can
    >> see nobody these days reads the licenses anymore, not even the
    >> tutorials

    > I am only asking you to be specific, like from where exactly do
    > you draw that information they majority of nobody reads licenses?

    > Is there a survey result whereby at least 1000 people have been
    > asked if they have read the license or tutorial and in which
    > specific area for which specific group of people?

    > I know that in Germany we, and I mean my free friends, have been
    > reading license as we were concerned what we can do with
    > proprietary software, if we can make copy for ourselves and if we
    > were allowed to share our install on multiple computers, and later
    > me and my close friends discovered GNU derived distributions and
    > became happy that license now allowed us. I can speak for few
    > close people that I know. And in organization that I worked, the
    > licensing was very much controlled, as we did not want to shift
    > anyone's rights.

    > As teenager I was clicking through licenses and used warez and
    > whatever I could without paying any license and reading such.

    > I do not know you, I am 47, what is your age?

    > I don't know if by saying that nobody reads licenses you refer to
    > nobody teenager interested to play games, or you refer to
    > Tanzanian student who will not care of any license because there
    > will be no enforcement, or you refer to average German trader who
    > needs software professionally.

    > I know how to make a survey and how to evaluate a survey results,
    > and if none was made, even if it was made, days shall be based on
    > such survey.

    >> I just say that nobody knows what is written in the license or
    >> the splash screen. Consider also that most of the people in the
    >> world are nor English speakers > either.

    > I know you write that but I don't see fusion of such a
    > statement. Did you count number of people not reading licenses and
    > how that was measured, what group of people and in which
    > geographic locations?

    > Without proper survey result, I don't share your opinion, just
    > contrary, I know that today there is more free software then ever,
    > and speaking from German and of good knowledge of Western European
    > part of the world, I know that those people introduced to free
    > software were especially interested in licensing terms.

    > As a speaker on seminars about GNU/Linux systems, attendees in
    > Stuttgart Mediothek, were interested in licensing terms and felt
    > liberated, and I can say they probably read licenses, but I have
    > not controlled them, as a speaker, from their questions I know
    > they were interested.

As I understand things, the "E" in emacs is for extensible. If something
is extensible then I suggest there exists an initial zero-extension
state. I further suggest that that state is characterised by the absent
of a .emacs file (or equivalent). Therefore emacs needs no .emacs to
work. I very much agree with what Jean Louis has written about this.

I know very little about emacs having only used it for 20+ years. (That
is a serious observation, not a joke.) For the first five years I knew
nothing about a .emacs file and used emacs happily to edit tex and
fortran files. I did read the licenses and became intrigued by something
called free software.

My point is emacs is a journey for many of us and I think my journey
would have begun on the wrong foot if I had been told what to do by a
"wizard". If you really want to sell emacs to new users, tell them about
this journey and tell them they will have adventures - but let them find
the adventures themselves.

Best wishes,


Colin Baxter
URL: http://www.Colin-Baxter.com
---------------------------------------------------------------------
GnuPG fingerprint: 68A8 799C 0230 16E7 BF68  2A27 BBFA 2492 91F5 41C8
---------------------------------------------------------------------
Since mathematicians have invaded the theory of relativity, I do not
understand it myself. A. Einstein

Re: A proposal for a friendlier Emacs

[Mingde (Matthew) Zeng]

> As I understand things, the "E" in emacs is for extensible.

IIRC Emacs is short for Editor MACroS.

--
Mingde (Matthew) Zeng

Re: A proposal for a friendlier Emacs

[Colin Baxter]

>>>>> Mingde (Matthew) Zeng <matthewzmd@posteo.net> writes:

    >> As I understand things, the "E" in emacs is for extensible.
    > IIRC Emacs is short for Editor MACroS.

Thanks. My mistake, but it doesn't invalidate the rest of my post.

Best wishes

Re: A proposal for a friendlier Emacs

[Alfred M. Szmidt]

   > What is lost exactly?  You have the _exact_ same information, plus
   > some (that of a on-click setup).  Having a special new-user dialog
   > would be a loss in information since it would hide the splash screen
   > which provides valuable information for new and old users alike.
   >
   > If users don't read the normal splash screen, there is no reason to
   > expect them to look at another "setup screen".

   I suspect they probably don't read it because there is too much
   information already, adding more would just make it worst.

If the few paragraphs on the splash screen are deemed "too much
information" then why would they read any other page?! 

Lets not assume that users are that lazy ...

   >    I claim that opening Emacs on new accounts with no .emacs will be
   >    infrequent for most users.  
   >
   > Just today I accessed four different machines where I had never logged
   > in (mainly for development stuff, where the machines run different
   > operating systems, often new VMs setup for whatever).  Sometimes it is
   > accessing the machine as root, sometimes it is as my self.

   Which _exact_ part of the spash screen have you used in this process?

Visit new file and Open Home Directory.

   How this proposed menu would have made harder your job today?

We are talking about the splash screen, not a menu.  The suggestion
(as I understood it) was to replace the splash screen with a wizard if
and only if there was no .emacs (or similar).  Then do magic to
somehow keep track if a user had "picked" a provided configuration
(vanilla, different, or configuration wizard) of Emacs.  Only then,
would you get the current splash screen when you start emacs.

That is a strange behaviour, and very much annoying one to keep track
of.  

Re: A proposal for a friendlier Emacs

[Andrea Corallo via Emacs development discussions.]

ams@gnu.org (Alfred M. Szmidt) writes:

>    > What is lost exactly?  You have the _exact_ same information, plus
>    > some (that of a on-click setup).  Having a special new-user dialog
>    > would be a loss in information since it would hide the splash screen
>    > which provides valuable information for new and old users alike.
>    >
>    > If users don't read the normal splash screen, there is no reason to
>    > expect them to look at another "setup screen".
>
>    I suspect they probably don't read it because there is too much
>    information already, adding more would just make it worst.
>
> If the few paragraphs on the splash screen are deemed "too much
> information" then why would they read any other page?! 
>
> Lets not assume that users are that lazy ...

IMO is quite a realistic scenario, so I'll assume that.

>    >    I claim that opening Emacs on new accounts with no .emacs will be
>    >    infrequent for most users.  
>    >
>    > Just today I accessed four different machines where I had never logged
>    > in (mainly for development stuff, where the machines run different
>    > operating systems, often new VMs setup for whatever).  Sometimes it is
>    > accessing the machine as root, sometimes it is as my self.
>
>    Which _exact_ part of the spash screen have you used in this process?
>
> Visit new file and Open Home Directory.
>
>    How this proposed menu would have made harder your job today?

Apologies wanted to write buffer.

> We are talking about the splash screen, not a menu.  The suggestion
> (as I understood it) was to replace the splash screen with a wizard if
> and only if there was no .emacs (or similar).  Then do magic to
> somehow keep track if a user had "picked" a provided configuration
> (vanilla, different, or configuration wizard) of Emacs.  Only then,
> would you get the current splash screen when you start emacs.
>
> That is a strange behaviour, and very much annoying one to keep track
> of.  

Sorry I have hard time imaging experienced users regularly using the
splash screen to open files, I find surprising this is your experience.

Re: A proposal for a friendlier Emacs

[Alfred M. Szmidt]

   > If the few paragraphs on the splash screen are deemed "too much
   > information" then why would they read any other page?! 
   >
   > Lets not assume that users are that lazy ...

   IMO is quite a realistic scenario, so I'll assume that.

From my experience, that is absolutley not the case.  It is the first
step to the tutorial, and the manual.

   > We are talking about the splash screen, not a menu.  The suggestion
   > (as I understood it) was to replace the splash screen with a wizard if
   > and only if there was no .emacs (or similar).  Then do magic to
   > somehow keep track if a user had "picked" a provided configuration
   > (vanilla, different, or configuration wizard) of Emacs.  Only then,
   > would you get the current splash screen when you start emacs.
   >
   > That is a strange behaviour, and very much annoying one to keep track
   > of.  

   Sorry I have hard time imaging experienced users regularly using the
   splash screen to open files, I find surprising this is your experience.

I use it all the time when I'm extra lazy or showing new users to use emacs.

It is sometimes easier to use the mouse when you're already using the
mouse; the benefit is also that you get the file dialog which you do
not get when you do find-file.  Ditto with the menu bar, which has its
uses.

Re: A proposal for a friendlier Emacs

[Andrea Corallo via Emacs development discussions.]

Thibaut Verron <thibaut.verron@gmail.com> writes:

> Le ven. 18 sept. 2020 à 20:26, Alfred M. Szmidt <ams@gnu.org> a écrit :
>>
>>    >    On first start, the wizard would offer the option to create an empty
>>    >    .emacs and never bother you again.
>>    >
>>    > The issue is that it would bother you on first start, at all.
>>
>>    On balance this a good thing, IMO.  And if you disagree, it will only
>>    bother you once.
>>
>> No, it will bother _each_ and _every_ time I start a new Emacs where I
>> have not done so previously.  That is a fairly common situation, both
>> for new users, but also for experienced users who are the majority of
>> Emacs users.
>>
>> Lets not make Emacs annoying to use, OK?
>
> I, for one, would be happy to have a one-click option to set a bunch
> of reasonable defaults whenever I start Emacs on a new device.

+1

Re: A proposal for a friendlier Emacs

[Philip K.]

Thibaut Verron <thibaut.verron@gmail.com> writes:

> Le ven. 18 sept. 2020 à 20:26, Alfred M. Szmidt <ams@gnu.org> a écrit :
>>
>>    >    On first start, the wizard would offer the option to create an empty
>>    >    .emacs and never bother you again.
>>    >
>>    > The issue is that it would bother you on first start, at all.
>>
>>    On balance this a good thing, IMO.  And if you disagree, it will only
>>    bother you once.
>>
>> No, it will bother _each_ and _every_ time I start a new Emacs where I
>> have not done so previously.  That is a fairly common situation, both
>> for new users, but also for experienced users who are the majority of
>> Emacs users.
>>
>> Lets not make Emacs annoying to use, OK?
>
> I, for one, would be happy to have a one-click option to set a bunch
> of reasonable defaults whenever I start Emacs on a new device.

I've seen new users keep the splash screen open all the time they are
using Emacs, not bothering to close it (mostly because they open it via
their graphical file manager or something along those
lines). Additionally having a wizard pop up would use even more screen
space, and is probably not what we want.

-- 
	Philip K.

Re: A proposal for a friendlier Emacs

[황병희]

Stefan Kangas <stefankangas@gmail.com> writes:

> ...
> ... because they always run "emacs foo.c".

Wow Stefan, thank you for tiny and clever tip!

Sincerely, Byung-Hee

-- 
^고맙습니다 _救濟蒼生_ 감사합니다_^))//

Re: A proposal for a friendlier Emacs

[Alfred M. Szmidt]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1544 bytes --]

   > The original proposal read to me that the original splash screen would
   > be something different when you have .emacs, or when you do not.

   So is yours, no?

I was thnking, where >> is the part that gets added when there is no
.emacs -- this keeps existing behaviour, and isn't as intrusive.  It
could be listed under Useful tasks too.

  Welcome to GNU Emacs, a part of the GNU operating system.
  To follow a link, click Mouse-1 on it, or move to it and type RET.
  To quit a partially entered command, type Control-g.
  
>>    You don't have a personal Emacs configuration file, would you
>>    like to run the configuration wizard, just use vanilla Emacs, or
>>    try a different default?
  
  Important Help menu items:
  Emacs Tutorial		Learn basic Emacs keystroke commands
  Read the Emacs Manual	View the Emacs manual using Info
  (Non)Warranty		GNU Emacs comes with ABSOLUTELY NO WARRANTY
  Copying Conditions	Conditions for redistributing and changing Emacs
  More Manuals / Ordering Manuals  How to order printed manuals from the FSF
  
  Useful tasks:
  Visit New File		Specify a new file’s name, to edit the file
  Open Home Directory	Open your home directory, to operate on its files
  Customize Startup	Change initialization settings including this screen
  
  GNU Emacs 26.3 (build 1, x86_64-unknown-openbsd, GTK+ Version 3.24.20)
   of 2020-05-09
  Copyright (C) 2019 Free Software Foundation, Inc.
  
  If an Emacs session crashed recently, type M-x recover-session RET
  to recover the files you were editing.

Re: A proposal for a friendlier Emacs

[Nicholas Savage]

I like the idea of a configuration wizard, but I agree that I wouldn't want to have to deal with it when logging into a new machine or using emacs -Q. 

What if the installer created a file somewhere in Emacs etc folder, such as `trigger_conf_wizard'. Then, Emacs checks if that file exists or not. If it does exist, run the configuration wizard and subsequently delete the file. If it doesn't exist, skip the wizard. This way too if you're fooling around with your .emacs, or testing the vanilla configuration, you won't have to worry about the wizard or figuring out the switch for it.

On Thu, Sep 17, 2020, at 08:24, Alfred M. Szmidt wrote:
>    > It shouldn't be super intrusive if there is no .emacs, since it is
>    > quite common to fire up Emacs without a .emacs.
> 
>    I think we should find a compromise here. If an experienced user stats 
>    emacs without a .emacs present, he/she may disable this somehow (maybe 
>    with --no-splash ?)
> 
> I think that would be annoying -- if I log in on a new machine that
> I've never used, I'm sure I wont remeber passing any special switches
> to Emacs to start it.
> 
> Why not just have it on the splash screen if there is no .emacs; and
> if there is a .emacs remove that blurb.  We could add one or two lines
> along the lines of M-x recover-session:
> 
>    If an Emacs session crashed recently, type M-x recover-session RET
>    to recover the files you were editing.
> 
> E.g., (actual wording left for someone else) if there is no .emacs, we
> show:
> 
>   You do not have a personal Emacs configuration file, you can go
>   [Vanilla], start the [configuration wizard], or try Emacs with a
>   different theme [different-theme-mode].
> 
> And if there is, we skip it.  And have some means of getting to the
> wizard from the menu-bar, maybe even a way of selecting a list of
> themes there too..
> 
> This wouldn't change how Emacs behaves, but still allow new or
> experienced users to fiddle.
> 
> 
>

Re: A proposal for a friendlier Emacs

[Alfred M. Szmidt]

   I like the idea of a configuration wizard, but I agree that I
   wouldn't want to have to deal with it when logging into a new
   machine or using emacs -Q.

   What if the installer created a file somewhere in Emacs etc folder,
   such as `trigger_conf_wizard'. Then, Emacs checks if that file
   exists or not. If it does exist, run the configuration wizard and
   subsequently delete the file. If it doesn't exist, skip the
   wizard. This way too if you're fooling around with your .emacs, or
   testing the vanilla configuration, you won't have to worry about
   the wizard or figuring out the switch for it.

I'm not sure I follow, isn't that exactly the same thing as checking
for .emacs or not? That is, if you're on a new machine, then there is
nothing to check for so the wizard popup or whatever will be shown.

Re: A proposal for a friendlier Emacs

[Thibaut Verron]

Le jeu. 17 sept. 2020 à 14:42, Nicholas Savage <nick@nicksavage.ca> a écrit :
>
> I like the idea of a configuration wizard, but I agree that I wouldn't want to have to deal with it when logging into a new machine or using emacs -Q.
>
> What if the installer created a file somewhere in Emacs etc folder, such as `trigger_conf_wizard'. Then, Emacs checks if that file exists or not. If it does exist, run the configuration wizard and subsequently delete the file. If it doesn't exist, skip the wizard. This way too if you're fooling around with your .emacs, or testing the vanilla configuration, you won't have to worry about the wizard or figuring out the switch for it.

How would it work in a multi-users setting?

Re: A proposal for a friendlier Emacs

[Mingde (Matthew) Zeng]

> I like the idea of a configuration wizard, but I agree that I wouldn't want to have to deal with it when logging into a new machine or using emacs -Q.

If we populate the configuration wizard on the default dashboard buffer, you can completely ignore it and don't deal with it, like the rest of the default dashboard screen.

--
Mingde (Matthew) Zeng

Re: A proposal for a friendlier Emacs

[Gregory Heytings via Emacs development discussions.]

Hi Nicola,

Thanks for your proposal!

>
> What about having a startup screen, opening only if no .emacs or other 
> user configuration file is found just saying (the text is just an 
> example):
>
> Welcome!
> This is the first time you run Emacs, please choose how to proceed:
>
> [] Go Vanilla!
>  (standard defaults, no customizations)
>
> [] Start Configuration Wizard
>  (set-up your .emacs configuration file interactively)
>
> [] Try Emacs in enhanced-mode
>  (run with a predefined configuration showing emacs potential)
>

That's a very good suggestion, thank you!  I think it would be better to 
invert options 2 et 3, with something like:

[] Go Vanilla!
[] Choose a predefined configuration
[] Create your own configuration

Option 2 would present the user with a list of predefined configuration 
sets: "doom", "quake", "vscode", ...

Option 3 would give the user a way to create a more refined configuration.

>
> This solution would prevent the problem of passing --modern to the emacs 
> exacutable and, beyond that, it could also correspond to emacs -Q, since 
> choosing "Vanilla" would result in a normal clean startup.
>

IMO this screen should be skipped when the option -Q or -q is passed to 
Emacs.

Re: A proposal for a friendlier Emacs

[Nicola Manca]

On 17/09/20 11:07, Gregory Heytings wrote:
> 
> Hi Nicola,
> 
> Thanks for your proposal!
> 
>>
>> What about having a startup screen, opening only if no .emacs or other 
>> user configuration file is found just saying (the text is just an 
>> example):
>>
>> Welcome!
>> This is the first time you run Emacs, please choose how to proceed:
>>
>> [] Go Vanilla!
>>  (standard defaults, no customizations)
>>
>> [] Start Configuration Wizard
>>  (set-up your .emacs configuration file interactively)
>>
>> [] Try Emacs in enhanced-mode
>>  (run with a predefined configuration showing emacs potential)
>>
> 
> That's a very good suggestion, thank you!  I think it would be better to 
> invert options 2 et 3, with something like:

I've no strong opinion about that :)

> [] Go Vanilla!
> [] Choose a predefined configuration
> [] Create your own configuration
> 
> Option 2 would present the user with a list of predefined configuration 
> sets: "doom", "quake", "vscode", ...

This is nice, but I think it is better to focus on something that is 
rapidly achievable and then maybe improve it. Andrea's suggestion is 
based entirely on CORE features, while I fear that mimic VScode or Doom 
may require MELPA.

> Option 3 would give the user a way to create a more refined configuration.
> 
>>
>> This solution would prevent the problem of passing --modern to the 
>> emacs exacutable and, beyond that, it could also correspond to emacs 
>> -Q, since choosing "Vanilla" would result in a normal clean startup.
>>
> 
> IMO this screen should be skipped when the option -Q or -q is passed to 
> Emacs.

I don't know. I think this is a way to somehow "reset" emacs or let 
someone else to try it on your own computer without having to face a 
personalized configuration. In such a away when he/she will install 
emacs will have the same user experience.

Maybe emacs -Q coud be just as now and "emacs" could start the splash 
screen if no configuration is found.

Nicola

Re: A proposal for a friendlier Emacs

[Gregory Heytings via Emacs development discussions.]

>> Option 2 would present the user with a list of predefined configuration 
>> sets: "doom", "quake", "vscode", ...
>
> This is nice, but I think it is better to focus on something that is 
> rapidly achievable and then maybe improve it. Andrea's suggestion is 
> based entirely on CORE features, while I fear that mimic VScode or Doom 
> may require MELPA.
>

What I wrote was not clear enough.  I did not mean "to mimick VSCode", I 
meant only to have a configuration that would make Emacs' experience 
closer to that of VSCode, without installing extra packages.

Re: A proposal for a friendlier Emacs

[Alexander Adolf]

Hello,

I started using Emacs when I first installed Lucid Emacs on a
SPARCstation LX, must have been early 1990s, and I have gone through
quite a couple of Emacs configs since then (SunOS, Solaris, and now
macOS).

Since one of the topics on the Emacs 28/modern threads here was
"on-boarding" of new users, I thought I'd share a few experiences of
what some hard parts were while developing my configs.

----------------------------------------------------------------------

The first hurdle is that when developing a config (yes, its a
development task), is that you're essentially pulling yourself out if
the swamp by your own hair. I.e. you are using Emacs to edit its own
configuration files. Many settings have immediate effect, and that's
super cool. Some don't, however, (or maybe you forgot to eval-region)
and seem to be evaluated only once at start-up time.

Another aspect of this is that not every change I make is one I will
want to keep (I'm trying things out). So this is about "backing out"
changes and restoring state. Whatever I want to achieve, in order to be
able to revert things later, I'll have to make note of the values of
variables and hooks before I change them, so I'll be able to restore the
previous value. Lest I forgot to make note...

Both things together result in me restarting Emacs every now and then
when developing a config, so as to be able to start from a clean slate,
and make sure that all config changes have been applied. Restarting
brings with it a couple of inconveniences. Apart from the wait, it also
means that I will need to re-open all the files, custom buffers,
documentation, and what not I had open before.

Thus, in my ideal world I would like to be able to start a new Emacs
instance, that loads the new config, has debug-on-error set, verbose
logging, and perhaps some more things to help me debug my new config. In
the new Emacs instance, I can take my new config for a spin, and
terminate it when I'm done (or even kill it if I messed up badly). Then
I drop back into the initial Emacs instance (still all buffers open),
refine the config, and give it another round.

----------------------------------------------------------------------

As your config evolves, the next question everyone will be asking
themselves is "custom.el or init file?" While there is no one answer to
this, of course, but it hints to a wider issue. With flexibility (of
init files architecture), comes responsibility (to choose the right
architecture for my case).

Here is what I observed: when I start adding a new class of use-cases
(example: email), I start out with a single package, that does most of
what I want/need. In that phase, I tend to name the config file after
the package (because the use-case and the package are one and the same
in my mental model). As I keep refining, and adding features, other
packages will likely come into play. At this point I realise that the
config file name no longer fits, and rename it to reflect the use-case
class. Within this config file, I keep the setting for each package in a
different section (separated by comments).

Again, in my ideal world, each package would be classified into exactly
one main category (email, content completion, etc.). When I install
(package-list-packages) the first package from a category I haven't had
before, Emacs would create a new file in the init directory, named after
the category (example: email.el), with a (provide 'setup-category) at
the end, and a section for the new package that has a copy of the init
code proposed by the package's documentation, and would eval-region on
the init code. When I install the next package from that category, Emacs
would just drop a new section into the respective init file, and
eval-region that section. Oh, and of course a (require 'setup-category)
would also need to be automatically dropped into init.el.

Of course this will not make every experienced user happy, and people
with existing, sophisticated configs will want to switch this off. So
there should be a variable to turn the whole mechanism off. Maybe in
early-init.el? But I think it could be a subtle way of guiding new users
to starting with a structured approach to init files (searching for
"emacs.d" on GitHub as of this writing lists 10,521 repositories).

In the long run, this could also be a tool for doing away with
custom.el. Just have Custom insert a custom-set-variables with the
settings for that package in the section for that package in the
respective category config file. And the settings for Emacs itself would
live in init.el.

----------------------------------------------------------------------

The third area I'd like to touch on are faces. This is what certainly
everybody will want to customise at some point. The reality of
customising faces is: it's hard. Faces can inherit from one another, so
sometimes I end up changing a couple of faces, when it would have been
sufficient to customise one (the "parent"). An "inheritance tree" would
help here.

Also, 'C-u C-x =' (what-cursor-position; 10 points for choosing a
calling name, btw.) is your friend to find out which of the many many
faces to change (provided you discovered it). But then you'll have to
strike the key chord time again to discover the faces and overlays here
and there. Why couldn't what-cursor-position just split the window,
display its information in the other window, and let me move around in
my buffer, updating the face/overlay information in the other window as
I move the cursor around? And as most of us are on graphical desktops
these days, where's the option to hover with the mouse and get
face/overlay information for what's under the mouse?

One more thing on what-cursor-position: in the info buffer, there's a
link for the face that takes me to another info screen, which in turn
describes the face's attributes, and gives me a "you can configure this"
link. IMO, this is redundant. Just give me a direct link to the face's
customisation from the initial what-cursor-position infp screen. The
customisation buffer will also show me the current attributes, so the
"intermediate" face attributes info screen has no added value to me.

----------------------------------------------------------------------

Finally, a few thoughts on packages and curation. As of this writing,
the combined list of ELPA, MELPA, and builtin packages of my current
emacs lists 5,065 packages. Chances are, whatever topic you're looking
at, there's more than one package. Which one is the best for my
purposes?

The Comprehensive Perl Archive Network (CPAN), which as of this writing
offers 196,156 Perl modules, faces similar issues. It has a simple
mechanism, which I find very helpful for quickly narrowing down my
selection. Users can do "add to favourites" for a module. When one
browses the modules, the number of users who faved it is shown. Not
perfect, but a rule-of-thumb estimate for a module's popularity. In my
ideal world, such a favourite mechanism would be added to ELPA and
MELPA, too, and the favourite count be displayed in the package
details screen of package-list-packages.

----------------------------------------------------------------------


Looking forward to your thoughts,

  --alexander

Re: A proposal for a friendlier Emacs

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > As your config evolves, the next question everyone will be asking
  > themselves is "custom.el or init file?"

It is possible to use both -- so why do people believe they have
to choose one or the other?

  > Here is what I observed: when I start adding a new class of use-cases
  > (example: email), I start out with a single package, that does most of
  > what I want/need.

We use multiple definitions of "package" in connection with Emacs.
Would you please say what definition you're using here?

For instance, does "package" include Rmail?

  > Within this config file, I keep the setting for each package in a
  > different section (separated by comments).

Could Configure do this automatically?  Would that require
additional data about relationships between various things?

  > Again, in my ideal world, each package would be classified into exactly
  > one main category (email, content completion, etc.). 

In principle, I think this is a good idea.  However, think it should
NOT be limited to ELPA packages.

Also, I have a feeling that users won't all agree how to classify
packages.  I expect there will be overlapping categories that make sense.
So I think we need to make provision for having one package
that fits into multiple categories.  Perhaps by asking the user
which category to think of this package in.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: A proposal for a friendlier Emacs

[Alexander Adolf]

Richard Stallman <rms@gnu.org> writes:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>   > As your config evolves, the next question everyone will be asking
>   > themselves is "custom.el or init file?"
>
> It is possible to use both -- so why do people believe they have
> to choose one or the other?

Apologies for not having been clear enough. The question is not either
or, but whether any arbitrary, usually small, set of (setq X) or
(face-spec-set Y) are better added to a hand-crafted init file, or done
via Custom (so they end up in custom.el). The typical advice users get
on Stackexchange and similar, is to choose either variant at will (or
randomly), and to version control their emacs.d directory with git.

What this shows is that (too much) freedom of choice early on in a new
user's adoption journey can be perceived as an obstacle (by new users).

>   > Here is what I observed: when I start adding a new class of use-cases
>   > (example: email), I start out with a single package, that does most of
>   > what I want/need.
>
> We use multiple definitions of "package" in connection with Emacs.
> Would you please say what definition you're using here?
>
> For instance, does "package" include Rmail?

Good point; 'package' is used in so many contexts, it's a fuzzy
term. Yes, I would refer to Rmail as a 'package', too.

>   > Within this config file, I keep the setting for each package in a
>   > different section (separated by comments).
>
> Could Configure do this automatically?

That was precisely my idea.

> Would that require additional data about relationships between various
> things?

I haven't done any experiments, but in my manually crafted configs, I
never had an issue with the ordering of sections. Sure, not everything
is autoloaded, and there's lazy loading. What about wrapping a package's
config in a with-eval-after-load, or making use-package a builtin?

>   > Again, in my ideal world, each package would be classified into exactly
>   > one main category (email, content completion, etc.). 
>
> In principle, I think this is a good idea.  However, think it should
> NOT be limited to ELPA packages.

Fully agree.

> Also, I have a feeling that users won't all agree how to classify
> packages.  I expect there will be overlapping categories that make sense.
> So I think we need to make provision for having one package
> that fits into multiple categories.  Perhaps by asking the user
> which category to think of this package in.
> [...]

Let the package author choose and, and only one category, and any number
of tags he/she wants to use to describe the package.

When a user installs a package from a package archive, the category
chosen by the author is presented as the default choice, and can be
overridden by the user.

Just my two cents anyway.


Looking forward to your thoughts,

  --alexander

RE: A proposal for a friendlier Emacs

[Drew Adams]

> The question is ... whether any arbitrary, usually small, set of (setq X) or
> (face-spec-set Y) are better added to a hand-crafted init file, or done
> via Custom (so they end up in custom.el).  The typical advice users get
> on Stackexchange and similar, is to choose either variant at will (or
> randomly), and to version control their emacs.d directory with git.

FWIW,that's not the advice I give.  This is the advice I give:

https://emacs.stackexchange.com/questions/102/advantages-of-setting-variables-with-setq-instead-of-custom-el/106#106

And my advice is to use a `custom-file', so that Customize
doesn't fiddle with your hand-coded settings in your init
file.  (And you shouldn't fiddle with Customize's code in
your `custom-file'.)

> What this shows is that (too much) freedom of choice early on in a new
> user's adoption journey can be perceived as an obstacle (by new users).

That may be true.

(I kinda wish that Emacs would somehow provide users with a
default, empty `custom-file', so that Customize would never
go near their init file.)

Re: A proposal for a friendlier Emacs

[Eli Zaretskii]

> Date: Tue, 22 Sep 2020 14:54:49 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: emacs-devel@gnu.org
> 
> > The question is ... whether any arbitrary, usually small, set of (setq X) or
> > (face-spec-set Y) are better added to a hand-crafted init file, or done
> > via Custom (so they end up in custom.el).  The typical advice users get
> > on Stackexchange and similar, is to choose either variant at will (or
> > randomly), and to version control their emacs.d directory with git.
> 
> FWIW,that's not the advice I give.  This is the advice I give:
> 
> https://emacs.stackexchange.com/questions/102/advantages-of-setting-variables-with-setq-instead-of-custom-el/106#106

In any case, I don't think we can be held responsible for incorrect or
inaccurate advice given on other forums.

Re: A proposal for a friendlier Emacs

[Eli Zaretskii]

> From: Alexander Adolf <alexander.adolf@condition-alpha.com>
> Date: Tue, 22 Sep 2020 22:50:21 +0200
> Cc: emacs-devel@gnu.org
> 
> > Also, I have a feeling that users won't all agree how to classify
> > packages.  I expect there will be overlapping categories that make sense.
> > So I think we need to make provision for having one package
> > that fits into multiple categories.  Perhaps by asking the user
> > which category to think of this package in.
> > [...]
> 
> Let the package author choose and, and only one category, and any number
> of tags he/she wants to use to describe the package.

That might be possible for some specialized packages, but not forf all
of them.

> When a user installs a package from a package archive, the category
> chosen by the author is presented as the default choice, and can be
> overridden by the user.

If the category is not fixed, I'm not sure I see the utility of having
such categories at all in the custom file.

Re: A proposal for a friendlier Emacs

[Alexander Adolf]

Eli Zaretskii <eliz@gnu.org> writes:

> [...] 
>> Let the package author choose and, and only one category, and any number
>> of tags he/she wants to use to describe the package.
>
> That might be possible for some specialized packages, but not forf all
> of them.



>> When a user installs a package from a package archive, the category
>> chosen by the author is presented as the default choice, and can be
>> overridden by the user.
>
> If the category is not fixed, I'm not sure I see the utility of having
> such categories at all in the custom file.

My idea about the category was to use it for grouping things into
"topical files" inside emacs.d. Consider the following, fictional,
example:

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 ~/.emacs.d/init.el                                    
───────────────────────────────────────────────────────
 ;;;; %%%%% magic-comment (emacs-core) %%%%%           
 (custom-set-* …) ;; inserted and maintained by Custom 
 ;;;; %%%%%                                            
 (…) ;; manual init code for emacs-core                
                                                       
 (require 'setup-email)                                
 (require 'setup-progn)                                
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━


━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 ~/.emacs.d/setup-email.el                                   
───────────────────────────────────────────────────────
 ;;;; %%%%% magic-comment (my-awesome-package) %%%%%   
 (custom-set-* …) ;; inserted and maintained by Custom 
 ;;;; %%%%%                                            
 (…) ;; manual init code for my-awesome-package        
                                                       
 ;;;; %%%%% magic-comment (even-greater-package) %%%%% 
 (custom-set-* …) ;; inserted and maintained by Custom 
 ;;;; %%%%%                                            
 (…) ;; manual init code for even-greater-package      
                                                       
 (provide 'setup-email)                                
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━


━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 ~/.emacs.d/setup-progn.el                                     
─────────────────────────────────────────────────────────
 ;;;; %%%%% magic-comment (super-duper-package) %%%%%    
 (custom-set-* …) ;; inserted and maintained by Custom   
 ;;;; %%%%%                                              
 (…) ;; manual init code for super-duper-package         
                                                         
 ;;;; %%%%% magic-comment (totally-useful-package) %%%%% 
 (custom-set-* …) ;; inserted and maintained by Custom   
 ;;;; %%%%%                                              
 (…) ;; manual init code for totally-useful-package      
                                                         
 (provide 'setup-progn)                                  
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

In this case, the user has installed four packages. Two of them were
categorised as "email", and two of them as "progn". When the first
package from a new category gets installed, a new setup-category.el file
would be generated in emacs.d. Whatever the user tweaks in Custom, gets
inserted in the (custom-set-* …) block for the package, and in the
respective setup-category.el file.

When a new user starts using Emacs (i.e. neither ~/.emacs.d nor ~/.emacs
exist), and changes settings in Custom, a ~/.emacs.d/init.el would be
created, with the magic comment/(custom-set-* …) block.

When a new package gets installed, the user would be prompted "Install
super-duper-package as category [progn]?", with the category chosen by
the package author (and stored in the package repository) as the
default. An option to never ask and always use the package's category
would also seem to make sense, and there might even be a point in
setting it to true by default (to not overwhelm new users with questions
they might have a hard time to understand). Later on, as the user
becomes more experienced, he/she may set that variable to false, and
move configuration blocks between init files as he/she deems fit.

Disadvantages:

• manual and automatic edits in the same file, which may lead to
  breakage

Advantages:

• new users are guided towards a topical config structure, and without
  any work on their part get a skeleton config to build upon

• all settings for any given package are collected in one place, instead
  of being spread out between the custom file and manually created files


Many thanks and looking forward to your thoughts,

  --alexander

Re: A proposal for a friendlier Emacs

[Eli Zaretskii]

> From: Alexander Adolf <alexander.adolf@condition-alpha.com>
> Cc: rms@gnu.org, emacs-devel@gnu.org
> Date: Fri, 25 Sep 2020 15:22:31 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > [...] 
> >> Let the package author choose and, and only one category, and any number
> >> of tags he/she wants to use to describe the package.
> >
> > That might be possible for some specialized packages, but not forf all
> > of them.
> 
> >> When a user installs a package from a package archive, the category
> >> chosen by the author is presented as the default choice, and can be
> >> overridden by the user.
> >
> > If the category is not fixed, I'm not sure I see the utility of having
> > such categories at all in the custom file.
> 
> My idea about the category was to use it for grouping things into
> "topical files" inside emacs.d. Consider the following, fictional,
> example:

Thanks, but I think we may be miscommunicating.  A package can belong
to more than one category -- what do you propose to do in that case?

Re: A proposal for a friendlier Emacs

[Alexander Adolf]

Eli Zaretskii <eliz@gnu.org> writes:

> [...]
> Thanks, but I think we may be miscommunicating.  A package can belong
> to more than one category -- what do you propose to do in that case?

Let it have one and only one category, and as many tags as the package's
author wishes.

To my experience, whenever people say "I need more than one category",
the motivation is always to enable users to find the thing under several
search terms. Something which is conveniently achieved by
tags. Technically, the only difference between "category" and "tag" in
my proposal is that special semantics are attached to the "category"
(determines which init file stuff goes into), whereas no semantics are
attached to "tag". When searching, a package hosting website (or a
client thereof) would of course match on both, categories and tags.

Also, classifications (like ontologies in general) are not
context-free. In a wider context, such as e.g. Emacs, the
classifications "email", and "web" might be useful. In a list of
web-browser plugins, a "web" category would hardly make sense. Likewise
for "email" in a list of plugins for an email client.

By means of example, below a random short-list of packages on ELPA, with
fictional category, and tags assigned by my humble self:

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 package        category  tags                                                     
───────────────────────────────────────────────────────────────────────────────────
 ada-mode       progn     ada, programming, fontification, navigation, indentation 
 adaptive-wrap  text      wrap, visual, long-lines                                 
 arbitools      games     chess, tournamet, report, logging                        
 wpuzzle        games     text, puzzle, scarbble, words                            
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Searching for "text" in this set, would deliver adaptive-wrap, and
wpuzzle as the results.

And yes, assigning a single category only to a non-trivial thing is
essentially an arbitrary act. Think of when you last browsed archives of
TV or cinematic content on different platforms. One and the same piece
of content goes down as "romance" on one platform, and as "comedy" on
another one. Hence, again to my experience, it is pointless to let a
community choose the category; the discussion will never end. Let
someone who can claim some sort of authority over the thing (e.g. its
author, or its publisher) take his/her arbitrary decision what the
category is.


Cheers,

  --alexander

Re: A proposal for a friendlier Emacs

[Eli Zaretskii]

> From: Alexander Adolf <alexander.adolf@condition-alpha.com>
> Cc: rms@gnu.org, emacs-devel@gnu.org
> Date: Fri, 25 Sep 2020 16:43:44 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > [...]
> > Thanks, but I think we may be miscommunicating.  A package can belong
> > to more than one category -- what do you propose to do in that case?
> 
> Let it have one and only one category, and as many tags as the package's
> author wishes.

Why does it matter whether we call it "category" or "tags".  The
important part is what the user thinks about a package.  And a single
package can satisfy several different needs.

So I think the idea of categorization that assumes a single category
per package is basically unworkable, because it's too restrictive, and
won't stand the test of time.

Re: A proposal for a friendlier Emacs

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Why does it matter whether we call it "category" or "tags".  The
  > important part is what the user thinks about a package.  And a single
  > package can satisfy several different needs.

  > So I think the idea of categorization that assumes a single category
  > per package is basically unworkable, because it's too restrictive, and
  > won't stand the test of time.

I agree.

In any case, the implementation of this doesn't need to make an assumption
about how many categorizations a package can have.


-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: A proposal for a friendlier Emacs

[Alexander Adolf]

[-- Attachment #1: Type: text/plain, Size: 2270 bytes --]

Richard Stallman <rms@gnu.org> writes:

> [...]
>   > Why does it matter whether we call it "category" or "tags".  The
>   > important part is what the user thinks about a package.  And a single
>   > package can satisfy several different needs.
>
>   > So I think the idea of categorization that assumes a single category
>   > per package is basically unworkable, because it's too restrictive, and
>   > won't stand the test of time.
>
> I agree.
>
> In any case, the implementation of this doesn't need to make an assumption
> about how many categorizations a package can have.
> [...]

It seems I was talking about possible technical solutions instead of
semantics, which appears to have gotten us into confusion.

My intent was to attach one new concept to any given package in the
repository. This concept would define the "init configuration topic" of
the package, so as to allow Custom code to auto-generate an init file
for that topic, and collect the config for all packages of that topic in
this init file.

In this thread, Eli has suggested a second concept to be attached to a
package, which is a (virtually) unbounded list of words and terms, which
would be matched against search terms users employ to find a package for
their needs.

I would hence view these as two distinct concepts, serving distinct
purposes. The "init configuration topic" concept is chiefly technical
information to partition init code into smaller units. The "unbounded
word list" concept is chiefly UX information as it is used to improve
search results' relevance.

Note that I have deliberately shied away from choosing any labels for
either of the concepts, under which they would be used in a vocabulary
or user interface (such as for instance "tag" or "category").

While I see Eli's suggestion as a worthwhile addition (as we appear to
be debating the metadata data model of the package repository), my
intent was to use the concept I described to enable a new approach to
Custom handling init files.

So I don't see the two concepts as mutually exclusive, competing, or
otherwise in conflict. The could very nicely coexist, or be adopted
independently of each other. Just let's not mix them up; that's all.


Many thanks and looking forward to your thoughts,

  --alexander

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 899 bytes --]

Re: A proposal for a friendlier Emacs

[Eli Zaretskii]

> From: Alexander Adolf <alexander.adolf@condition-alpha.com>
> Cc: emacs-devel@gnu.org
> Date: Tue, 29 Sep 2020 19:08:14 +0200
> 
> My intent was to attach one new concept to any given package in the
> repository. This concept would define the "init configuration topic" of
> the package, so as to allow Custom code to auto-generate an init file
> for that topic, and collect the config for all packages of that topic in
> this init file.

For a single package, assigning some category to it would work.  But
as soon as you want to have several packages in the same category,
this breaks, because one can group packages differently by assigning
them to different categories.

For example, one can assign CC Mode to the category "programming
languages", then it will be in the same category as perl.el, python.el
and fortran.el.  But someone else might decide to assign CC Mode to
the category "indentation", in which case it will be in the same
category with indent.el, text.el, etc.  And if the same person
sometimes regards it as PL and sometimes as "indentation", they will
have the same package in more than one init file.

Do you see the problem I had in mind?

Re: A proposal for a friendlier Emacs

[Alexander Adolf]

Eli Zaretskii <eliz@gnu.org> writes:

> [...]
> For example, one can assign CC Mode to the category "programming
> languages", then it will be in the same category as perl.el, python.el
> and fortran.el.
> [...]

Where does this assignment happen, on the user's local machine or on the
package repository website (or yet another place?), what semantics are
associated with that assignment, and how are these semantics exposed to
the user?

> Do you see the problem I had in mind?

Maybe, depending on your take on my questions above.


  --alexander

Re: A proposal for a friendlier Emacs

[Eli Zaretskii]

> From: Alexander Adolf <alexander.adolf@condition-alpha.com>
> Cc: rms@gnu.org, emacs-devel@gnu.org
> Date: Wed, 30 Sep 2020 22:40:10 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > [...]
> > For example, one can assign CC Mode to the category "programming
> > languages", then it will be in the same category as perl.el, python.el
> > and fortran.el.
> > [...]
> 
> Where does this assignment happen, on the user's local machine or on the
> package repository website (or yet another place?), what semantics are
> associated with that assignment, and how are these semantics exposed to
> the user?

I don't know.  It's the semantics you proposed, so you know what you
had in mind.  However, I don't see how that could matter, because the
problem is a fundamental one, and doesn't depend on the semantics of
the category.

Re: A proposal for a friendlier Emacs

[Alexander Adolf]

Hello Eli,

Eli Zaretskii <eliz@gnu.org> writes:

> [...] 
>> > For example, one can assign CC Mode to the category "programming
>> > languages", then it will be in the same category as perl.el, python.el
>> > and fortran.el.
>> > [...]
>> 
>> Where does this assignment happen, on the user's local machine or on the
>> package repository website (or yet another place?), what semantics are
>> associated with that assignment, and how are these semantics exposed to
>> the user?
>
> I don't know.  It's the semantics you proposed, so you know what you
> had in mind.  However, I don't see how that could matter, because the
> problem is a fundamental one, and doesn't depend on the semantics of
> the category.

It seems I'm trying to be too abstract to get things across. Let me try
to approach it from the solution space:

1. On the ELPA package repository, a new attribute would be added to the
   package database. The attribute type would be based on string, with
   restrictions suited to make the value usable as a filename. For each
   new package uploaded to ELPA, the author would be encouraged to fill
   in a value for the new attribute.

2. When a new package is installed locally, the Emacs user would be
   prompted under which headline or keyword he wants the package's
   config to be added to the init files. The value of the new ELPA
   attribute would offered as the default choice at the prompt.

3. With the value chosen by the user in the previous step, Custom would
   look for a file named ~/.emacs.d/setup-<user-chosen-value>.el, and
   create it if it doesn't already exist. Custom would then search that
   file for a section for the new package (using some magic-comment
   convention as I for instance described in my earlier post). If a
   section already exists, job done. If no section for the new package
   exists, Custom would create one, and fill in the default init code
   for the package (as defined by the package author in the package's
   documentation). If there is no init code to insert, Custom would just
   insert an empty magic-comment section for the new package.


From what I understood of your comments, you seem to claim that local
users choosing different names in step #2 would cause a problem?

Looking forward to your thoughts,

  --alexander

Re: A proposal for a friendlier Emacs

[Eli Zaretskii]

> From: Alexander Adolf <alexander.adolf@condition-alpha.com>
> Cc: rms@gnu.org, emacs-devel@gnu.org
> Date: Thu, 01 Oct 2020 18:13:50 +0200
> 
> >From what I understood of your comments, you seem to claim that local
> users choosing different names in step #2 would cause a problem?

No.  The problem I have in mind is that the user might decide to give
a package some keyword when first installed, but then the user might
wish to have the same package in another setup-KEYWORD.el file as
well, because it is useful as part of another group of packages.

Re: A proposal for a friendlier Emacs

[Stefan Monnier]

>> >From what I understood of your comments, you seem to claim that local
>> users choosing different names in step #2 would cause a problem?
> No.  The problem I have in mind is that the user might decide to give
> a package some keyword when first installed, but then the user might
> wish to have the same package in another setup-KEYWORD.el file as
> well, because it is useful as part of another group of packages.

For that there would be tags.  There's no sane way to duplicate the
settings of a package in two or more different places, which is why we
can't use the "tags" for that, so we'd introduce a second
classification which would come with the restriction that for this
classification a given package can only belong to one "category".

We already have some of that in our `lisp` subdirectory where some
packages are placed in `emacs-lisp` and others in `vc`, ...


        Stefan

Re: A proposal for a friendlier Emacs

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Alexander Adolf <alexander.adolf@condition-alpha.com>,  rms@gnu.org,
>   emacs-devel@gnu.org
> Date: Thu, 01 Oct 2020 12:49:39 -0400
> 
> >> >From what I understood of your comments, you seem to claim that local
> >> users choosing different names in step #2 would cause a problem?
> > No.  The problem I have in mind is that the user might decide to give
> > a package some keyword when first installed, but then the user might
> > wish to have the same package in another setup-KEYWORD.el file as
> > well, because it is useful as part of another group of packages.
> 
> For that there would be tags.

That's not the problem, and tags are not the solution.

The problem is with the concept of having groups of packages that load
together, and whose customizations are on a single .el file.  Once a
package can belong to more than one such group (and there will be such
packages), this concept breaks.

Anyway, I've already said this several times, and since it doesn't
seem to help drive the point home, I will assume that I'm missing
something important here, or am otherwise confused, and will shut up
in this thread from now on.

Re: A proposal for a friendlier Emacs

[Stefan Monnier]

> The problem is with the concept of having groups of packages that load
> together, and whose customizations are on a single .el file.  Once a
> package can belong to more than one such group (and there will be such
> packages), this concept breaks.

It doesn't break, because you instead make it technically impossible for
a package to belong to two such "groups".  It's easy to do.


        Stefan

Re: A proposal for a friendlier Emacs

[Alexander Adolf]

Eli Zaretskii <eliz@gnu.org> writes:

> [...]
> No.  The problem I have in mind is that the user might decide to give
> a package some keyword when first installed, but then the user might
> wish to have the same package in another setup-KEYWORD.el file as
> well, because it is useful as part of another group of packages.

In that case, my idea would be that the user manually moves the block of
init code for the package in question (including magic comments) from
setup-A.el to setup-B.el.

I did _not_ have in mind that the user would be assigning any new
information (such as e.g. tags or categories) to the packages. My mental
model was that the packages "live" on ELPA, and are read-only as far the
Emacs user is concerned (as is the status-quo today).

In my model, the only purpose in life for the new attribute was to give
the init code block a default, initial place to store, and to allow the
user to override that place at package installation time.

As time goes by, and things evolve, the user is of course free to rename
init files, move config blocks between them, create new init files and
move existing blocks there, etc. For as long as the magic comments are
retained (maybe there's a better way than magic comments even), Custom
would be able to find stuff, maintain the (custom-set-*) blocks, and
things would go smoothly.


Cheers,

  --alexander

Classifying packages

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

To distinguish topics, how about changing the Subject for
this discussion about categories or groups of packages.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: A proposal for a friendlier Emacs

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Finally, a few thoughts on packages and curation. As of this writing,
  > the combined list of ELPA, MELPA, and builtin packages of my current
  > emacs lists 5,065 packages. Chances are, whatever topic you're looking
  > at, there's more than one package. Which one is the best for my
  > purposes?

MELPA will not be included in whatever we set up.
MELPA does not cooperate with us, so we don't support it.

  > Users can do "add to favourites" for a module. When one
  > browses the modules, the number of users who faved it is shown. Not
  > perfect, but a rule-of-thumb estimate for a module's popularity.

A package repository web site could have a feature like this, but we
want access to the packages to be read-only and anonymous in the usual
case.  That is a matter of respecting privacy.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: A proposal for a friendlier Emacs

[Alexander Adolf]

Richard Stallman <rms@gnu.org> writes:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>   > Finally, a few thoughts on packages and curation. As of this writing,
>   > the combined list of ELPA, MELPA, and builtin packages of my current
>   > emacs lists 5,065 packages. Chances are, whatever topic you're looking
>   > at, there's more than one package. Which one is the best for my
>   > purposes?
>
> MELPA will not be included in whatever we set up.
> MELPA does not cooperate with us, so we don't support it.

No worries, I was only trying to make the point that there is a large
number of packages out there, and that there is a non-negligible chance
that there will be more than a single package for each use-case.

Let's evolve ELPA according to what we, the community agree upon, and
the other package archives may follow if they choose.

>   > Users can do "add to favourites" for a module. When one
>   > browses the modules, the number of users who faved it is shown. Not
>   > perfect, but a rule-of-thumb estimate for a module's popularity.
>
> A package repository web site could have a feature like this, but we
> want access to the packages to be read-only and anonymous in the usual
> case.  That is a matter of respecting privacy.
> [...]

Fully agree. Favourites can only be granted by registered users of a
package repository web site. But there's no reason the reading of the
favourites count of a package couldn't be read-only and anonymous. This
is exactly how CPAN works, btw.


Cheers,

  --alexander

Re: A proposal for a friendlier Emacs

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Fully agree. Favourites can only be granted by registered users of a
  > package repository web site. But there's no reason the reading of the
  > favourites count of a package couldn't be read-only and anonymous.

I am not certain what "favourites count" means.  If it refers to a feature
whereby users can optionally tell the repository that they like the package,
I have nothing against it.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: A proposal for a friendlier Emacs

[Alexander Adolf]

Richard Stallman <rms@gnu.org> writes:

> [...]
>   > Fully agree. Favourites can only be granted by registered users of a
>   > package repository web site. But there's no reason the reading of the
>   > favourites count of a package couldn't be read-only and anonymous.
>
> I am not certain what "favourites count" means.

The number of registered repository users who have clicked on "add to
favourites" for the package in question. Think of it as Facebook likes
("X people like this").

> If it refers to a feature whereby users can optionally tell the
> repository that they like the package, I have nothing against it.
> [...]

Exactly that.


  --alexander

RE: A proposal for a friendlier Emacs

[Drew Adams]

> Think of it as Facebook likes

(Perhaps enough reason not to go there. ;-))

> > If it refers to a feature whereby users can optionally tell the
> > repository that they like the package, I have nothing against it.
> 
> Exactly that.

Should we really conflate the set of Emacs
users with "registered repository users"?

Re: A proposal for a friendlier Emacs

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > > If it refers to a feature whereby users can optionally tell the
  > > > repository that they like the package, I have nothing against it.
  > > 
  > > Exactly that.

  > Should we really conflate the set of Emacs
  > users with "registered repository users"?

I don't follow you.  You seem to be criticizing something
but I don't know what.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

RE: A proposal for a friendlier Emacs

[Drew Adams]

> > Should we really conflate the set of Emacs
> > users with "registered repository users"?
> 
> I don't follow you.  You seem to be criticizing
> something but I don't know what.

(A question is criticism now?)

I responded to this:

  The number of registered repository users who
  have clicked on "add to favourites" for the
  package in question.

I questioned whether "registered repository users"
is a good proxy for Emacs users.  Presumably not
all Emacs users will be registered repository
users (?).  Maybe the difference needs to be
taken into account in some way?  A question.

(No, I don't know what a "registered repository
user" is.  But AFAIK I'm not one, and I am an
Emacs user.)

Re: A proposal for a friendlier Emacs

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > > Should we really conflate the set of Emacs
  > > > users with "registered repository users"?
  > > 
  > > I don't follow you.  You seem to be criticizing
  > > something but I don't know what.

  > (A question is criticism now?)

That question is a criticism because it uses the word "conflate".
That word asserts that something is a mistake.

I did not know know what it was that allegedly is a mistake.
But you explained: it was this:

  The number of registered repository users who
  have clicked on "add to favourites" for the
  package in question.

  > I questioned whether "registered repository users"
  > is a good proxy for Emacs users.

No, you suggested I was "conflating" things, and that
is always unkind.

As for whether it is a good proxy, I don't know and
I said nothing about that.


-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

RE: A proposal for a friendlier Emacs

[Drew Adams]

>   > > > Should we really conflate the set of Emacs
>   > > > users with "registered repository users"?
>   > >
>   > > I don't follow you.  You seem to be criticizing
>   > > something but I don't know what.
> 
>   > (A question is criticism now?)
> 
> That question is a criticism because it uses the word
> "conflate".  That word asserts that something is a mistake.

No, it does not assert that.

  Verb: conflate  kun'fleyt

  Add together different elements
  "The colours conflate well";
  - blend, flux, mix, commingle, immix, fuse,
    coalesce, meld, combine, merge

https://www.wordwebonline.com/search.pl?w=conflate

Other definitions (they all say the same thing):

https://duckduckgo.com/?q=conflate+definition&t=brave&ia=definition

In logic/reasoning, conflation _can_ give rise to
confusion, but it need not do so.

https://en.wikipedia.org/wiki/Conflation

My point was precisely to raise the question of
whether conflating the set of Emacs users with
the set of Emacs users who are registered
somewhere can lead to misunderstanding or
confusion.  Perhaps it can mislead, and if so
won't necessarily help clarity.

If we're looking for a poll/sampling, is this a
helpful way to represent Emacs users in general?
Frankly, I don't know.  But I recognize that
there's a conflation - the two sets aren't the
same.

I could have used the word "identify".  I used
"conflate" to underline that they're different.
But both "identify" (in the sense of declaring
that two things are the same) and "conflate"
fit here.  As does your use of "proxy".

> I did not know know what it was that allegedly
> is a mistake.  But you explained: it was this:
> 
>   The number of registered repository users who
>   have clicked on "add to favourites" for the
>   package in question.
> 
>   > I questioned whether "registered repository users"
>   > is a good proxy for Emacs users.
> 
> No, you suggested I was "conflating" things, and that
> is always unkind.

No, see above.  I'm sorry you misunderstood it
as unkind.

> As for whether it is a good proxy, I don't know
> and I said nothing about that.

That was my question: how good a proxy is it?
I don't know.  But I know it's a proxy, and I
raised the question of how good it is, whether
we should take the one for the other, here.
I don't know what the best proxy for this might be.

Re: A proposal for a friendlier Emacs

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > No, it does not assert that.

  >   Verb: conflate  kun'fleyt

  >   Add together different elements
  >   "The colours conflate well";
  >   - blend, flux, mix, commingle, immix, fuse,
  >     coalesce, meld, combine, merge

I am surprised.  The only meaning I have ever seen
is to mistakenly identify things that are different.
If that is not what you meant, then I apologize for the mistake.

Here's what you wrote:

>   > > > Should we really conflate the set of Emacs
>   > > > users with "registered repository users"?

Can you state your intended meaning in different words?

  > If we're looking for a poll/sampling, is this a
  > helpful way to represent Emacs users in general?
  > Frankly, I don't know.  But I recognize that
  > there's a conflation - the two sets aren't the
  > same.

Each time you use the word conflate, I am unsure what meaning you have
in mind.  What operation with these two sets that you mean?  Taking
the union of them?  Treating then as intersubstitutable?  Something else?






-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

RE: A proposal for a friendlier Emacs

[Drew Adams]

> > Should we really conflate the set of Emacs
> > users with "registered repository users"?
> 
> Can you state your intended meaning in different words?

You asked Alexander what he meant by "favourites
count".  He replied that it's "the number of
registered repository user who have clicked on
'add to favorites' for the package in question."

I questioned how good counting such "likes" by 
registered users would be as a measure of how
much users in general might appreciate a given
package.

That's all.  Is counting registered users who
"like" a package a good proxy for its appreciation
by users in general?  Dunno.

> > If we're looking for a poll/sampling, is this a
> > helpful way to represent Emacs users in general?
> > Frankly, I don't know.  But I recognize that
> > there's a conflation - the two sets aren't the
> > same.
> 
> Each time you use the word conflate, I am unsure what meaning you have
> in mind.  What operation with these two sets that you mean?  Taking
> the union of them?  Treating then as intersubstitutable?  Something else?

Using one set as a proxy for the other.

One is a subset of the other.  Is such a sample
a good proxy?  Maybe; I don't know.  But the two
should at least be distinguished, not considered
the same (identified/conflated).  That's all.

Use whatever word you like, as I expect you now
understand.  If you want, consider the question
only as pointing out that not all users will
register and then "like" something.

As for the difference, I take it from Alexander:
"Favourites can only be granted by registered users
of a package repository web site."  Those are the
(only) "votes" that would be counted with this
approach, IIUC.
___

(Also, you've often expressed the view that, while
polls can be useful, we also want detailed feedback
and reasoned arguments before deciding something.
I agree with that.)

Re: A proposal for a friendlier Emacs

[Jean Louis]

* Richard Stallman <rms@gnu.org> [2020-09-28 06:50]:
> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> 
>   > No, it does not assert that.
> 
>   >   Verb: conflate  kun'fleyt
> 
>   >   Add together different elements
>   >   "The colours conflate well";
>   >   - blend, flux, mix, commingle, immix, fuse,
>   >     coalesce, meld, combine, merge
> 
> I am surprised.  The only meaning I have ever seen
> is to mistakenly identify things that are different.
> If that is not what you meant, then I apologize for the mistake.

That is why, there shall be function in Emacs to look up words in
dictionaries.

Jean

Re: A proposal for a friendlier Emacs

[Eli Zaretskii]

> Date: Tue, 29 Sep 2020 01:03:07 +0300
> From: Jean Louis <bugs@gnu.support>
> Cc: alexander.adolf@condition-alpha.com, Drew Adams <drew.adams@oracle.com>,
>  emacs-devel@gnu.org
> 
> >   > No, it does not assert that.
> > 
> >   >   Verb: conflate  kun'fleyt
> > 
> >   >   Add together different elements
> >   >   "The colours conflate well";
> >   >   - blend, flux, mix, commingle, immix, fuse,
> >   >     coalesce, meld, combine, merge
> > 
> > I am surprised.  The only meaning I have ever seen
> > is to mistakenly identify things that are different.
> > If that is not what you meant, then I apologize for the mistake.
> 
> That is why, there shall be function in Emacs to look up words in
> dictionaries.

You are suggesting that we have "conflate" in our Glossary?

Re: A proposal for a friendlier Emacs

[Stefan Monnier]

> You are suggesting that we have "conflate" in our Glossary?

I think more useful would be something like a `flyread-mode` which flags
those words that I will misinterpret.  `jit-lock-register` should make
that very easy.


        Stefan

Re: A proposal for a friendlier Emacs

[Jean Louis]

* Eli Zaretskii <eliz@gnu.org> [2020-09-29 05:33]:
> > Date: Tue, 29 Sep 2020 01:03:07 +0300
> > From: Jean Louis <bugs@gnu.support>
> > Cc: alexander.adolf@condition-alpha.com, Drew Adams <drew.adams@oracle.com>,
> >  emacs-devel@gnu.org
> > 
> > >   > No, it does not assert that.
> > > 
> > >   >   Verb: conflate  kun'fleyt
> > > 
> > >   >   Add together different elements
> > >   >   "The colours conflate well";
> > >   >   - blend, flux, mix, commingle, immix, fuse,
> > >   >     coalesce, meld, combine, merge
> > > 
> > > I am surprised.  The only meaning I have ever seen
> > > is to mistakenly identify things that are different.
> > > If that is not what you meant, then I apologize for the mistake.
> > 
> > That is why, there shall be function in Emacs to look up words in
> > dictionaries.
> 
> You are suggesting that we have "conflate" in our Glossary?

I suggest that there shall be visible, exposed function to lookup
words in dictionaries.

Emacs words or technical words in info should be easily findable in
glossary.

Difference between dictionaries and glossary:

Glossary

* Overview of noun glossary

The noun glossary has 1 sense (first 1 from tagged texts)
1. (3) glossary, gloss -- (an alphabetical list of technical terms in some specialized field of knowledge; usually published as an appendix to a text on that field)

Dictionary

* Overview of noun dictionary

The noun dictionary has 1 sense (first 1 from tagged texts)
1. (52) dictionary, lexicon -- (a reference book containing an alphabetical list of words with information about them)

Re: A proposal for a friendlier Emacs

[Eli Zaretskii]

On September 29, 2020 7:16:13 AM GMT+03:00, Jean Louis <bugs@gnu.support> wrote:
> * Eli Zaretskii <eliz@gnu.org> [2020-09-29 05:33]:
> > > Date: Tue, 29 Sep 2020 01:03:07 +0300
> > > From: Jean Louis <bugs@gnu.support>
> > > Cc: alexander.adolf@condition-alpha.com, Drew Adams
> <drew.adams@oracle.com>,
> > >  emacs-devel@gnu.org
> > > 
> > > >   > No, it does not assert that.
> > > > 
> > > >   >   Verb: conflate  kun'fleyt
> > > > 
> > > >   >   Add together different elements
> > > >   >   "The colours conflate well";
> > > >   >   - blend, flux, mix, commingle, immix, fuse,
> > > >   >     coalesce, meld, combine, merge
> > > > 
> > > > I am surprised.  The only meaning I have ever seen
> > > > is to mistakenly identify things that are different.
> > > > If that is not what you meant, then I apologize for the mistake.
> > > 
> > > That is why, there shall be function in Emacs to look up words in
> > > dictionaries.
> > 
> > You are suggesting that we have "conflate" in our Glossary?
> 
> I suggest that there shall be visible, exposed function to lookup
> words in dictionaries.



That could be a useful new feature, but it is a tangent in the context of this discussion.

Btw, we have a similar functionality built in: try "M-s M-w" after marking a word or a phrase.

Re: A proposal for a friendlier Emacs

[Jean Louis]

* Eli Zaretskii <eliz@gnu.org> [2020-09-29 08:36]:
> > I suggest that there shall be visible, exposed function to lookup
> > words in dictionaries.

> That could be a useful new feature, but it is a tangent in the context of this discussion.
> 
> Btw, we have a similar functionality built in: try "M-s M-w" after
> marking a word or a phrase.

I did not know, that is good to search words online, it does not
really define words, it searches for whatever is marked, that is
good. It is not a dictionary though.

I prefer if Emacs would be using GNU Dico software, as part of GNU system:
https://puszcza.gnu.org.ua/software/dico/ as a built in feature, so if
dico exists, it could use it, if it does not exist, it could then
provide www fallback.

If local dictionary server serves, dico would be using local
dictionaries, if not, it would be using online dictionaries.

There are hard coded settings for Google Chrome browser in {M-x customize-group RET browse-url RET}
in Emacs, so why not have hard coded settings for dictionary features.

Re: A proposal for a friendlier Emacs

[Eli Zaretskii]

> Date: Tue, 29 Sep 2020 08:45:46 +0300
> From: Jean Louis <bugs@gnu.support>
> Cc: emacs-devel@gnu.org, alexander.adolf@condition-alpha.com,
>   rms@gnu.org, drew.adams@oracle.com
> 
> > Btw, we have a similar functionality built in: try "M-s M-w" after
> > marking a word or a phrase.
> 
> I did not know, that is good to search words online, it does not
> really define words, it searches for whatever is marked, that is
> good. It is not a dictionary though.

First, what it does by default has an advantage of being able to look
up phrases, not just words.

And second, you can customize eww-search-prefix in a way that will
search dictionaries: for example Google does that when the query
begins with "define:"

> I prefer if Emacs would be using GNU Dico software, as part of GNU system:
> https://puszcza.gnu.org.ua/software/dico/ as a built in feature, so if
> dico exists, it could use it, if it does not exist, it could then
> provide www fallback.
> 
> If local dictionary server serves, dico would be using local
> dictionaries, if not, it would be using online dictionaries.
> 
> There are hard coded settings for Google Chrome browser in {M-x customize-group RET browse-url RET}
> in Emacs, so why not have hard coded settings for dictionary features.

That is a completely separate issue: you are talking about setting up
the dictionary _servers_ to which the client will talk, something that
IMO should be entirely up to the Emacs users.

Re: A proposal for a friendlier Emacs

[Jean Louis]

* Eli Zaretskii <eliz@gnu.org> [2020-09-29 17:25]:
> > Date: Tue, 29 Sep 2020 08:45:46 +0300
> > From: Jean Louis <bugs@gnu.support>
> > Cc: emacs-devel@gnu.org, alexander.adolf@condition-alpha.com,
> >   rms@gnu.org, drew.adams@oracle.com
> > 
> > > Btw, we have a similar functionality built in: try "M-s M-w" after
> > > marking a word or a phrase.
> > 
> > I did not know, that is good to search words online, it does not
> > really define words, it searches for whatever is marked, that is
> > good. It is not a dictionary though.
> 
> First, what it does by default has an advantage of being able to look
> up phrases, not just words.
> 
> And second, you can customize eww-search-prefix in a way that will
> search dictionaries: for example Google does that when the query
> begins with "define:"

Similar like that, yet, looking up word online would be a fallback.
First would need to come local dictionaries, as majority of the world
is offline. A student in East Africa is regarding online use very
disabled. Majority of schools in this world are poor schools. Reality
is quite different globally. Offline dictionaries need no network. If
offline dictionaries are not available, then online would be used,
that is done automatically by dict/dico clients, and then if none of
clients exists, then the online lookup could ask for !define word in
Duckduck.com or similar.

> > There are hard coded settings for Google Chrome browser in {M-x customize-group RET browse-url RET}
> > in Emacs, so why not have hard coded settings for dictionary features.
> 
> That is a completely separate issue: you are talking about setting up
> the dictionary _servers_ to which the client will talk, something that
> IMO should be entirely up to the Emacs users.

Yes, analogous is the Google Chrome browser, it is up to user to
install it, but settings are available in Emacs. It would be up to
user to install dict server, but settings could be, if possible, put in
Emacs.

Re: A proposal for a friendlier Emacs

[Arthur Miller]

Jean Louis <bugs@gnu.support> writes:

> * Eli Zaretskii <eliz@gnu.org> [2020-09-29 17:25]:
>> > Date: Tue, 29 Sep 2020 08:45:46 +0300
>> > From: Jean Louis <bugs@gnu.support>
>> > Cc: emacs-devel@gnu.org, alexander.adolf@condition-alpha.com,
>> >   rms@gnu.org, drew.adams@oracle.com
>> > 
>> > > Btw, we have a similar functionality built in: try "M-s M-w" after
>> > > marking a word or a phrase.
>> > 
>> > I did not know, that is good to search words online, it does not
>> > really define words, it searches for whatever is marked, that is
>> > good. It is not a dictionary though.
>> 
>> First, what it does by default has an advantage of being able to look
>> up phrases, not just words.
>> 
>> And second, you can customize eww-search-prefix in a way that will
>> search dictionaries: for example Google does that when the query
>> begins with "define:"
>
> Similar like that, yet, looking up word online would be a fallback.
> First would need to come local dictionaries, as majority of the world
> is offline. A student in East Africa is regarding online use very
> disabled. Majority of schools in this world are poor schools. Reality
> is quite different globally. Offline dictionaries need no network. If
> offline dictionaries are not available, then online would be used,
> that is done automatically by dict/dico clients, and then if none of
> clients exists, then the online lookup could ask for !define word in
> Duckduck.com or similar.
>
>> > There are hard coded settings for Google Chrome browser in {M-x customize-group RET browse-url RET}
>> > in Emacs, so why not have hard coded settings for dictionary features.
>> 
>> That is a completely separate issue: you are talking about setting up
>> the dictionary _servers_ to which the client will talk, something that
>> IMO should be entirely up to the Emacs users.
>
> Yes, analogous is the Google Chrome browser, it is up to user to
> install it, but settings are available in Emacs. It would be up to
> user to install dict server, but settings could be, if possible, put in
> Emacs.

I would like to have an easy to loookup dictionary from Lisp posibly for
automatically translating of GUI ites. I have always thought of creating
an sqlite database of "programming" dictionary where some common gui
items are put together like (file, menu, cut, copy, paste, etc) and
indexed for use in programms. In a Lisp program sqlite is not even
needed.

I have no idea how those dictionary servers work, never used one, but
maybe it is something applications could use to translate software too;
at least simpler part like some common GUI stuff.

Re: A proposal for a friendlier Emacs

[Jean Louis]

* Arthur Miller <arthur.miller@live.com> [2020-10-20 16:08]:
> I would like to have an easy to loookup dictionary from Lisp posibly for
> automatically translating of GUI ites. I have always thought of creating
> an sqlite database of "programming" dictionary where some common gui
> items are put together like (file, menu, cut, copy, paste, etc) and
> indexed for use in programms. In a Lisp program sqlite is not even
> needed.

You mean very simple and common words? 

If there are not too many, Lisp structure is enough, that is how I am
using it in some CGI scripts for multi languages.

Emacs Lisp package could then just find if such word exists, if it
does not exist, it could ask you to translate, and it could fetch
definitions from dictionary to help you.

There is wordnut package for looking up into Wordnet dictionary, it is
free as in freedom dictionary, it is fast, and pressing enter on words
leads you to new words.

> I have no idea how those dictionary servers work, never used one, but
> maybe it is something applications could use to translate software too;
> at least simpler part like some common GUI stuff.

Not automatically if you mean that, it is not translation word by word.

Re: A proposal for a friendlier Emacs

[Arthur Miller]

Jean Louis <bugs@gnu.support> writes:

> * Arthur Miller <arthur.miller@live.com> [2020-10-20 16:08]:
>> I would like to have an easy to loookup dictionary from Lisp posibly for
>> automatically translating of GUI ites. I have always thought of creating
>> an sqlite database of "programming" dictionary where some common gui
>> items are put together like (file, menu, cut, copy, paste, etc) and
>> indexed for use in programms. In a Lisp program sqlite is not even
>> needed.
>
> You mean very simple and common words? 
Yes, like: File, Open, Close, Cut, Copy, Paste ...

> If there are not too many, Lisp structure is enough, that is how I am
> using it in some CGI scripts for multi languages.
I know; sqlite db is a bit more portable; think C++; but for Lisp
programs a hash map or even list are fine.

> Emacs Lisp package could then just find if such word exists, if it
> does not exist, it could ask you to translate, and it could fetch
> definitions from dictionary to help you.
Long time ago, I was thinking of such a dictionary for programming only;
so there would be a db with 'en_US' column and a column for each locale
that has translation. That is very simplified dictionary I had in mind.
But while reading discussion about dictionaries on this list, I am just
wondering if one could look up words from a GUI directly in a say
English-Someotherlang dictionary, without have a specialized kind of
dictionary.

> There is wordnut package for looking up into Wordnet dictionary, it is
> free as in freedom dictionary, it is fast, and pressing enter on words
> leads you to new words.
Always wanted to look up wordnet, but never got to it; one day ....

>> I have no idea how those dictionary servers work, never used one, but
>> maybe it is something applications could use to translate software too;
>> at least simpler part like some common GUI stuff.
>
> Not automatically if you mean that, it is not translation word by word.
I know; it is never word by word. 

I mean one could write program to look up a list of words; maybe
save it and then use the saved translation as a base for a human to
finish the translation?

Re: A proposal for a friendlier Emacs

[Jean Louis]

* Arthur Miller <arthur.miller@live.com> [2020-10-27 07:32]:
> Jean Louis <bugs@gnu.support> writes:
> 
> > * Arthur Miller <arthur.miller@live.com> [2020-10-20 16:08]:
> >> I would like to have an easy to loookup dictionary from Lisp posibly for
> >> automatically translating of GUI ites. I have always thought of creating
> >> an sqlite database of "programming" dictionary where some common gui
> >> items are put together like (file, menu, cut, copy, paste, etc) and
> >> indexed for use in programms. In a Lisp program sqlite is not even
> >> needed.
> >
> > You mean very simple and common words? 
> Yes, like: File, Open, Close, Cut, Copy, Paste ...

There are those /usr/share/locale .po files  to be used with GNU
gettext.

NAME
	gettext - translate message

SYNOPSIS
	gettext [OPTION] [[TEXTDOMAIN] MSGID]
	gettext [OPTION] -s [MSGID]...

DESCRIPTION
	The gettext  program translates  a natural  language message
	into the user's language, by looking up the translation in a
	message catalog.

https://www.emacswiki.org/emacs/Gettext

See:
https://www.gnu.org/software/gettext/manual/html_node/PO-Mode.html

So gettext is for you. You may already get all that what you want, you
can translate user interfaces quickly and get translations from
existing other software by using it.

Are there any Emacs or completion packages for gettext? 

> > If there are not too many, Lisp structure is enough, that is how I am
> > using it in some CGI scripts for multi languages.
> I know; sqlite db is a bit more portable; think C++; but for Lisp
> programs a hash map or even list are fine.

If database is for single user then Lisp data in files is fine. If for
multiple users then what if they write to database in the same file.

Emacs should have database built-in such as gdbm the GNU database,
or other similar databases optionally with ./configure options.

I am using the PostgreSQL dynamic module for database management:
https://github.com/anse1/emacs-libpq and this works well and fine,
independent of Emacs package. I think original pg package broke with
the new release of PostgreSQL, so I had to look for
solution. Developers are looking how to include this dynamic module
into GNU ELPA, they are willing so far.

and there is SQLLite dynamic module:
https://github.com/pekingduck/emacs-sqlite3-api

There is GDBM tool named: gdbmtool for which one could write an Emacs
package and use it that way indirectly. I wonder why such packages do
not exist after so many years, in general, why some simple database is
not built in.

> > There is wordnut package for looking up into Wordnet dictionary, it is
> > free as in freedom dictionary, it is fast, and pressing enter on words
> > leads you to new words.
> Always wanted to look up wordnet, but never got to it; one day ....

In many GNU/Linux distributions there are packages with Wordnet. Emacs
package is wordnut, works fine also in connection with helm, and
Wordnet is freely licensed.

Wordnet projects are huge:
https://en.wikipedia.org/wiki/WordNet#Global_WordNet_Association

And include allegedly more than 200 languages, but licenses are often
non-free. Emacs packages work without any middle server.

> I mean one could write program to look up a list of words; maybe
> save it and then use the saved translation as a base for a human to
> finish the translation?

get the gettext

-- 
Jean Louis

Re: A proposal for a friendlier Emacs

[Alfred M. Szmidt]

It would be unrealistic for each program to include a copy of the
English dictionary.  For looking up words specific to Emacs, there
already is a function to do that: search-emacs-glossary

Re: A proposal for a friendlier Emacs

[Jean Louis]

Function to look up word definitions would use GNU dico of installed, or dict software, or www solution as fallback.

Dico and dict would use local dictionary or remote one as fallback.

Function should be accessible by key and menu and it would act on word at point or region.

Accessible dictionary through Emacs would empower users.

No need to ship dictionary with Emacs.

That function exists for glossary is great. Yet to help user, it should be integrated in reading of info or otherwise made better known, as what is not known or integrated is not as useful.

Emacs info could for example tell somewhere at beginning that technical words could be looked up by using M-x search-emacs-glossary



On September 29, 2020 7:19:02 AM UTC, ams@gnu.org wrote:
>It would be unrealistic for each program to include a copy of the
>English dictionary.  For looking up words specific to Emacs, there
>already is a function to do that: search-emacs-glossary

Re: A proposal for a friendlier Emacs

[Alfred M. Szmidt]

I think it is safe to assume that those who can read the Emacs Manual
also are able to read English -- or for that matter look up basic
words in a dictionary.

   Emacs info could for example tell somewhere at beginning that
   technical words could be looked up by using M-x
   search-emacs-glossary

It could certainly do that, we already define words that using the
@dfn{} command -- though you cannot know if a word is a definition or
not based on the generated Info output.  

Would you like to suggest a patch?

Re: A proposal for a friendlier Emacs

[Jean Louis]

On September 29, 2020 8:23:26 AM UTC, ams@gnu.org wrote:
>I think it is safe to assume that those who can read the Emacs Manual
>also are able to read English -- or for that matter look up basic
>words in a dictionary.

I am referring to general dictionary access, that is not relevant only to Emacs Manual.

Cannot help with patches, sorry.

My concept for dictionary I have sent.

Re: A proposal for a friendlier Emacs

[Jean Louis]

* Alfred M. Szmidt <ams@gnu.org> [2020-09-29 11:24]:
> I think it is safe to assume that those who can read the Emacs Manual
> also are able to read English -- or for that matter look up basic
> words in a dictionary.
> 
>    Emacs info could for example tell somewhere at beginning that
>    technical words could be looked up by using M-x
>    search-emacs-glossary

It just opens the glossary, it does not allow the look up as action. 

On the Android/LineageOS/Replicant systems, many actions, documents
are connected. For example when there is Openkeychain installed, it
modifies the long click, which opens Cut, Copy, Paste, and offers
"Encrypt" function. It looks like tooltip for actions. In similar
fashion, one could put a cursor on a word, activate function and look
it up in dictionaries.

I am using Emacs for reading, for example there is popular book Tom
Sawyer that I recommend to many to read, now they moe on the unknown
word and sooner or later they give up reading due to misunderstanding.
If words can be quickly defined, they can be understood.

Look up function built in into Emacs would Emacs excellent teaching
or learning tool.

Re: A proposal for a friendlier Emacs

[Eli Zaretskii]

> Date: Tue, 29 Sep 2020 07:16:13 +0300
> From: Jean Louis <bugs@gnu.support>
> Cc: rms@gnu.org, alexander.adolf@condition-alpha.com,
>   drew.adams@oracle.com, emacs-devel@gnu.org
> 
> I suggest that there shall be visible, exposed function to lookup
> words in dictionaries.

We already have "M-s M-w".

Adding a specialized command to query DICT servers will also be a
welcome addition.

Re: A proposal for a friendlier Emacs

[Juri Linkov]

>> I suggest that there shall be visible, exposed function to lookup
>> words in dictionaries.
>
> We already have "M-s M-w".
>
> Adding a specialized command to query DICT servers will also be a
> welcome addition.

Anyone can already enable this feature easily in own init file with:

(when (require 'dictem nil t)
  ;; (setq dictem-server "dict.org")
  ;; (setq dictem-server "mova.org")
  (setq dictem-server "localhost")
  (setq dictem-port   "2628")
  (dictem-initialize)
  (global-set-key "\M-s\M-d" 'dictem-run-search))

Re: A proposal for a friendlier Emacs

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: Jean Louis <bugs@gnu.support>,  alexander.adolf@condition-alpha.com,
>   rms@gnu.org,  drew.adams@oracle.com,  emacs-devel@gnu.org
> Date: Wed, 30 Sep 2020 21:36:52 +0300
> 
> > We already have "M-s M-w".
> >
> > Adding a specialized command to query DICT servers will also be a
> > welcome addition.
> 
> Anyone can already enable this feature easily in own init file with:
> 
> (when (require 'dictem nil t)
>   ;; (setq dictem-server "dict.org")
>   ;; (setq dictem-server "mova.org")
>   (setq dictem-server "localhost")
>   (setq dictem-port   "2628")
>   (dictem-initialize)
>   (global-set-key "\M-s\M-d" 'dictem-run-search))

That only works on Posix systems.  We should have a DICT client
implemented in Emacs Lisp, perhaps based on dictionary.el.

Re: A proposal for a friendlier Emacs

[Gregory Heytings via Emacs development discussions.]

>
> That only works on Posix systems.  We should have a DICT client 
> implemented in Emacs Lisp, perhaps based on dictionary.el.
>

What is missing in dictionary.el?  It is implemented in Emacs Lisp, I just 
tried it (apt-get install elpa-dictionary), and it seems to work fine. 
The default server is dict.org, port 2628, which gives access to all 
dictionaries available in Debian.

Re: A proposal for a friendlier Emacs

[Robert Pluim]

>>>>> On Wed, 30 Sep 2020 19:50:39 +0000, Gregory Heytings via "Emacs development discussions." <emacs-devel@gnu.org> said:

    >> 
    >> That only works on Posix systems.  We should have a DICT client
    >> implemented in Emacs Lisp, perhaps based on dictionary.el.
    >> 

    Emacs> What is missing in dictionary.el?  It is implemented in Emacs Lisp, I
    Emacs> just tried it (apt-get install elpa-dictionary), and it seems to work
    Emacs> fine. The default server is dict.org, port 2628, which gives access to
    Emacs> all dictionaries available in Debian.

Iʼve been using it for <checks notes> 2 decades, and itʼs fine. We
could ask the author if he's willing to have it incorporated in emacs.

Robert
-- 

Re: A proposal for a friendlier Emacs

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  Gregory Heytings <ghe@sdf.org>
> Date: Thu, 01 Oct 2020 09:27:56 +0200
> 
> Iʼve been using it for <checks notes> 2 decades, and itʼs fine.

Are you using the version from Git, or the last released one?

> We could ask the author if he's willing to have it incorporated in
> emacs.

That would be a good idea, I think.  Except that I'm not sure there's
only one author...

Re: A proposal for a friendlier Emacs

[Robert Pluim]

>>>>> On Thu, 01 Oct 2020 16:10:50 +0300, Eli Zaretskii <eliz@gnu.org> said:

    >> From: Robert Pluim <rpluim@gmail.com>
    >> Cc: Eli Zaretskii <eliz@gnu.org>,  Gregory Heytings <ghe@sdf.org>
    >> Date: Thu, 01 Oct 2020 09:27:56 +0200
    >> 
    >> Iʼve been using it for <checks notes> 2 decades, and itʼs fine.

    Eli> Are you using the version from Git, or the last released one?

The last released one from melpa: dictionary-20191111.446

    >> We could ask the author if he's willing to have it incorporated in
    >> emacs.

    Eli> That would be a good idea, I think.  Except that I'm not sure there's
    Eli> only one author...

$ git log|grep Author|sort|uniq|wc -l
8

so it should not be too hard to figure out. Then again, that repo has
only 59 commits stretching back 20 years, many of them of the type
'imported version x from tarball', so the authorship info is likely
not very accurate.

Robert
-- 

Re: A proposal for a friendlier Emacs

[Eli Zaretskii]

> Date: Wed, 30 Sep 2020 19:50:39 +0000
> From: Gregory Heytings <ghe@sdf.org>
> cc: emacs-devel@gnu.org
> 
> > That only works on Posix systems.  We should have a DICT client 
> > implemented in Emacs Lisp, perhaps based on dictionary.el.
> 
> What is missing in dictionary.el?

Maybe nothing, I don't know.  I didn't yet have enough time to take a
good look at it.

Re: A proposal for a friendlier Emacs

[Jean Louis]

* Gregory Heytings via "Emacs development discussions. <emacs-devel@gnu.org> [2020-09-30 22:51]:
> 
> > 
> > That only works on Posix systems.  We should have a DICT client
> > implemented in Emacs Lisp, perhaps based on dictionary.el.
> > 
> 
> What is missing in dictionary.el?  It is implemented in Emacs Lisp, I just
> tried it (apt-get install elpa-dictionary), and it seems to work fine. The
> default server is dict.org, port 2628, which gives access to all
> dictionaries available in Debian.

I have now asked Torsten the author if he would be willing to give
that package for official Emacs.

Jean

Re: A proposal for a friendlier Emacs

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > What is missing in dictionary.el?  It is implemented in Emacs Lisp, I just 
  > tried it (apt-get install elpa-dictionary), and it seems to work fine. 

How does it work?

  > The default server is dict.org, port 2628,

We should not refer people to someone else's server as the first,
recommended way of looking up words in a dictionary.

The first option should be referring to a dictionary
on your own machine.  It should support the formats that
are widely used.

I don't mind if it also has the ability to talk to servers,
but that should be the last resort, not the first choice!


-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: A proposal for a friendlier Emacs

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: eliz@gnu.org, emacs-devel@gnu.org
> Date: Thu, 01 Oct 2020 23:51:10 -0400
> 
>   > What is missing in dictionary.el?  It is implemented in Emacs Lisp, I just 
>   > tried it (apt-get install elpa-dictionary), and it seems to work fine. 
> 
> How does it work?

Similar to smtpmail.el: connects to a server (whose URL is
customizable) and talks to it using the DICT protocol.

>   > The default server is dict.org, port 2628,
> 
> We should not refer people to someone else's server as the first,
> recommended way of looking up words in a dictionary.
> 
> The first option should be referring to a dictionary
> on your own machine.  It should support the formats that
> are widely used.

We could implement an initialization function that tests whether
there's a local DICT server, and if there is, use that.  That could be
triggered by a special value of the defcustom that names the server.

Re: A proposal for a friendlier Emacs

[Jean Louis]

* Juri Linkov <juri@linkov.net> [2020-09-30 22:19]:
> >> I suggest that there shall be visible, exposed function to lookup
> >> words in dictionaries.
> >
> > We already have "M-s M-w".
> >
> > Adding a specialized command to query DICT servers will also be a
> > welcome addition.
> 
> Anyone can already enable this feature easily in own init file with:
> 
> (when (require 'dictem nil t)
>   ;; (setq dictem-server "dict.org")
>   ;; (setq dictem-server "mova.org")
>   (setq dictem-server "localhost")
>   (setq dictem-port   "2628")
>   (dictem-initialize)
>   (global-set-key "\M-s\M-d" 'dictem-run-search))

I cannot find dictem package, where is it?

Jean

Re: A proposal for a friendlier Emacs

[Eli Zaretskii]

> Date: Thu, 1 Oct 2020 17:13:53 +0300
> From: Jean Louis <bugs@gnu.support>
> Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org,
>  alexander.adolf@condition-alpha.com, drew.adams@oracle.com, rms@gnu.org
> 
> > (when (require 'dictem nil t)
> >   ;; (setq dictem-server "dict.org")
> >   ;; (setq dictem-server "mova.org")
> >   (setq dictem-server "localhost")
> >   (setq dictem-port   "2628")
> >   (dictem-initialize)
> >   (global-set-key "\M-s\M-d" 'dictem-run-search))
> 
> I cannot find dictem package, where is it?

  https://github.com/cheusov/dictem
  https://sourceforge.net/projects/dictem/files/dictem/dictem-1.0.4/

dictionary.el could be included in main stream Emacs - Re: A proposal for a friendlier Emacs

[Jean Louis]

Dear Eli,

Torsten have just agreed to be willing to include the dictionary.el in
the main stream Emacs.

Can you help on the process?

Jean

========= copy of message =========

Subject: Re: Kind request for dictionary.el
To: Jean Louis <bugs A-T gnu.support>
From: Torsten Hilbrich <torsten A-T myrkr.in-berlin.de>
Date: Thu, 1 Oct 2020 16:52:10 +0200

On 01.10.20 16:19, Jean Louis wrote:
> Hallo Torsten,
> 
> Wärest Du interesiert dein dictionary.el in den Emacs direct zu
> integrieren?
> 
> Wir haben an der Emacs devel mailing Liste darüber diskutiert, jetzt
> wissen wir dass Du es schon gemacht hast. Ich wäre sehr dankbar, denn
> ich würde es gern unter Look up word menu item integrieren.
> 
> Bitte schreibe mir, es wäre gut dass Du mitmachst.
> 
> Jean
> 

Ich habe keine Einwände gegen diesen Vorschlag.

Just in case also in English:

I have no objections to this plan.

	Torsten

PS: I had to use a different from header to answer to avoid some SPF
problems.

Re: dictionary.el could be included in main stream Emacs - Re: A proposal for a friendlier Emacs

[Eli Zaretskii]

> Date: Thu, 1 Oct 2020 19:05:23 +0300
> From: Jean Louis <bugs@gnu.support>
> Cc: juri@linkov.net, emacs-devel@gnu.org,
>   alexander.adolf@condition-alpha.com, drew.adams@oracle.com,
>   rms@gnu.org
> 
> Torsten have just agreed to be willing to include the dictionary.el in
> the main stream Emacs.
> 
> Can you help on the process?

Sure.

Thorsten, I see you already have copyright assignment on file for
Emacs, and AFAICT contributions by others are very small and don't
require assignments.  So we are fine from the legal paperwork POV.

The next question would be how would you prefer to go about the
inclusion?  There are several alternatives; the most convenient for us
would be to move the dictionary.el development into the Emacs Git
repository.  Would that be okay with you (we will give you write
access to the Emacs Git in this case, of course)?

If this is not acceptable, we can discuss other options.

Also, I think we will want to make some changes in the package.  One
is to require 'cl-lib', not 'cl' (the latter causes a warning in
recent versions of Emacs).  Another change was discussed here
recently: to add a feature that at first invocation detects whether a
local DICT server is available, and use that, falling back to a remote
server.  This could be triggered by a special value of the
dictionary-server defcustom, for example, in which case we would want
to make that special value the default.

TIA (and thanks for developing this package over the years).

Re: dictionary.el could be included in main stream Emacs - Re: A proposal for a friendlier Emacs

[Torsten Hilbrich]

On 02.10.20 13:40, Eli Zaretskii wrote:
> Thorsten, I see you already have copyright assignment on file for
> Emacs, and AFAICT contributions by others are very small and don't
> require assignments.  So we are fine from the legal paperwork POV.
> 
> The next question would be how would you prefer to go about the
> inclusion?  There are several alternatives; the most convenient for us
> would be to move the dictionary.el development into the Emacs Git
> repository.  Would that be okay with you (we will give you write
> access to the Emacs Git in this case, of course)?
> 
> If this is not acceptable, we can discuss other options.

The inclusion into the Emacs Git Repository works fine for me.

> Also, I think we will want to make some changes in the package.  One
> is to require 'cl-lib', not 'cl' (the latter causes a warning in
> recent versions of Emacs).  Another change was discussed here
> recently: to add a feature that at first invocation detects whether a
> local DICT server is available, and use that, falling back to a remote
> server.  This could be triggered by a special value of the
> dictionary-server defcustom, for example, in which case we would want
> to make that special value the default.
> 
> TIA (and thanks for developing this package over the years).

These changes sound okay.

	Torsten

Re: A proposal for a friendlier Emacs

[Juri Linkov]

>> (when (require 'dictem nil t)
>>   ;; (setq dictem-server "dict.org")
>>   ;; (setq dictem-server "mova.org")
>>   (setq dictem-server "localhost")
>>   (setq dictem-port   "2628")
>>   (dictem-initialize)
>>   (global-set-key "\M-s\M-d" 'dictem-run-search))
>
> I cannot find dictem package, where is it?

It's not packaged as an Emacs package, but can be installed on GNU/Linux
with this command:

  sudo apt install dictem

However, if dictionary.el doesn't require an external dict client,
this is even better.

Ideally, all features of dictem should be merged to dictionary.el.

Re: A proposal for a friendlier Emacs

[Jean Louis]

* Richard Stallman <rms@gnu.org> [2020-09-28 06:50]:
> Each time you use the word conflate, I am unsure what meaning you have
> in mind.  What operation with these two sets that you mean?  Taking
> the union of them?  Treating then as intersubstitutable?  Something else?

Use that example, and imagine how a users are faced with so many words
that user does not know, is going to become unsure. You said it
well. That is why each word that one reads or writes in Emacs, should
be easily looked up for its definition.

And I mean each word, not just special or technical words. GNU has
GCIDE and dictionary servers, there is Wordnut, there are hacker
dictionaries and abbreviations.

Re: A proposal for a friendlier Emacs

[Jean Louis]

* Nicola Manca <nicola.manca85@gmail.com> [2020-09-17 04:50]:
> Dear all,
> 
> following the recent discussions about a startup wizard and modern-mode I
> try to provide a suggestion.
> 
> What about having a startup screen, opening only if no .emacs or other user
> configuration file is found just saying (the text is just an example):
> 
> Welcome!
> This is the first time you run Emacs, please choose how to proceed:
> 
> [] Go Vanilla!
>   (standard defaults, no customizations)
> 
> [] Start Configuration Wizard
>   (set-up your .emacs configuration file interactively)
> 
> [] Try Emacs in enhanced-mode
>   (run with a predefined configuration showing emacs potential)
> 
> After this screen, the normal Emacs splash screen could me
> presented.

No please.

I would not like that be included in Emacs. I am installing so many
times Emacs, I need no installation wizards, finally if it is proposal
for "new users" then nothing will help but reading tutorials, as words
such as "startup screen" would mean nothing special to such user. User
reads description of a package, and finds out it is text editor, so
expects to edit text, and not to think of defaults.

How would new user know what are "standard defaults"?! I do not find it friendlier.

Why a new user need to think of "customizations"?! I cannot see it is
friendlier. Emacs as such now is very friendly software.

Why would "Configuration Wizard" be friendlier? I don't find it
friendlier, especially considering that more citizens in many
countries find words like "wizard" not appealing, due to their
beliefs.

Sorry I cannot see how interactive setup would make it friendlier, as
that brings users to learn to walk through the interactive setup,
action alone is making it harder, not friendlier. Person is faced with
difficulties, yet installed a text editor.

What would mean "enhanced mode" under supposedly friendlier approach,
I do not know. I would think that each person likes enhanced modes, be
it for this or that, and I do not know why it should run with
predefined configuration and cannot see how is it friendlier.

I find it very friendly on *GNU Emacs* buffer:

Welcome to GNU Emacs, one component of the GNU/Linux operating system.

Emacs Tutorial	        Learn basic keystroke commands
Emacs Guided Tour	Overview of Emacs features at gnu.org
View Emacs Manual	View the Emacs manual using Info
Absence of Warranty	GNU Emacs comes with ABSOLUTELY NO WARRANTY
Copying Conditions	Conditions for redistributing and changing Emacs
Ordering Manuals	Purchasing printed copies of manuals

Most friendly feature is that Emacs Tutorial is offered as
first. Nothing else matters.

To make Emacs friendlier, one could make more translations of the
tutorial and include maybe additional Tutorials, I do believe that
people like to learn.

Tutorial works well, I have given Emacs to staff members who after
short time could already start translating from English to local
languages.

And I am accessing Emacs so many times without .emacs, so I do not
know why should I be faced with blocks in the workflow.

-- 
Thanks,
Jean Louis

Re: A proposal for a friendlier Emacs

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > Welcome!
  > > This is the first time you run Emacs, please choose how to proceed:
  > > 
  > > [] Go Vanilla!
  > >   (standard defaults, no customizations)
  > > 
  > > [] Start Configuration Wizard
  > >   (set-up your .emacs configuration file interactively)
  > > 
  > > [] Try Emacs in enhanced-mode
  > >   (run with a predefined configuration showing emacs potential)
  > > 
  > > After this screen, the normal Emacs splash screen could me
  > > presented.

  > No please.

  > I would not like that be included in Emacs. I am installing so many
  > times Emacs, I need no installation wizards,

I understand that you have no need for this -- but why do you object to it?
It would only require you to type a couple of characters.

Indeed, you could surely bypass that step by copying a certain
pre-prepared .emacs file into each new installation.  That file
would indicate that the choice had already been made.

  > Why would "Configuration Wizard" be friendlier? I don't find it
  > friendlier, especially considering that more citizens in many
  > countries find words like "wizard" not appealing, due to their
  > beliefs.

Please distinguish the behavior of the feature from its name.

If we have this feature, we don't HAVE to call it "wizard."  But many
programs use the term "wizard" for such things -- it seems to be a
standard term.  I would expect that computer users have got used to
it.


-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: A proposal for a friendlier Emacs

[Alfred M. Szmidt]

     > > Welcome!
     > > This is the first time you run Emacs, please choose how to proceed:
     > > 
     > > [] Go Vanilla!
     > >   (standard defaults, no customizations)
     > > 
     > > [] Start Configuration Wizard
     > >   (set-up your .emacs configuration file interactively)
     > > 
     > > [] Try Emacs in enhanced-mode
     > >   (run with a predefined configuration showing emacs potential)
     > > 
     > > After this screen, the normal Emacs splash screen could me
     > > presented.

     > No please.

     > I would not like that be included in Emacs. I am installing so many
     > times Emacs, I need no installation wizards,

   I understand that you have no need for this -- but why do you object to it?
   It would only require you to type a couple of characters.

In the above example, you need to get through _two_ screens, one is to
quit the "configuration screen", and then you need to quit the splash
screen before you can use emacs.  It is unfriendly to the user to
demand them to spend time, even the slightest, to configure Emacs
before they can use it -- today there is a nice balance.

If the "configuration screen" would be part of the splash screen which
I have suggested, or behave as the splash screen (i.e., you can simply
switch buffers or press q or similar to get to the *scratch* buffer)
then this wouldn't be a problem.

Re: A proposal for a friendlier Emacs

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > In the above example, you need to get through _two_ screens, one is to
  > quit the "configuration screen", and then you need to quit the splash
  > screen before you can use emacs.  It is unfriendly to the user to
  > demand them to spend time, even the slightest, to configure Emacs
  > before they can use it -- today there is a nice balance.

We can surely take account of this point when designing the little
details.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: A proposal for a friendlier Emacs

[Jean Louis]

* Richard Stallman <rms@gnu.org> [2020-09-22 06:40]:
> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> 
>   > > Welcome!
>   > > This is the first time you run Emacs, please choose how to proceed:
>   > > 
>   > > [] Go Vanilla!
>   > >   (standard defaults, no customizations)
>   > > 
>   > > [] Start Configuration Wizard
>   > >   (set-up your .emacs configuration file interactively)
>   > > 
>   > > [] Try Emacs in enhanced-mode
>   > >   (run with a predefined configuration showing emacs potential)
>   > > 
>   > > After this screen, the normal Emacs splash screen could me
>   > > presented.
> 
>   > No please.
> 
>   > I would not like that be included in Emacs. I am installing so many
>   > times Emacs, I need no installation wizards,
> 
> I understand that you have no need for this -- but why do you object
> to it?

It is changing defaults and facing me and also the new users with
complexities, in general, it gives an active obligation to the user
versus the splash screen that does not disturb the user in the
workflow.

Emacs in my opinion does not need configuration assistant that user
has to confront, as user installed Emacs for text editing purposes,
nothing is required, and nobody needs to have .emacs to edit with
Emacs, and I do it so often exactly that way, especially on new user
accounts setup for those users. I need no .emacs in general as Emacs
is self contained with its defaults.

Traditionally I would avoid using "wizard", rather "assistant" like
GNOME is using it, see:
https://en.wikipedia.org/wiki/Wizard_(software)

I would not mind if there exists package that is included inside of
Emacs that can be started from splash screen and that is called "Emacs
Configuration Assistant" and that guides a person through
configuration options. Especially if such a package also speaks to the
user and guides the user's mouse pointer or cursor and actually
assists the user as artificial intelligence.

Such functions should not confront the user, as that then becomes
attention priority for the user, and user has obligation to do, even
if it is to press the key to quit the configuration assistant, that is
too much.

No editor is confronting me with the request for action, I want to
launch an editor, and be able to open a file or open buffer and start
typing text. As user I am not supposed to think about enhancing
whatever, or customization.

If such functions of a "Emacs Configuration Assistant" are separate
package that is shown on the splash screen, even if it is in the Help
menu, I would not mind of it.

> It would only require you to type a couple of characters.

I would find it irritating to be asked as user to do anything, as user
I have opened the editor with purpose to edit text, and not to play
around with configurations. Finally, as user, I do not need
configurations.

As we speak of customization of configuration files, the function M-x
customize could be made friendlier, by providing definitions of the
terms that may not be easy to understand to users.

Would the M-x customize be made friendlier in the sense that basics of
editing options are separated from advanced demands, then that would
also solve pretty much the issues of "Emacs Configuration Assistant"
(not wizard). 

Example:

Electricity		    Electric behavior for self inserting keys.

And then there is no definition for electricity, I know it is fun, but
to make it friendlier, it would be good to have a glossary and that
user can move to the word and get the definition of that word.

Killing		    Killing and yanking commands.

It is funny and I like it, and need no changes, but to make it
friendlier, one would need to provide definitions of such words in the
customize, as for some users it could cause misunderstoods which could
cause the person to give up.

Editing		    Basic text editing facilities.
Text		    Support for editing text files.

Those two customization groups differ in their description only
slightly if at all, so that is what is not friendly, as user I would
not see easy difference. If I click on "Editing" I am referring to
editing of text, if I click on Text, I am referring to editing of
text. It is not friendly enough. If I click on Text, I am then faced
with Ps Print which does not really refer to text only but to PS files
and printing, and I am faced with Printing Utilities group, and
validation of XML which does not necessarily fit into simple text
mindset.

None new function called "Emacs Configuration Wizard" which I would
rather call "Emacs Configuration Assistant" can help in describing
those customization groups better, or providing user with better
understanding.

What will make Emacs friendlier is better understanding of its
functions and usage.

Understanding is what makes friends.

Thus if Emacs Configuration Wizard, or however it may be called is
helping user to understand how Emacs works, that is very nice and
helpful, but let the user decide to launch it, and not launch it
because there is no .emacs or because user is launching Emacs first
time. Put it in Help menu or on splash screen that it can be launched,
just as I can open file from splash screen, but do not need to open
the file. I am also not actively ask to participate in opening of
files, or directories, which is basic text editing function, so I
should not be asked to decide about whatever configurations and funny
things to do.

As LISP system, I do expect Emacs to have better assistive functions,
it should speak, move the cursor and mouse pointer automatically to
point out where is that menu item, it should open menues automatically
and point to the user, even though Emacs does have all those assistive
functions more than any other piece of software, some new audio-visual
functions could make it friendlier.

> Indeed, you could surely bypass that step by copying a certain
> pre-prepared .emacs file into each new installation.  That file
> would indicate that the choice had already been made.

Myself, I do have my personal .emacs, but I have many physical
computers, and servers and my staff members and children and whoever
is facing whatever text and notes writing, and I do not find it
friendly to be faced with whatever answering on configuration wizards,
especially I would not like anybody else like programmer deciding for
me that I should configure some software, if it functions well without
configuration. On any other computer and user account that is not my
personal, I am using Emacs without .emacs as I expect text editor not
to ask user anything special for its functions to work.

Jean

Re: A proposal for a friendlier Emacs

[Eli Zaretskii]

> Date: Tue, 22 Sep 2020 09:24:37 +0300
> From: Jean Louis <bugs@gnu.support>
> Cc: nicola.manca85@gmail.com, emacs-devel@gnu.org
> 
> > I understand that you have no need for this -- but why do you object
> > to it?
> 
> It is changing defaults and facing me and also the new users with
> complexities, in general, it gives an active obligation to the user
> versus the splash screen that does not disturb the user in the
> workflow.

You personally may find it annoying, but please keep in mind that many
applications nowadays offer to take the user through a similar process
first time the application is started after installation.  So I
presume many newcomers to Emacs will not be surprised by that, and
maybe will even expect something like that.

> Emacs in my opinion does not need configuration assistant that user
> has to confront, as user installed Emacs for text editing purposes,

Emacs is not just a text editor, it is a large and rich environment
for many tasks that require text-processing.  Treating it just as a
program for inserting, deleting, and searching text runs the risk of
missing the point of this discussion.

> Editing		    Basic text editing facilities.
> Text		    Support for editing text files.
> 
> Those two customization groups differ in their description only
> slightly if at all, so that is what is not friendly, as user I would
> not see easy difference. If I click on "Editing" I am referring to
> editing of text, if I click on Text, I am referring to editing of
> text.

Actually, "Text" is not (or at least should not be) about editing
text, it is about editing human-readable text (as opposed to
programming language text, for example).  We should probably make that
clear in the group description, and also make sure the packages in
that category are indeed all about human-readable text.

Thank you for pointing out this point of potential confusion.

Re: A proposal for a friendlier Emacs

[Jean Louis]

On September 22, 2020 2:10:00 PM UTC, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Tue, 22 Sep 2020 09:24:37 +0300
>> From: Jean Louis <bugs@gnu.support>
>> Cc: nicola.manca85@gmail.com, emacs-devel@gnu.org
>> 
>> > I understand that you have no need for this -- but why do you
>object
>> > to it?
>> 
>> It is changing defaults and facing me and also the new users with
>> complexities, in general, it gives an active obligation to the user
>> versus the splash screen that does not disturb the user in the
>> workflow.
>
>You personally may find it annoying, but please keep in mind that many
>applications nowadays offer to take the user through a similar process
>first time the application is started after installation.  So I
>presume many newcomers to Emacs will not be surprised by that, and
>maybe will even expect something like that.

To make a survey online today is not so hard and not so expensive, turn advertising on and ask people to answer few questions in exchange for free software download, you can give them Emacs as award.

You would ask before the download if they consider themselves beginners, intermediate or advance computer users, if they know what is teddy editor and how often they just such, and then you would ask about the need and demand for wizards in neutral question making, if they would like to be faced with questions, and you would also ask if they understand exactly those questions which you intend to implement in Emacs.

It can be done in one day even on street in front of computer shops, with few people you could reach 100 survey results, give lemonade in exchange or offer free Emacs CD with free software system.

Then evaluate the results, and you will find the beginner's needs and their wants, which will make all the difference between the subjective opinion (ours) and the objective public demand.

Re: A proposal for a friendlier Emacs

[Eli Zaretskii]

> Date: Tue, 22 Sep 2020 14:22:03 +0000
> CC: rms@gnu.org, nicola.manca85@gmail.com, emacs-devel@gnu.org
> From: Jean Louis <bugs@gnu.support>
> 
> >You personally may find it annoying, but please keep in mind that many
> >applications nowadays offer to take the user through a similar process
> >first time the application is started after installation.  So I
> >presume many newcomers to Emacs will not be surprised by that, and
> >maybe will even expect something like that.
> 
> To make a survey online today is not so hard and not so expensive, turn advertising on and ask people to answer few questions in exchange for free software download, you can give them Emacs as award.

It isn't a matter of opinion, it is a matter of fact: many
applications offer to configure them the first time you invoke them.
I know because I install them.  Any other user will see the same.

That is all I was saying: that this kind of feature is quite
widespread nowadays.

Re: A proposal for a friendlier Emacs

[Jean Louis]

It is subjective fact taking. I am so much software addicted as before, and have installed many applications over last years and did not get nearly that opinion, I have seen none such in part years. I remember that from before 1999 in Windows sphere.

Which software specifically you installed with such assistants?


On September 22, 2020 2:31:49 PM UTC, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Tue, 22 Sep 2020 14:22:03 +0000
>> CC: rms@gnu.org, nicola.manca85@gmail.com, emacs-devel@gnu.org
>> From: Jean Louis <bugs@gnu.support>
>> 
>> >You personally may find it annoying, but please keep in mind that
>many
>> >applications nowadays offer to take the user through a similar
>process
>> >first time the application is started after installation.  So I
>> >presume many newcomers to Emacs will not be surprised by that, and
>> >maybe will even expect something like that.
>> 
>> To make a survey online today is not so hard and not so expensive,
>turn advertising on and ask people to answer few questions in exchange
>for free software download, you can give them Emacs as award.
>
>It isn't a matter of opinion, it is a matter of fact: many
>applications offer to configure them the first time you invoke them.
>I know because I install them.  Any other user will see the same.
>
>That is all I was saying: that this kind of feature is quite
>widespread nowadays.

Re: A proposal for a friendlier Emacs

[Eli Zaretskii]

> Date: Tue, 22 Sep 2020 14:52:07 +0000
> CC: rms@gnu.org, nicola.manca85@gmail.com, emacs-devel@gnu.org
> From: Jean Louis <bugs@gnu.support>
> 
> Which software specifically you installed with such assistants?

Almost every application you install on a smartphone does that.

Re: A proposal for a friendlier Emacs

[Jean Louis]

* Eli Zaretskii <eliz@gnu.org> [2020-09-22 18:35]:
> > Date: Tue, 22 Sep 2020 14:52:07 +0000
> > CC: rms@gnu.org, nicola.manca85@gmail.com, emacs-devel@gnu.org
> > From: Jean Louis <bugs@gnu.support>
> > 
> > Which software specifically you installed with such assistants?
> 
> Almost every application you install on a smartphone does that.

Those on smartphone are not comparable directly to Emacs as text
editor, and I use free software applications on smart phone and here
is the summary:

- none text editor that I use on smart phones have any configuration
  needs, I hope you don't mean permission configurations. I am using
  Editor from F-Droid, then Markor, µnote

- applications that require network username and password setups, such
  as K-9 for email or Conversations for XMPP chat are offering such
  configuration walk throughs, that is understandable. Same type of
  assistive features could be implemented in Emacs to make it
  friendlier.

- none application that functions without configuration is offering me
  configuration wizards.

Emacs works without configuration.

Thus does not need any configuration wizard.

There is no need for any username, password, hostname, web server
name, or similar, there is no need for any configuration that software
works. And that complicates life for those real users using Emacs
without .emacs.

I understand you think you are making it friendlier, and I endorse
that notion, I just think that assistance like that shall be packages
or functions inside of Emacs and not forced onto users, especially not
for reasons of not having .emacs file, and for reason to wrongly
assume that non-.emacs-ers are beginners.

Please also think on real users who don't use .emacs on multiple
computers, as I am real user who need Emacs without .emacs or wizards,
not just unnamed beginner, and I am promoting Emacs to new users too.

Those beginners in need of a wizard, did not make the notion they need
it. Few real users including me expressed that it is not necessary at
first launch.

Another thoughts, what is supposed to be done after the configuration
wizard have assumed that user is beginner because there is no .emacs
file and user pressed a key to choose one of the wizard options?

Is the wizard then, after asking the user about configuration,
supposed to make the .emacs file? As that way, the wizard is to
wizardry stop assuming that user is beginner, because wizard created
now the .emacs after user pressed a key to choose one of options, so
wizard wizardry made a user advanced user... :-) truly magic how it
works. 

Re: A proposal for a friendlier Emacs

[Eli Zaretskii]

> Date: Tue, 22 Sep 2020 19:03:55 +0300
> From: Jean Louis <bugs@gnu.support>
> Cc: rms@gnu.org, nicola.manca85@gmail.com, emacs-devel@gnu.org
> 
> > > Which software specifically you installed with such assistants?
> > 
> > Almost every application you install on a smartphone does that.
> 
> Those on smartphone are not comparable directly to Emacs as text
> editor

You are missing the point.  My point is that people nowadays are used
to applications that start like that.  They are therefore unlikely to
be surprised if Emacs does.

Whether this is appropriate for Emacs or not is a different question.
I understand your point -- no need to reiterate it so many times --
but many people here disagree with you.

> Emacs works without configuration.

Yes, it does.  The problem the "friendlier Emacs" proposal tries to
solve is how to help new users discover features they might want, but
which are disabled by default.  The assumption is that doing so will
help them start using Emacs more efficiently sooner.

> Please also think on real users who don't use .emacs on multiple
> computers, as I am real user who need Emacs without .emacs or wizards,
> not just unnamed beginner, and I am promoting Emacs to new users too.

You are not the only one who mentioned this aspect.  So this issue is
on the table, and will find its solution, this way or another.

> Another thoughts, what is supposed to be done after the configuration
> wizard have assumed that user is beginner because there is no .emacs
> file and user pressed a key to choose one of the wizard options?

The options the user selects will be saved for future sessions of this
user.

Re: A proposal for a friendlier Emacs

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > To make a survey online today is not so hard and not so expensive,
  > turn advertising on and ask people to answer few questions in
  > exchange for free software download, you can give them Emacs as
  > award.

We would not want to act pushy towards users, but we could find gentle
ways to invite them to answer questions anonymously.

However, in the absence of any real problem with having a
configuration wizard, we may as well do that.


-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: A proposal for a friendlier Emacs

[Jean Louis]

Configuration wizard is good for database setup, or network related setups, and situations where software as such is not usable without configuring it. Key me mention email software, it would be good to have such wizard for email or Gnus within Emacs. For connection to PostgreSQL it would be good as it would ask user fit username, hostname, ports, etc. For Tramp or for setting up some list of Tramp servers with some usernames and passwords it would make sense.

Emacs as such is usable without any configuration, thus wizard would do nothing good but irritate Emacs users, in my opinion, it would be programmer's capricious control over users, to force them to configure Emacs.

If beginner is considered new user, why a person new to Emacs should be forced to configure Emacs?! Especially if software functions as it is without any configuration. It is waste of time and would bring beginners into new misunderstandings. 

To include some general AI audio-video interactive assistant that helps with any function in Emacs, within Tutorial or outside, or to improve present describe- functions would be good, but not as force at first run.

In general it is bad to change the long standing policy that user need not have .emacs configuration, or to force the user to have such, and to undermine and tell the user and Emacs that such cannot be used without configuration.

Even worse is changing the established policy that Emacs launched without .emacs is run by beginners. Why would authors need to make such assumptions?

Is it established in the editor software in the world that if there is no editor configuration that user is beginner who need teaching on how to configure software that functions anyway fine without being configured? I don't think so and it is not logical.

We empower users by bringing better understanding to them and wizard idea is one such attempt, I just don't agree that it should be forced onto user by assuming that user is beginner who needs teaching if that person does not have Emacs configuration.

And myself I have used Emacs for years without any configuration and still use that way on 5 computers at home, and 4 servers on internet, and remote computers in other countries.

Re: A proposal for a friendlier Emacs

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > You personally may find it annoying, but please keep in mind that many
  > applications nowadays offer to take the user through a similar process
  > first time the application is started after installation.  So I
  > presume many newcomers to Emacs will not be surprised by that, and
  > maybe will even expect something like that.

If wr make it optional to run the configuration wizard, then the worst
annoyance it can cause is saying no, just once after each
installation.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: A proposal for a friendlier Emacs

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: bugs@gnu.support, nicola.manca85@gmail.com, emacs-devel@gnu.org
> Date: Tue, 22 Sep 2020 23:41:24 -0400
> 
>   > You personally may find it annoying, but please keep in mind that many
>   > applications nowadays offer to take the user through a similar process
>   > first time the application is started after installation.  So I
>   > presume many newcomers to Emacs will not be surprised by that, and
>   > maybe will even expect something like that.
> 
> If wr make it optional to run the configuration wizard, then the worst
> annoyance it can cause is saying no, just once after each
> installation.

Making it optional is indeed the way to go.