Re: Changes for emacs 28

Re: Changes for emacs 28

[Ergus]

Hi I have a set of question:

1) Could we add an option to enable choosing between the traditional
undo or undo-only + undo-redo? something like undo-redo-mode?

if (yes):

2) Where in the menubar-toolbar do you expect it should be added to be
enabled/disabled? Maybe with "Use Cua Keys".

3) Is it possible/should we: add a redo icon in the toolbar
conditionally when the mode is enabled?

else

4) I see a redo added in the menu-bar unconditionally... should we do
the same in the toolbar unconditionally?

Re: Changes for emacs 28

[Caio Henrique]

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

Ergus <spacibba@aol.com> writes:

> 4) I see a redo added in the menu-bar unconditionally... should we do
> the same in the toolbar unconditionally?

I tried adding it to the toolbar just to see how it would look like:


[-- Attachment #2: Redo added to toolbar --]
[-- Type: image/png, Size: 31100 bytes --]

[-- Attachment #3: Type: text/plain, Size: 1250 bytes --]


Maybe it takes too much horizontal space? I don't know.
___________
diff --git a/lisp/term/x-win.el b/lisp/term/x-win.el
index 42a6f4030e..fa87739c23 100644
--- a/lisp/term/x-win.el
+++ b/lisp/term/x-win.el
@@ -1396,6 +1396,7 @@ x-gtk-stock-map
     ("etc/images/save" . ("document-save" "gtk-save"))
     ("etc/images/saveas" . ("document-save-as" "gtk-save-as"))
     ("etc/images/undo" . ("edit-undo" "gtk-undo"))
+    ("etc/images/redo" . ("edit-redo" "gtk-redo"))
     ("etc/images/cut" . ("edit-cut" "gtk-cut"))
     ("etc/images/copy" . ("edit-copy" "gtk-copy"))
     ("etc/images/paste" . ("edit-paste" "gtk-paste"))
diff --git a/lisp/tool-bar.el b/lisp/tool-bar.el
index 7df1e28e06..ac8134dce6 100644
--- a/lisp/tool-bar.el
+++ b/lisp/tool-bar.el
@@ -259,6 +259,7 @@ tool-bar-setup
                               :label "Save")
   (define-key-after (default-value 'tool-bar-map) [separator-1] menu-bar-separator)
   (tool-bar-add-item-from-menu 'undo "undo" nil)
+  (tool-bar-add-item-from-menu 'undo-redo "redo" nil)
   (define-key-after (default-value 'tool-bar-map) [separator-2] menu-bar-separator)
   (tool-bar-add-item-from-menu (lookup-key menu-bar-edit-menu [cut])
                               "cut" nil :vert-only t)
___________

Re: Changes for emacs 28

[Eli Zaretskii]

> From: Caio Henrique <caiohcs0@gmail.com>
> Date: Thu, 10 Sep 2020 22:38:18 -0300
> Cc: Ricardo Wurmus <rekado@elephly.net>, Gregory Heytings <ghe@sdf.org>,
>  Drew Adams <drew.adams@oracle.com>, emacs-devel@gnu.org
> 
> > 4) I see a redo added in the menu-bar unconditionally... should we do
> > the same in the toolbar unconditionally?
> 
> I tried adding it to the toolbar just to see how it would look like:

Thanks, but please add a help-echo text for that button.  The menu
item perhaps could do without it, but not the tool-bar button.

Re: Changes for emacs 28

[Robert Pluim]

>>>>> On Fri, 11 Sep 2020 09:58:18 +0300, Eli Zaretskii <eliz@gnu.org> said:

    >> From: Caio Henrique <caiohcs0@gmail.com>
    >> Date: Thu, 10 Sep 2020 22:38:18 -0300
    >> Cc: Ricardo Wurmus <rekado@elephly.net>, Gregory Heytings <ghe@sdf.org>,
    >> Drew Adams <drew.adams@oracle.com>, emacs-devel@gnu.org
    >> 
    >> > 4) I see a redo added in the menu-bar unconditionally... should we do
    >> > the same in the toolbar unconditionally?
    >> 
    >> I tried adding it to the toolbar just to see how it would look like:

    Eli> Thanks, but please add a help-echo text for that button.  The menu
    Eli> item perhaps could do without it, but not the tool-bar button.

(enabling and looking at the toolbar for the first time in a decade)

Why have we got separate 'open new file' and 'open existing file'
buttons? You can open an existing one from the dialog that 'open new
file' pops up.

Robert

Re: Changes for emacs 28

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: Caio Henrique <caiohcs0@gmail.com>,  rekado@elephly.net,  ghe@sdf.org,
>   spacibba@aol.com,  drew.adams@oracle.com,  emacs-devel@gnu.org
> Date: Fri, 11 Sep 2020 15:57:31 +0200
> 
> Why have we got separate 'open new file' and 'open existing file'
> buttons?

Because most other applications have File->New and File->Open as
separate items.

> You can open an existing one from the dialog that 'open new file'
> pops up.

Yes, we Emacs veterans don't need both.  But the tool bar is not for
us.

Re: Changes for emacs 28

[Robert Pluim]

>>>>> On Fri, 11 Sep 2020 17:04:17 +0300, Eli Zaretskii <eliz@gnu.org> said:

    >> From: Robert Pluim <rpluim@gmail.com>
    >> Cc: Caio Henrique <caiohcs0@gmail.com>,  rekado@elephly.net,  ghe@sdf.org,
    >> spacibba@aol.com,  drew.adams@oracle.com,  emacs-devel@gnu.org
    >> Date: Fri, 11 Sep 2020 15:57:31 +0200
    >> 
    >> Why have we got separate 'open new file' and 'open existing file'
    >> buttons?

    Eli> Because most other applications have File->New and File->Open as
    Eli> separate items.

Hm, OK. Then if the goal is to save space we could remove the 'Save'
and 'Undo' text in the toolbar under Gnu/Linux (the toolbar on macOS
has only icons).

Robert

Re: Changes for emacs 28

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: caiohcs0@gmail.com,  rekado@elephly.net,  ghe@sdf.org,
>   spacibba@aol.com,  drew.adams@oracle.com,  emacs-devel@gnu.org
> Date: Fri, 11 Sep 2020 16:24:23 +0200
> 
> if the goal is to save space we could remove the 'Save'
> and 'Undo' text in the toolbar under Gnu/Linux (the toolbar on macOS
> has only icons).

Does the text come from Emacs?  I thought it comes from GTK (I see no
text on MS-Windows, either).

Re: Changes for emacs 28

[Caio Henrique]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Robert Pluim <rpluim@gmail.com>
>> Cc: caiohcs0@gmail.com,  rekado@elephly.net,  ghe@sdf.org,
>>   spacibba@aol.com,  drew.adams@oracle.com,  emacs-devel@gnu.org
>> Date: Fri, 11 Sep 2020 16:24:23 +0200
>> 
>> if the goal is to save space we could remove the 'Save'
>> and 'Undo' text in the toolbar under Gnu/Linux (the toolbar on macOS
>> has only icons).
>
> Does the text come from Emacs?  I thought it comes from GTK (I see no
> text on MS-Windows, either).

(setq tool-bar-style 'image)

That should do the trick for GTK. Maybe this should be its default value?

Re: Changes for emacs 28

[Robert Pluim]

>>>>> On Fri, 11 Sep 2020 13:12:05 -0300, Caio Henrique <caiohcs0@gmail.com> said:

    Caio> Eli Zaretskii <eliz@gnu.org> writes:
    >>> From: Robert Pluim <rpluim@gmail.com>
    >>> Cc: caiohcs0@gmail.com,  rekado@elephly.net,  ghe@sdf.org,
    >>> spacibba@aol.com,  drew.adams@oracle.com,  emacs-devel@gnu.org
    >>> Date: Fri, 11 Sep 2020 16:24:23 +0200
    >>> 
    >>> if the goal is to save space we could remove the 'Save'
    >>> and 'Undo' text in the toolbar under Gnu/Linux (the toolbar on macOS
    >>> has only icons).
    >> 
    >> Does the text come from Emacs?  I thought it comes from GTK (I see no
    >> text on MS-Windows, either).

    Caio> (setq tool-bar-style 'image)

    Caio> That should do the trick for GTK. Maybe this should be its default value?

I agree (but I donʼt use the toolbar :-) )

Re: Changes for emacs 28

[Caio Henrique]

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

Robert Pluim <rpluim@gmail.com> writes:

>>>>>> On Fri, 11 Sep 2020 13:12:05 -0300, Caio Henrique <caiohcs0@gmail.com> said:
>
>     Caio> Eli Zaretskii <eliz@gnu.org> writes:
>     >>> From: Robert Pluim <rpluim@gmail.com>
>     >>> Cc: caiohcs0@gmail.com,  rekado@elephly.net,  ghe@sdf.org,
>     >>> spacibba@aol.com,  drew.adams@oracle.com,  emacs-devel@gnu.org
>     >>> Date: Fri, 11 Sep 2020 16:24:23 +0200
>     >>> 
>     >>> if the goal is to save space we could remove the 'Save'
>     >>> and 'Undo' text in the toolbar under Gnu/Linux (the toolbar on macOS
>     >>> has only icons).
>     >> 
>     >> Does the text come from Emacs?  I thought it comes from GTK (I see no
>     >> text on MS-Windows, either).
>
>     Caio> (setq tool-bar-style 'image)
>
>     Caio> That should do the trick for GTK. Maybe this should be its default value?
>
> I agree (but I donʼt use the toolbar :-) )


I believe that this is a bug (see the images attached comparing before
and after this patch). 

_____
diff --git a/lisp/tool-bar.el b/lisp/tool-bar.el
index 7df1e28e06..bec45c1ea4 100644
--- a/lisp/tool-bar.el
+++ b/lisp/tool-bar.el
@@ -256,9 +256,9 @@ tool-bar-setup
   (tool-bar-add-item-from-menu 'dired "diropen" nil :vert-only t)
   (tool-bar-add-item-from-menu 'kill-this-buffer "close" nil :vert-only t)
   (tool-bar-add-item-from-menu 'save-buffer "save" nil
-			       :label "Save")
+			       :label "Save" :vert-only t)
   (define-key-after (default-value 'tool-bar-map) [separator-1] menu-bar-separator)
-  (tool-bar-add-item-from-menu 'undo "undo" nil)
+  (tool-bar-add-item-from-menu 'undo "undo" nil :vert-only t)
   (define-key-after (default-value 'tool-bar-map) [separator-2] menu-bar-separator)
   (tool-bar-add-item-from-menu (lookup-key menu-bar-edit-menu [cut])
 			       "cut" nil :vert-only t)
_____



[-- Attachment #2: toolbar before 1 --]
[-- Type: image/png, Size: 23688 bytes --]

[-- Attachment #3: toolbar before 2 --]
[-- Type: image/png, Size: 28526 bytes --]

[-- Attachment #4: toolbar after patch 1 --]
[-- Type: image/png, Size: 24166 bytes --]

[-- Attachment #5: toolbar patched 2 --]
[-- Type: image/png, Size: 31321 bytes --]

Re: Changes for emacs 28

[Ergus]

On Sat, Sep 12, 2020 at 03:29:34PM -0300, Caio Henrique wrote:
>Robert Pluim <rpluim@gmail.com> writes:
>
>
>
>I believe that this is a bug (see the images attached comparing before
>and after this patch).
>
>_____
>diff --git a/lisp/tool-bar.el b/lisp/tool-bar.el
>index 7df1e28e06..bec45c1ea4 100644
>--- a/lisp/tool-bar.el
>+++ b/lisp/tool-bar.el
>@@ -256,9 +256,9 @@ tool-bar-setup
>   (tool-bar-add-item-from-menu 'dired "diropen" nil :vert-only t)
>   (tool-bar-add-item-from-menu 'kill-this-buffer "close" nil :vert-only t)
>   (tool-bar-add-item-from-menu 'save-buffer "save" nil
>-			       :label "Save")
>+			       :label "Save" :vert-only t)
>   (define-key-after (default-value 'tool-bar-map) [separator-1] menu-bar-separator)
>-  (tool-bar-add-item-from-menu 'undo "undo" nil)
>+  (tool-bar-add-item-from-menu 'undo "undo" nil :vert-only t)
>   (define-key-after (default-value 'tool-bar-map) [separator-2] menu-bar-separator)
>   (tool-bar-add-item-from-menu (lookup-key menu-bar-edit-menu [cut])
> 			       "cut" nil :vert-only t)
>_____
>
>

Why you think it is a bug? :vert-only means exactly what I see.

Re: Changes for emacs 28

[Caio Henrique]

Ergus <spacibba@aol.com> writes:

> Why you think it is a bug? :vert-only means exactly what I see.

Sorry, "bug" was the wrong word, it is just an inconsistency IMO since
all other buttons are vertical only.

Re: Changes for emacs 28

[Thibaut Verron]

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

Wouldn't File > New in most other applications be more akin to switching to
an empty buffer with no associated file?

Le ven. 11 sept. 2020 à 16:05, Eli Zaretskii <eliz@gnu.org> a écrit :

> > From: Robert Pluim <rpluim@gmail.com>
> > Cc: Caio Henrique <caiohcs0@gmail.com>,  rekado@elephly.net,
> ghe@sdf.org,
> >   spacibba@aol.com,  drew.adams@oracle.com,  emacs-devel@gnu.org
> > Date: Fri, 11 Sep 2020 15:57:31 +0200
> >
> > Why have we got separate 'open new file' and 'open existing file'
> > buttons?
>
> Because most other applications have File->New and File->Open as
> separate items.
>
> > You can open an existing one from the dialog that 'open new file'
> > pops up.
>
> Yes, we Emacs veterans don't need both.  But the tool bar is not for
> us.
>
>

[-- Attachment #2: Type: text/html, Size: 1682 bytes --]

Re: Changes for emacs 28

[Eli Zaretskii]

> From: Thibaut Verron <thibaut.verron@gmail.com>
> Date: Fri, 11 Sep 2020 17:16:33 +0200
> Cc: Robert Pluim <rpluim@gmail.com>, spacibba@aol.com, caiohcs0@gmail.com, 
> 	emacs-devel@gnu.org, rekado@elephly.net, ghe@sdf.org, drew.adams@oracle.com
> 
> Wouldn't File > New in most other applications be more akin to switching to an empty buffer with no
> associated file? 

"Other applications" mostly don't support buffers with no associated
files, so we had to make a decision which of these two to use.  Since
those other applications force you to decide on exit whether to save
your edits or not, we decided it was more like what Emacs does with
buffers that do visit files.

Re: Changes for emacs 28

[Thibaut Verron]

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

Le ven. 11 sept. 2020 à 17:21, Eli Zaretskii <eliz@gnu.org> a écrit :

> > From: Thibaut Verron <thibaut.verron@gmail.com>
> > Date: Fri, 11 Sep 2020 17:16:33 +0200
> > Cc: Robert Pluim <rpluim@gmail.com>, spacibba@aol.com,
> caiohcs0@gmail.com,
> >       emacs-devel@gnu.org, rekado@elephly.net, ghe@sdf.org,
> drew.adams@oracle.com
> >
> > Wouldn't File > New in most other applications be more akin to switching
> to an empty buffer with no
> > associated file?
>
> "Other applications" mostly don't support buffers with no associated
> files, so we had to make a decision which of these two to use.  Since
> those other applications force you to decide on exit whether to save
> your edits or not, we decided it was more like what Emacs does with
> buffers that do visit files.
>

Don't they? As far as I can remember, Libreoffice does, MS office does,
Notepad does...

They call it "new document" rather than "new file" for this reason, I
guess.

Maybe this button could be bound to a function creating a new buffer with a
name like *unnamed[-n]*, and also mark these buffers for query for save on
exit?

>

[-- Attachment #2: Type: text/html, Size: 2513 bytes --]

Re: Changes for emacs 28

[Eli Zaretskii]

> From: Thibaut Verron <thibaut.verron@gmail.com>
> Date: Fri, 11 Sep 2020 17:36:24 +0200
> Cc: rpluim@gmail.com, spacibba@aol.com, caiohcs0@gmail.com, 
> 	emacs-devel@gnu.org, rekado@elephly.net, ghe@sdf.org, drew.adams@oracle.com
> 
>  "Other applications" mostly don't support buffers with no associated
>  files, so we had to make a decision which of these two to use.  Since
>  those other applications force you to decide on exit whether to save
>  your edits or not, we decided it was more like what Emacs does with
>  buffers that do visit files.
> 
> Don't they? As far as I can remember, Libreoffice does, MS office does, Notepad does... 
> 
> They call it "new document" rather than "new file" for this reason, I guess. 

And ask you where to save it when you exit.  That's what Emacs does
with file-visiting buffers.

> Maybe this button could be bound to a function creating a new buffer with a name like *unnamed[-n]*, and
> also mark these buffers for query for save on exit? 

AFAIR, that was considered.  Maybe you want to read those old
discussions.

Re: Changes for emacs 28

[Thibaut Verron]

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

Le ven. 11 sept. 2020 à 17:49, Eli Zaretskii <eliz@gnu.org> a écrit :

> > From: Thibaut Verron <thibaut.verron@gmail.com>
> > Date: Fri, 11 Sep 2020 17:36:24 +0200
> > Cc: rpluim@gmail.com, spacibba@aol.com, caiohcs0@gmail.com,
> >       emacs-devel@gnu.org, rekado@elephly.net, ghe@sdf.org,
> drew.adams@oracle.com
> >
> >  "Other applications" mostly don't support buffers with no associated
> >  files, so we had to make a decision which of these two to use.  Since
> >  those other applications force you to decide on exit whether to save
> >  your edits or not, we decided it was more like what Emacs does with
> >  buffers that do visit files.
> >
> > Don't they? As far as I can remember, Libreoffice does, MS office does,
> Notepad does...
> >
> > They call it "new document" rather than "new file" for this reason, I
> guess.
>
> And ask you where to save it when you exit.  That's what Emacs does
> with file-visiting buffers.
>

Yes but if you don't want to save it, you can just click discard and never
input a path. With the current setting you need to choose a path before you
can write text.


> > Maybe this button could be bound to a function creating a new buffer
> with a name like *unnamed[-n]*, and
> > also mark these buffers for query for save on exit?
>
> AFAIR, that was considered.  Maybe you want to read those old
> discussions.
>

Right, I will. :) No need to run in circles.

>

[-- Attachment #2: Type: text/html, Size: 2900 bytes --]

Re: Changes for emacs 28

[Eli Zaretskii]

> From: Thibaut Verron <thibaut.verron@gmail.com>
> Date: Fri, 11 Sep 2020 18:20:57 +0200
> Cc: rpluim@gmail.com, spacibba@aol.com, caiohcs0@gmail.com, 
> 	emacs-devel@gnu.org, rekado@elephly.net, ghe@sdf.org, drew.adams@oracle.com
> 
>  > They call it "new document" rather than "new file" for this reason, I guess. 
> 
>  And ask you where to save it when you exit.  That's what Emacs does
>  with file-visiting buffers.
> 
> Yes but if you don't want to save it, you can just click discard and never input a path. With the current setting
> you need to choose a path before you can write text. 

But with a buffer that doesn't visit a file, you don't get any prompt
at all.

Re: Changes for emacs 28

[Robert Pluim]

>>>>> On Fri, 11 Sep 2020 21:24:17 +0300, Eli Zaretskii <eliz@gnu.org> said:

    >> From: Thibaut Verron <thibaut.verron@gmail.com>
    >> Date: Fri, 11 Sep 2020 18:20:57 +0200
    >> Cc: rpluim@gmail.com, spacibba@aol.com, caiohcs0@gmail.com, 
    >> emacs-devel@gnu.org, rekado@elephly.net, ghe@sdf.org, drew.adams@oracle.com
    >> 
    >> > They call it "new document" rather than "new file" for this reason, I guess. 
    >> 
    >> And ask you where to save it when you exit.  That's what Emacs does
    >> with file-visiting buffers.
    >> 
    >> Yes but if you don't want to save it, you can just click discard and never input a path. With the current setting
    >> you need to choose a path before you can write text. 

    Eli> But with a buffer that doesn't visit a file, you don't get any prompt
    Eli> at all.

We could set 'kill-buffer-hook' to a querying function in buffers
created via the toolbar.

Robert

Re: Changes for emacs 28

[Thibaut Verron]

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

Le lun. 14 sept. 2020 à 09:37, Robert Pluim <rpluim@gmail.com> a écrit :

> >>>>> On Fri, 11 Sep 2020 21:24:17 +0300, Eli Zaretskii <eliz@gnu.org>
> said:
>
>     >> From: Thibaut Verron <thibaut.verron@gmail.com>
>     >> Date: Fri, 11 Sep 2020 18:20:57 +0200
>     >> Cc: rpluim@gmail.com, spacibba@aol.com, caiohcs0@gmail.com,
>     >> emacs-devel@gnu.org, rekado@elephly.net, ghe@sdf.org,
> drew.adams@oracle.com
>     >>
>     >> > They call it "new document" rather than "new file" for this
> reason, I guess.
>     >>
>     >> And ask you where to save it when you exit.  That's what Emacs does
>     >> with file-visiting buffers.
>     >>
>     >> Yes but if you don't want to save it, you can just click discard
> and never input a path. With the current setting
>     >> you need to choose a path before you can write text.
>
>     Eli> But with a buffer that doesn't visit a file, you don't get any
> prompt
>     Eli> at all.
>
> We could set 'kill-buffer-hook' to a querying function in buffers
> created via the toolbar.
>

There is already a (buffer-local) variable buffer-offer-save which, set to
'always, causes save-some-buffers to query for save the corresponding
buffer, if non-empty.

And save-buffers-kill-emacs calls save-some-buffers with the second
argument set to t, aka, "also save some non-file buffers".

It really looks as if this scenario is already planned, but just not for
entry from the tool-bar.

[-- Attachment #2: Type: text/html, Size: 2514 bytes --]

Re: Changes for emacs 28

[Robert Pluim]

>>>>> On Mon, 14 Sep 2020 09:53:28 +0200, Thibaut Verron <thibaut.verron@gmail.com> said:
    >> 
    >> We could set 'kill-buffer-hook' to a querying function in buffers
    >> created via the toolbar.
    >> 

    Thibaut> There is already a (buffer-local) variable buffer-offer-save which, set to
    Thibaut> 'always, causes save-some-buffers to query for save the corresponding
    Thibaut> buffer, if non-empty.

Right, but toolbar-save doesnʼt run save-some-buffers. That could be
added, but it seems people feel toolbar space is precious (here the
default toolbar uses slightly more than 50% of the available width
when running -Q)

    Thibaut> And save-buffers-kill-emacs calls save-some-buffers with the second
    Thibaut> argument set to t, aka, "also save some non-file buffers".

    Thibaut> It really looks as if this scenario is already planned, but just not for
    Thibaut> entry from the tool-bar.

That covers the 'exiting emacs' scenario, weʼd still need something to
cover the 'clicked the kill-buffer button'. Or if we really want to go
whole hog, we automatically save the state of buffers created via the
toolbar, and restore them on startup.

Robert

Re: Changes for emacs 28

[Thibaut Verron]

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

Le lun. 14 sept. 2020 à 13:54, Robert Pluim <rpluim@gmail.com> a écrit :

> >>>>> On Mon, 14 Sep 2020 09:53:28 +0200, Thibaut Verron <
> thibaut.verron@gmail.com> said:
>     >>
>     >> We could set 'kill-buffer-hook' to a querying function in buffers
>     >> created via the toolbar.
>     >>
>
>     Thibaut> There is already a (buffer-local) variable buffer-offer-save
> which, set to
>     Thibaut> 'always, causes save-some-buffers to query for save the
> corresponding
>     Thibaut> buffer, if non-empty.
>
> Right, but toolbar-save doesnʼt run save-some-buffers. That could be
> added, but it seems people feel toolbar space is precious (here the
> default toolbar uses slightly more than 50% of the available width
> when running -Q)
>

The save button runs save-buffer, so it should DTRT already, no?


> That covers the 'exiting emacs' scenario, weʼd still need something to
> cover the 'clicked the kill-buffer button'.


That's correct, I didn't have this usage in mind. Kill-buffer-hook seems to
be more for cleanup, but kill-buffer-query-functions could do the job as a
first step (as in, "do you really want to kill without saving?"). I believe
that
the most natural would be to add such a test to kill-buffer, since it
already
takes care of modified file buffers.

All those approaches would also affect other commands killing the buffer,
preventing a user from accidentally losing data because of an unfortunate
keypress.


Or if we really want to go
> whole hog, we automatically save the state of buffers created via the
> toolbar, and restore them on startup.
>

Restoring them as-is is what notepad++ does (or did when I last used it
10 years ago). I personally did not like this behavior, and I didn't have
remotely as many open files in notepad++ as I do in a typical emacs session.

On the other hand, auto-saving and offering to restore could be sensible.

[-- Attachment #2: Type: text/html, Size: 2887 bytes --]

Re: Changes for emacs 28, Re: Changes for emacs 28

[Robert Pluim]

>>>>> On Mon, 14 Sep 2020 14:15:40 +0200, Thibaut Verron <thibaut.verron@gmail.com> said:

    Thibaut> Le lun. 14 sept. 2020 à 13:54, Robert Pluim <rpluim@gmail.com> a écrit :
    >> >>>>> On Mon, 14 Sep 2020 09:53:28 +0200, Thibaut Verron <
    >> thibaut.verron@gmail.com> said:
    >> >>
    >> >> We could set 'kill-buffer-hook' to a querying function in buffers
    >> >> created via the toolbar.
    >> >>
    >> 
    Thibaut> There is already a (buffer-local) variable buffer-offer-save
    >> which, set to
    Thibaut> 'always, causes save-some-buffers to query for save the
    >> corresponding
    Thibaut> buffer, if non-empty.
    >> 
    >> Right, but toolbar-save doesnʼt run save-some-buffers. That could be
    >> added, but it seems people feel toolbar space is precious (here the
    >> default toolbar uses slightly more than 50% of the available width
    >> when running -Q)
    >> 

    Thibaut> The save button runs save-buffer, so it should DTRT already, no?

Sorry, yes. The 'new' button forces you to choose a filename for the
buffer, so saving it works (that will teach me to talk about features
I donʼt use)

    >> That covers the 'exiting emacs' scenario, weʼd still need something to
    >> cover the 'clicked the kill-buffer button'.

And again, this is already covered, since the buffer has an associated
file, emacs queries if you try to kill a buffer with unsaved changes.

    Thibaut> That's correct, I didn't have this usage in mind. Kill-buffer-hook seems to
    Thibaut> be more for cleanup, but kill-buffer-query-functions could do the job as a
    Thibaut> first step (as in, "do you really want to kill without saving?"). I believe
    Thibaut> that
    Thibaut> the most natural would be to add such a test to kill-buffer, since it
    Thibaut> already
    Thibaut> takes care of modified file buffers.

    Thibaut> All those approaches would also affect other commands killing the buffer,
    Thibaut> preventing a user from accidentally losing data because of an unfortunate
    Thibaut> keypress.

And now that Iʼve tested it, attempting to exit emacs with a modified
buffer throws up the GUI version of the 'save/no save/view' question,
so thatʼs OK.

So in short: nothing to implement :-)


    Thibaut> Or if we really want to go
    >> whole hog, we automatically save the state of buffers created via the
    >> toolbar, and restore them on startup.
    >> 

    Thibaut> Restoring them as-is is what notepad++ does (or did when I last used it
    Thibaut> 10 years ago). I personally did not like this behavior, and I didn't have
    Thibaut> remotely as many open files in notepad++ as I do in a typical emacs session.

Itʼs a behaviour thatʼs become strongly expected, mainly because
people have become conditioned to 'restart where I left off' behaviour
from web browsers, I suspect.

    Thibaut> On the other hand, auto-saving and offering to restore could be sensible.
>>>>> On Mon, 14 Sep 2020 09:18:29 -0400, Stefan Monnier <monnier@iro.umontreal.ca> said:

    Eli> But with a buffer that doesn't visit a file, you don't get any prompt
    Eli> at all.

The toolbar does not let you create such buffers (I thought it did,
but it doesnʼt).

    >> We could set 'kill-buffer-hook' to a querying function in buffers
    >> created via the toolbar.

    Stefan> Beside this question of "save" there's also the issue of "autosave".

    Stefan> Why not create a new and "normal" file-buffer whose file name is
    Stefan> something like `~/.emacs.d/newfiles/untitled<N>`?

See above: the buffer will have an associated file, so autosave should
just work.

Robert

Re: Changes for emacs 28, Re: Changes for emacs 28

[Thibaut Verron]

Le lun. 14 sept. 2020 à 16:35, Robert Pluim <rpluim@gmail.com> a écrit :
>
> >>>>> On Mon, 14 Sep 2020 14:15:40 +0200, Thibaut Verron <thibaut.verron@gmail.com> said:
>
>     Thibaut> Le lun. 14 sept. 2020 à 13:54, Robert Pluim <rpluim@gmail.com> a écrit :
>     >> >>>>> On Mon, 14 Sep 2020 09:53:28 +0200, Thibaut Verron <
>     >> thibaut.verron@gmail.com> said:
>     >> >>
>     >> >> We could set 'kill-buffer-hook' to a querying function in buffers
>     >> >> created via the toolbar.
>     >> >>
>     >>
>     Thibaut> There is already a (buffer-local) variable buffer-offer-save
>     >> which, set to
>     Thibaut> 'always, causes save-some-buffers to query for save the
>     >> corresponding
>     Thibaut> buffer, if non-empty.
>     >>
>     >> Right, but toolbar-save doesnʼt run save-some-buffers. That could be
>     >> added, but it seems people feel toolbar space is precious (here the
>     >> default toolbar uses slightly more than 50% of the available width
>     >> when running -Q)
>     >>
>
>     Thibaut> The save button runs save-buffer, so it should DTRT already, no?
>
> Sorry, yes. The 'new' button forces you to choose a filename for the
> buffer, so saving it works (that will teach me to talk about features
> I donʼt use)

I think that you missed a message in the long thread.

To clarify, currently, the "new" button is "find-file", so it does
expect a file name and a path.
The suggestion is to maybe replace it with a function creating an
anonymous buffer, leaving the choice of a path (if necessary) to the
point of saving.

In essence, something like

> (defun my/new-buffer ()
>   (interactive)
>   (let ((buffer (generate-new-buffer "*unnamed*")))
>     (pop-to-buffer buffer)
>     (setq buffer-offer-save 'always)))

Save-buffer should still work as expected, just as if you were calling
it from a normal non-file buffer, and so should save-some-buffers and
the like.

But kill-buffer will not offer to save, as of now, as you pointed out.

>
>     Thibaut> Restoring them as-is is what notepad++ does (or did when I last used it
>     Thibaut> 10 years ago). I personally did not like this behavior, and I didn't have
>     Thibaut> remotely as many open files in notepad++ as I do in a typical emacs session.
>
> Itʼs a behaviour thatʼs become strongly expected, mainly because
> people have become conditioned to 'restart where I left off' behaviour
> from web browsers, I suspect.

There are packages going in that direction, if you are interested, but
it is really a complicated matter. Anonymous user-generated buffers
are not the biggest problem there. Web-browsers can just reload the
content of most of their "buffers", that's a luxury emacs does not
have.

> The toolbar does not let you create such buffers (I thought it did,
> but it doesnʼt).

That illustrates how confusing the current situation is, I believe. :)

Re: Changes for emacs 28, Re: Changes for emacs 28

[Robert Pluim]

>>>>> On Mon, 14 Sep 2020 16:53:07 +0200, Thibaut Verron <thibaut.verron@gmail.com> said:

    Thibaut> The save button runs save-buffer, so it should DTRT already, no?
    >> 
    >> Sorry, yes. The 'new' button forces you to choose a filename for the
    >> buffer, so saving it works (that will teach me to talk about features
    >> I donʼt use)

    Thibaut> I think that you missed a message in the long thread.

No doubt. Itʼs a *very* long thread.

    Thibaut> To clarify, currently, the "new" button is "find-file", so it does
    Thibaut> expect a file name and a path.
    Thibaut> The suggestion is to maybe replace it with a function creating an
    Thibaut> anonymous buffer, leaving the choice of a path (if necessary) to the
    Thibaut> point of saving.

    Thibaut> In essence, something like

    >> (defun my/new-buffer ()
    >> (interactive)
    >> (let ((buffer (generate-new-buffer "*unnamed*")))
    >> (pop-to-buffer buffer)
    >> (setq buffer-offer-save 'always)))

Oh. Is that what non-emacs-experienced users really expect?

    Thibaut> Save-buffer should still work as expected, just as if you were calling
    Thibaut> it from a normal non-file buffer, and so should save-some-buffers and
    Thibaut> the like.

    Thibaut> But kill-buffer will not offer to save, as of now, as you pointed out.

Right, so if we find a good way to fix that itʼs fine, although Iʼm
not sure whether thereʼs any good reason for us to do it other than
'other programs do it' ; the current behaviour seems consistent
enough.

    >> 
    Thibaut> Restoring them as-is is what notepad++ does (or did when I last used it
    Thibaut> 10 years ago). I personally did not like this behavior, and I didn't have
    Thibaut> remotely as many open files in notepad++ as I do in a typical emacs session.
    >> 
    >> Itʼs a behaviour thatʼs become strongly expected, mainly because
    >> people have become conditioned to 'restart where I left off' behaviour
    >> from web browsers, I suspect.

    Thibaut> There are packages going in that direction, if you are interested, but
    Thibaut> it is really a complicated matter. Anonymous user-generated buffers
    Thibaut> are not the biggest problem there. Web-browsers can just reload the
    Thibaut> content of most of their "buffers", that's a luxury emacs does not
    Thibaut> have.

    >> The toolbar does not let you create such buffers (I thought it did,
    >> but it doesnʼt).

    Thibaut> That illustrates how confusing the current situation is, I believe. :)

Only to people who create buffers, and then later decide whether to
put stuff in a file. Thatʼs not your typical newcomer to emacs.

Robert

Re: Changes for emacs 28, Re: Changes for emacs 28

[Thibaut Verron]

Le lun. 14 sept. 2020 à 18:01, Robert Pluim <rpluim@gmail.com> a écrit :
>
> >>>>> On Mon, 14 Sep 2020 16:53:07 +0200, Thibaut Verron <thibaut.verron@gmail.com> said:
>
>     Thibaut> The save button runs save-buffer, so it should DTRT already, no?
>     >>
>     >> Sorry, yes. The 'new' button forces you to choose a filename for the
>     >> buffer, so saving it works (that will teach me to talk about features
>     >> I donʼt use)
>
>     Thibaut> I think that you missed a message in the long thread.
>
> No doubt. Itʼs a *very* long thread.
>
>     Thibaut> To clarify, currently, the "new" button is "find-file", so it does
>     Thibaut> expect a file name and a path.
>     Thibaut> The suggestion is to maybe replace it with a function creating an
>     Thibaut> anonymous buffer, leaving the choice of a path (if necessary) to the
>     Thibaut> point of saving.
>
>     Thibaut> In essence, something like
>
>     >> (defun my/new-buffer ()
>     >> (interactive)
>     >> (let ((buffer (generate-new-buffer "*unnamed*")))
>     >> (pop-to-buffer buffer)
>     >> (setq buffer-offer-save 'always)))
>
> Oh. Is that what non-emacs-experienced users really expect?

As you said below, other programs do it. That's not, per se, a reason
to do it too, but that's a reason for users to expect it to work in a
certain way.
And it is what you and me and others, all experienced Emacs users with
very little experience of the tool bar, expected when we saw the
button.
So it seems reasonable to me that it is what people, in general, expect.

For a specific use case, I regularly see people fire up Word or
Libreoffice to draft an e-mail. They might choose a file name early in
the process, but usually, choosing a path comes much later, at the
time of saving, and at that point they can just decide to discard the
changes.


>     Thibaut> Save-buffer should still work as expected, just as if you were calling
>     Thibaut> it from a normal non-file buffer, and so should save-some-buffers and
>     Thibaut> the like.
>
>     Thibaut> But kill-buffer will not offer to save, as of now, as you pointed out.
>
> Right, so if we find a good way to fix that itʼs fine, although Iʼm
> not sure whether thereʼs any good reason for us to do it other than
> 'other programs do it' ; the current behaviour seems consistent
> enough.

The main reason is not that "other programs do it", it's that Emacs
does it, and that Emacs users do it regularly. If there is a workflow
that is common in the Emacs paradigm (C-x b "asdf") *and* other
programs already do it (and make it their entry point, in a lot of
cases*), I believe that it is a very good reason to give it a VIP
place on the tool bar.

It looks like the only difficulty is to also properly expose all the
necessary buffer-related features: auto-saving, maybe also renaming,
etc. There seems to be multiple possibilities, but for example
Stefan's suggestion to just use actual files could work, with a little
bit of UI and auto-cleaning.

*. To be clear, I do not think that Emacs should offer a blank,
auto-saved file document on start, as other programs do.

Re: Changes for emacs 28, Re: Changes for emacs 28

[tomas]

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

On Mon, Sep 14, 2020 at 04:53:07PM +0200, Thibaut Verron wrote:

> I think that you missed a message in the long thread.
> 
> To clarify, currently, the "new" button is "find-file", so it does
> expect a file name and a path.
> The suggestion is to maybe replace it with a function creating an
> anonymous buffer, leaving the choice of a path (if necessary) to the
> point of saving.

Yes, but as Andreas said, Emacs has no information to set a major
mode: the file itself is empty, and the name has no hints.

Technically, that's OK, but there is the risk that "newbies" do
everything in fundamental-mode.

Which would degrade the user experience.

Cheers
 - t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Changes for emacs 28

[Stefan Monnier]

>     Eli> But with a buffer that doesn't visit a file, you don't get any prompt
>     Eli> at all.
> We could set 'kill-buffer-hook' to a querying function in buffers
> created via the toolbar.

Beside this question of "save" there's also the issue of "autosave".

Why not create a new and "normal" file-buffer whose file name is
something like `~/.emacs.d/newfiles/untitled<N>`?


        Stefan

Re: Changes for emacs 28

[Andreas Schwab]

On Sep 14 2020, Stefan Monnier wrote:

> Why not create a new and "normal" file-buffer whose file name is
> something like `~/.emacs.d/newfiles/untitled<N>`?

The file name also sets the major mode for the buffer.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: Changes for emacs 28

[Eli Zaretskii]

> Date: Fri, 11 Sep 2020 01:14:20 +0200
> From: Ergus <spacibba@aol.com>
> Cc: Ricardo Wurmus <rekado@elephly.net>, Gregory Heytings <ghe@sdf.org>,
>  emacs-devel@gnu.org
> 
> 3) Is it possible/should we: add a redo icon in the toolbar
> conditionally when the mode is enabled?
> 
> else
> 
> 4) I see a redo added in the menu-bar unconditionally... should we do
> the same in the toolbar unconditionally?

I indeed think that the Redo icon should be added unconditionally
(enabled only when there's something to redo, like the menu item).

Re: Changes for emacs 28

[Dmitry Gutov]

On 11.09.2020 09:39, Eli Zaretskii wrote:
>> Date: Fri, 11 Sep 2020 01:14:20 +0200
>> From: Ergus<spacibba@aol.com>
>> Cc: Ricardo Wurmus<rekado@elephly.net>, Gregory Heytings<ghe@sdf.org>,
>>   emacs-devel@gnu.org
>>
>> 3) Is it possible/should we: add a redo icon in the toolbar
>> conditionally when the mode is enabled?
>>
>> else
>>
>> 4) I see a redo added in the menu-bar unconditionally... should we do
>> the same in the toolbar unconditionally?
> I indeed think that the Redo icon should be added unconditionally
> (enabled only when there's something to redo, like the menu item).

Are you not worried about the divergence between the menu items and the 
toolbar, and the actual available bindings?

And also about the fact the menu item next to 'redo' doesn't call 
'undo-only'? Which will be contrary to the expectations of users who 
know the concept of 'redo' from other programs.

I think this created a potential for additional user confusion.

A global mode like undo-redo-mode, like suggested by Ergus, would avoid 
both of these problems. We'd only need to find a key for 'undo-redo'.

Perhaps, 'M-_' and 'C-?'? That's what undo-tree uses by default.

Re: Changes for emacs 28

[Eli Zaretskii]

> Cc: rekado@elephly.net, ghe@sdf.org, drew.adams@oracle.com,
>  emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Fri, 11 Sep 2020 13:10:29 +0300
> 
> >> 4) I see a redo added in the menu-bar unconditionally... should we do
> >> the same in the toolbar unconditionally?
> > I indeed think that the Redo icon should be added unconditionally
> > (enabled only when there's something to redo, like the menu item).
> 
> Are you not worried about the divergence between the menu items and the 
> toolbar, and the actual available bindings?

I see no divergence in the proposal.  So no, I'm not worried.

> And also about the fact the menu item next to 'redo' doesn't call 
> 'undo-only'?

What is "the menu item next to 'redo'"?

Re: Changes for emacs 28

[Dmitry Gutov]

On 11.09.2020 13:33, Eli Zaretskii wrote:
> What is "the menu item next to 'redo'"?

'undo'.

As opposed to 'undo-only'.

Re: Changes for emacs 28

[Eli Zaretskii]

> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Fri, 11 Sep 2020 13:36:25 +0300
> Cc: rekado@elephly.net, ghe@sdf.org, spacibba@aol.com, drew.adams@oracle.com,
>  emacs-devel@gnu.org
> 
> On 11.09.2020 13:33, Eli Zaretskii wrote:
> > What is "the menu item next to 'redo'"?
> 
> 'undo'.
> 
> As opposed to 'undo-only'.

If people prefer that, we could change the binding, I won't object.

Re: Changes for emacs 28

[Dmitry Gutov]

On 11.09.2020 13:41, Eli Zaretskii wrote:
> If people prefer that, we could change the binding, I won't object.

But then we'll have no binding for `undo-redo`, just a menu item?

Or would you be fine with adding a binding for it too?

Re: Changes for emacs 28

[Ergus]

On Fri, Sep 11, 2020 at 02:09:17PM +0300, Dmitry Gutov wrote:
>On 11.09.2020 13:41, Eli Zaretskii wrote:
>>If people prefer that, we could change the binding, I won't object.
>
>But then we'll have no binding for `undo-redo`, just a menu item?
>
>Or would you be fine with adding a binding for it too?
>
Do you think we should go with the mode approach?

Re: Changes for emacs 28

[Dmitry Gutov]

On 11.09.2020 14:19, Ergus wrote:
> On Fri, Sep 11, 2020 at 02:09:17PM +0300, Dmitry Gutov wrote:
>> On 11.09.2020 13:41, Eli Zaretskii wrote:
>>> If people prefer that, we could change the binding, I won't object.
>>
>> But then we'll have no binding for `undo-redo`, just a menu item?
>>
>> Or would you be fine with adding a binding for it too?
>>
> Do you think we should go with the mode approach?

Either that, or switch to undo-only and undo-redo bindings in the 
default set.

But I don't think we'll reach an agreement for the latter anytime soon. 
So the gradual approach seems more in line with the usual Emacs evolution.

Said mode could be an easy switch to the alternative undo behavior. We 
can announce it availability prominently, and sometime after we could 
discuss whether that mode should be on by default. If we do, people who 
prefer the old way could easily disable it then, that's also a plus.

Re: Changes for emacs 28

[Eli Zaretskii]

> Cc: rekado@elephly.net, ghe@sdf.org, spacibba@aol.com, drew.adams@oracle.com,
>  emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Fri, 11 Sep 2020 14:09:17 +0300
> 
> On 11.09.2020 13:41, Eli Zaretskii wrote:
> > If people prefer that, we could change the binding, I won't object.
> 
> But then we'll have no binding for `undo-redo`, just a menu item?
> 
> Or would you be fine with adding a binding for it too?

Why do we need a binding for it in the default configuration?  Not
every command available through the menus has a keybinding by default.

Re: Changes for emacs 28

[Ergus]

On Fri, Sep 11, 2020 at 03:04:50PM +0300, Eli Zaretskii wrote:
>> Cc: rekado@elephly.net, ghe@sdf.org, spacibba@aol.com, drew.adams@oracle.com,
>>  emacs-devel@gnu.org
>> From: Dmitry Gutov <dgutov@yandex.ru>
>> Date: Fri, 11 Sep 2020 14:09:17 +0300
>>
>> On 11.09.2020 13:41, Eli Zaretskii wrote:
>> > If people prefer that, we could change the binding, I won't object.
>>
>> But then we'll have no binding for `undo-redo`, just a menu item?
>>
>> Or would you be fine with adding a binding for it too?
>
>Why do we need a binding for it in the default configuration?  Not
>every command available through the menus has a keybinding by default.
>
Hi Eli:

Could you reconsider my proposal of an undo-redo-mode to:

- Add the extra icon in the toolbar.
- Change the undo action in menu-bar and tool-bar by undo-only instead.
- Bind undo-redo to something in the keyboard.
- To enable it in some of the proposed user "profiles"
- Not bother the users that somehow won't like to have all that.

Having undo with an undo-redo in the same "state" could be confusing as
the normal undo could do also redo IMO.

Re: Changes for emacs 28

[Eli Zaretskii]

> Date: Fri, 11 Sep 2020 14:19:19 +0200
> From: Ergus <spacibba@aol.com>
> Cc: Dmitry Gutov <dgutov@yandex.ru>, rekado@elephly.net, ghe@sdf.org,
> 	drew.adams@oracle.com, emacs-devel@gnu.org
> 
> Could you reconsider my proposal of an undo-redo-mode to:
> 
> - Add the extra icon in the toolbar.

I believe I already agreed to that.  We even had a patch posted for
it, and I commented on it.

> - Change the undo action in menu-bar and tool-bar by undo-only instead.

We need more opinions for this one.  If many people agree to it, I
won't object.

> - Bind undo-redo to something in the keyboard.

If you can find a good key that is vacant, sure, why not?

> - To enable it in some of the proposed user "profiles"

Since we don't have any profiles yet, this is not something we can do.

> - Not bother the users that somehow won't like to have all that.

Having said all of the above, I'm now asking myself (and you) why do
we have to have a special mode for this?  None of these measures
contradicts the default operation of undo via C-/, so we could simply
have this by default.

> Having undo with an undo-redo in the same "state" could be confusing as
> the normal undo could do also redo IMO.

If the user uses the menus or the tool bar, the confusion will be
spared, right?

Re: Changes for emacs 28

[Ergus]

On Fri, Sep 11, 2020 at 03:35:40PM +0300, Eli Zaretskii wrote:
>> Date: Fri, 11 Sep 2020 14:19:19 +0200
>> From: Ergus <spacibba@aol.com>
>> Cc: Dmitry Gutov <dgutov@yandex.ru>, rekado@elephly.net, ghe@sdf.org,
>> 	drew.adams@oracle.com, emacs-devel@gnu.org
>>
>> Could you reconsider my proposal of an undo-redo-mode to:
>>
>> - Add the extra icon in the toolbar.
>
>I believe I already agreed to that.  We even had a patch posted for
>it, and I commented on it.
>
I mean conditionally in the mode ;p

>> - Change the undo action in menu-bar and tool-bar by undo-only instead.
>
>We need more opinions for this one.  If many people agree to it, I
>won't object.
>
That's why we need the mode. Normally there is not agreement about
changes of this kind, so user can set it on demand if they prefer it.

>> - Bind undo-redo to something in the keyboard.
>
>If you can find a good key that is vacant, sure, why not?
>
C-? and M-_ are generally used in the packages around and they make
sense with the current ones.

>> - To enable it in some of the proposed user "profiles"
>
>Since we don't have any profiles yet, this is not something we can do.
>
>> - Not bother the users that somehow won't like to have all that.
>
>Having said all of the above, I'm now asking myself (and you) why do
>we have to have a special mode for this?  None of these measures
>contradicts the default operation of undo via C-/, so we could simply
>have this by default.
>
The mode will substitute undo with undo-only. This small contradiction
will start a war here.

>> Having undo with an undo-redo in the same "state" could be confusing as
>> the normal undo could do also redo IMO.
>
>If the user uses the menus or the tool bar, the confusion will be
>spared, right?
>
If the user expects undo-only behavior; then having our undo will be
confusing because not expecting undo becoming a redo at some point.

IMO we should have one (undo) or the other (undo-only + undo-edor) but
not mix them by default.

Re: Changes for emacs 28

[Eli Zaretskii]

> Date: Fri, 11 Sep 2020 14:57:44 +0200
> From: Ergus <spacibba@aol.com>
> Cc: rekado@elephly.net, ghe@sdf.org, emacs-devel@gnu.org,
> 	drew.adams@oracle.com, dgutov@yandex.ru
> 
> The mode will substitute undo with undo-only. This small contradiction
> will start a war here.

As long as we keep this on the menu and the tool bar, there will be no
reason for a "war".

> >> Having undo with an undo-redo in the same "state" could be confusing as
> >> the normal undo could do also redo IMO.
> >
> >If the user uses the menus or the tool bar, the confusion will be
> >spared, right?
> >
> If the user expects undo-only behavior; then having our undo will be
> confusing because not expecting undo becoming a redo at some point.

How can it be confusing that 2 different commands produce different
results?  Why isn't it confusing today, when we already have these 2
commands?

> IMO we should have one (undo) or the other (undo-only + undo-edor) but
> not mix them by default.

Whether to mix them or not is up to the user.

Re: Changes for emacs 28

[Eli Zaretskii]

> Date: Fri, 11 Sep 2020 16:04:48 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: rekado@elephly.net, ghe@sdf.org, dgutov@yandex.ru, drew.adams@oracle.com,
>  emacs-devel@gnu.org
> 
> > Date: Fri, 11 Sep 2020 14:57:44 +0200
> > From: Ergus <spacibba@aol.com>
> > Cc: rekado@elephly.net, ghe@sdf.org, emacs-devel@gnu.org,
> > 	drew.adams@oracle.com, dgutov@yandex.ru
> > 
> > The mode will substitute undo with undo-only. This small contradiction
> > will start a war here.
> 
> As long as we keep this on the menu and the tool bar, there will be no
> reason for a "war".
> 
> > >> Having undo with an undo-redo in the same "state" could be confusing as
> > >> the normal undo could do also redo IMO.
> > >
> > >If the user uses the menus or the tool bar, the confusion will be
> > >spared, right?
> > >
> > If the user expects undo-only behavior; then having our undo will be
> > confusing because not expecting undo becoming a redo at some point.
> 
> How can it be confusing that 2 different commands produce different
> results?  Why isn't it confusing today, when we already have these 2
> commands?
> 
> > IMO we should have one (undo) or the other (undo-only + undo-edor) but
> > not mix them by default.
> 
> Whether to mix them or not is up to the user.

To clarify: I'm not opposed to your proposal of having a special mode,
I just think it's an unnecessary complication, and actually flies in
the face of our desire to make Emacs easier for newbies: a mode that
is not turned on by default needs to be discovered and turned on,
before its benefits can be apparent.  Having these commands available
by default doesn't have this disadvantage.

Re: Changes for emacs 28

[Arthur Miller]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Fri, 11 Sep 2020 16:04:48 +0300
>> From: Eli Zaretskii <eliz@gnu.org>
>> Cc: rekado@elephly.net, ghe@sdf.org, dgutov@yandex.ru, drew.adams@oracle.com,
>>  emacs-devel@gnu.org
>> 
>> > Date: Fri, 11 Sep 2020 14:57:44 +0200
>> > From: Ergus <spacibba@aol.com>
>> > Cc: rekado@elephly.net, ghe@sdf.org, emacs-devel@gnu.org,
>> > 	drew.adams@oracle.com, dgutov@yandex.ru
>> > 
>> > The mode will substitute undo with undo-only. This small contradiction
>> > will start a war here.
>> 
>> As long as we keep this on the menu and the tool bar, there will be no
>> reason for a "war".
>> 
>> > >> Having undo with an undo-redo in the same "state" could be confusing as
>> > >> the normal undo could do also redo IMO.
>> > >
>> > >If the user uses the menus or the tool bar, the confusion will be
>> > >spared, right?
>> > >
>> > If the user expects undo-only behavior; then having our undo will be
>> > confusing because not expecting undo becoming a redo at some point.
>> 
>> How can it be confusing that 2 different commands produce different
>> results?  Why isn't it confusing today, when we already have these 2
>> commands?
>> 
>> > IMO we should have one (undo) or the other (undo-only + undo-edor) but
>> > not mix them by default.
>> 
>> Whether to mix them or not is up to the user.
>
> To clarify: I'm not opposed to your proposal of having a special mode,
> I just think it's an unnecessary complication, and actually flies in
> the face of our desire to make Emacs easier for newbies: a mode that
> is not turned on by default needs to be discovered and turned on,
> before its benefits can be apparent.  Having these commands available
> by default doesn't have this disadvantage.

They don't need to know that it is a mode and it can be on by default.
Users just need to know it is a "feature" which they can switch off or
on. Being a mode could be just an so called implemetation detail. I
don't see personally what extra a mode brings in, but when it comes to
discoverability it can still be "just a feature".

Re: Changes for emacs 28

[Dmitry Gutov]

On 11.09.2020 16:04, Eli Zaretskii wrote:
>> Date: Fri, 11 Sep 2020 14:57:44 +0200
>> From: Ergus <spacibba@aol.com>
>> Cc: rekado@elephly.net, ghe@sdf.org, emacs-devel@gnu.org,
>> 	drew.adams@oracle.com, dgutov@yandex.ru
>>
>> The mode will substitute undo with undo-only. This small contradiction
>> will start a war here.
> 
> As long as we keep this on the menu and the tool bar, there will be no
> reason for a "war".

So there will be contradiction between the menu and the keyboard?

>>>> Having undo with an undo-redo in the same "state" could be confusing as
>>>> the normal undo could do also redo IMO.
>>>
>>> If the user uses the menus or the tool bar, the confusion will be
>>> spared, right?
>>>
>> If the user expects undo-only behavior; then having our undo will be
>> confusing because not expecting undo becoming a redo at some point.
> 
> How can it be confusing that 2 different commands produce different
> results?  Why isn't it confusing today, when we already have these 2
> commands?

The menu item doesn't exactly say which command it is invoking.

>> IMO we should have one (undo) or the other (undo-only + undo-edor) but
>> not mix them by default.
> 
> Whether to mix them or not is up to the user.

This has been true before the menu items were added, and will continue 
to be true if/when we change the default bindings.

So I think that statement is missing the point: we should endeavor for 
predictable and consistent sets of menu items, key bindings, and other 
features.

Re: Changes for emacs 28

[Ergus]

On Sat, Sep 12, 2020 at 12:00:48AM +0300, Dmitry Gutov wrote:
>On 11.09.2020 16:04, Eli Zaretskii wrote:
>>>Date: Fri, 11 Sep 2020 14:57:44 +0200
>>>From: Ergus <spacibba@aol.com>
>>>Cc: rekado@elephly.net, ghe@sdf.org, emacs-devel@gnu.org,
>>>	drew.adams@oracle.com, dgutov@yandex.ru
>>>
>>>The mode will substitute undo with undo-only. This small contradiction
>>>will start a war here.
>>
>>As long as we keep this on the menu and the tool bar, there will be no
>>reason for a "war".
>
>So there will be contradiction between the menu and the keyboard?
>
Hopefully not: With the undo-redo-mode; undo icon will do undo-only as
well as the keyboard and toolbar-icon.

Otherwise; maybe it is easier to keep everything there as now (undo and
redo in toolbar and menubar and no undo-redo-mode) but add an option
like default-undo-command to set the undo-only as the default undo
either in the keyboard, toolbar and menubar if someone (like me) don't
like at all the default undo.

I don't know if that's possible with a simple remap... is it?

BTW: everybody agrees in set undo-redo to C-? and M-_??

>>>>>Having undo with an undo-redo in the same "state" could be confusing as
>>>>>the normal undo could do also redo IMO.
>>>>
>>>>If the user uses the menus or the tool bar, the confusion will be
>>>>spared, right?
>>>>
>>>If the user expects undo-only behavior; then having our undo will be
>>>confusing because not expecting undo becoming a redo at some point.
>>
>>How can it be confusing that 2 different commands produce different
>>results?  Why isn't it confusing today, when we already have these 2
>>commands?
>
>The menu item doesn't exactly say which command it is invoking.
>
>>>IMO we should have one (undo) or the other (undo-only + undo-edor) but
>>>not mix them by default.
>>
>>Whether to mix them or not is up to the user.
>
>This has been true before the menu items were added, and will continue 
>to be true if/when we change the default bindings.
>
>So I think that statement is missing the point: we should endeavor for 
>predictable and consistent sets of menu items, key bindings, and other 
>features.
>
Personally I still think that a mode is better. But I trust more in Eli's
opinion than mine in this topics.

Re: Changes for emacs 28

[Dmitry Gutov]

On 12.09.2020 00:17, Ergus wrote:
> On Sat, Sep 12, 2020 at 12:00:48AM +0300, Dmitry Gutov wrote:

>> So there will be contradiction between the menu and the keyboard?
>>
> Hopefully not: With the undo-redo-mode; undo icon will do undo-only as
> well as the keyboard and toolbar-icon.

Indeed.

> Otherwise; maybe it is easier to keep everything there as now (undo and
> redo in toolbar and menubar and no undo-redo-mode) but add an option
> like default-undo-command to set the undo-only as the default undo
> either in the keyboard, toolbar and menubar if someone (like me) don't
> like at all the default undo.
> 
> I don't know if that's possible with a simple remap... is it?

It's unlikely to be as seamless as toggling undo-redo-mode.

> BTW: everybody agrees in set undo-redo to C-? and M-_??

No objections so far, and the bindings are free, so...

We can change the exact keys later anyway.

> Personally I still think that a mode is better. But I trust more in Eli's
> opinion than mine in this topics.

Since Eli clarified that his objection is not hard (email from 
11.09.2020, 16:13), perhaps you should go ahead and propose a concrete 
patch for review.

Re: Changes for emacs 28

[Ergus]

On Sat, Sep 12, 2020 at 01:29:42AM +0300, Dmitry Gutov wrote:
>On 12.09.2020 00:17, Ergus wrote:
>>On Sat, Sep 12, 2020 at 12:00:48AM +0300, Dmitry Gutov wrote:
>
>>>So there will be contradiction between the menu and the keyboard?
>>>
>>Hopefully not: With the undo-redo-mode; undo icon will do undo-only as
>>well as the keyboard and toolbar-icon.
>
>Indeed.
>
>>Otherwise; maybe it is easier to keep everything there as now (undo and
>>redo in toolbar and menubar and no undo-redo-mode) but add an option
>>like default-undo-command to set the undo-only as the default undo
>>either in the keyboard, toolbar and menubar if someone (like me) don't
>>like at all the default undo.
>>
>>I don't know if that's possible with a simple remap... is it?
>
>It's unlikely to be as seamless as toggling undo-redo-mode.
>

>>BTW: everybody agrees in set undo-redo to C-? and M-_??
>
>No objections so far, and the bindings are free, so...
>
>We can change the exact keys later anyway.
>
>>Personally I still think that a mode is better. But I trust more in Eli's
>>opinion than mine in this topics.
>
>Since Eli clarified that his objection is not hard (email from 
>11.09.2020, 16:13), perhaps you should go ahead and propose a concrete 
>patch for review.

Actually the implementation is barely trivial; something like this
should work (including tool-bar and menu-bar) because the redo icon is
already there; so we only add the bindings for it until it will be added
by default:

(defvar undo-redo-mode-map
   (let ((map (make-sparse-keymap)))
     (define-key map [remap undo] 'undo-only)
     (define-key map (kbd "C-?") 'undo-redo)
     (define-key map (kbd "M-_") 'undo-redo)
     map))

(define-minor-mode undo-redo-mode
   "Replace undo with undo-only and enables undo-redo."
   :global t
   :keymap undo-redo-mode-map
   :group 'undo
   )

As it seems like the redo will stay by default as well as the bindings,
then the mode is probably not needed and the user could just bind:

(define-key global-map [remap undo] 'undo-only)

if he don't like to use the default undo.

If we remove the redo from the menu and toolbar and or the default
bindings; then some other small changes will be needed and will make
sense to have this mode. But so far nobody complained about the redo
icon and personally I don't really care too much.

Re: Changes for emacs 28

[Dmitry Gutov]

On 12.09.2020 05:01, Ergus wrote:

> Actually the implementation is barely trivial; something like this
> should work (including tool-bar and menu-bar) because the redo icon is
> already there; so we only add the bindings for it until it will be added
> by default:

I agree it is simple, but a concrete patch would be another step toward 
the goal.

> (defvar undo-redo-mode-map
>    (let ((map (make-sparse-keymap)))
>      (define-key map [remap undo] 'undo-only)
>      (define-key map (kbd "C-?") 'undo-redo)
>      (define-key map (kbd "M-_") 'undo-redo)
>      map))
> 
> (define-minor-mode undo-redo-mode
>    "Replace undo with undo-only and enables undo-redo."
>    :global t
>    :keymap undo-redo-mode-map
>    :group 'undo
>    )
> 
> As it seems like the redo will stay by default as well as the bindings,
> then the mode is probably not needed and the user could just bind:

Indeed, so IMO the mode should affect the toolbar and the menu as well.

> (define-key global-map [remap undo] 'undo-only)
> 
> if he don't like to use the default undo.

That's a decent point, but this setup is missing the new bindings for 
undo-redo. It also won't help with the low discoverability that 
undo-only and undo-redo have.

And since the main moment when we would expect someone to want this is 
just when they are becoming familiar with Emacs, making it as easy as 
possible should be the goal.

> If we remove the redo from the menu and toolbar and or the default
> bindings; then some other small changes will be needed and will make
> sense to have this mode. But so far nobody complained about the redo
> icon and personally I don't really care too much.

If we're talking about existing, experienced users such as you and I, we 
might as well leave _everything_ as is, and customize whatever bits in 
the init scripts. But we're probably talking about new user experience.

Re: Changes for emacs 28

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

There are two problems with C-?:

* It requires two shift keys, so it is inconvenient.
(The bindings for undo ensure it can be typed with just one
shift key on all usual terminals.)

* It does not exist at all on ttys.  (I don't know whether we can
change that on Linux consoles.)

Whether constitutes a problem for the undo-redo feature depends on the
precise meanings of the two commands.  I don't know those details
so I can't judge.

M-_ is likewise inconvenient because of the need for two shift keys.

Defining these keys in addition to the existing binding for 'undo'
can't do direct harm.  But it may disappoint the users you're trying
to help.


-- 
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: Changes for emacs 28

[Yuri Khan]

On Sun, 13 Sep 2020 at 10:57, Richard Stallman <rms@gnu.org> wrote:

> There are two problems with C-?:
>
> * It requires two shift keys, so it is inconvenient.
> (The bindings for undo ensure it can be typed with just one
> shift key on all usual terminals.)
>
> M-_ is likewise inconvenient because of the need for two shift keys.
>
> Defining these keys in addition to the existing binding for 'undo'
> can't do direct harm.  But it may disappoint the users you're trying
> to help.

The users we’re trying to help are already used to Redo being bound to
Ctrl+Shift+Z (because Redo is the inverse of Undo which is usually on
Ctrl+Z).

Re: Changes for emacs 28

[Eli Zaretskii]

> From: Yuri Khan <yuri.v.khan@gmail.com>
> Date: Sun, 13 Sep 2020 16:49:05 +0700
> Cc: Ergus <spacibba@aol.com>, Emacs developers <emacs-devel@gnu.org>, rekado@elephly.net, 
> 	Dmitry Gutov <dgutov@yandex.ru>, Gregory Heytings <ghe@sdf.org>, Eli Zaretskii <eliz@gnu.org>, 
> 	Drew Adams <drew.adams@oracle.com>
> 
> The users we’re trying to help are already used to Redo being bound to
> Ctrl+Shift+Z (because Redo is the inverse of Undo which is usually on
> Ctrl+Z).

I'm used to Redo bound to Ctrl-Y.

Re: Changes for emacs 28

[Dmitry Gutov]

On 13.09.2020 17:30, Eli Zaretskii wrote:
>> The users we’re trying to help are already used to Redo being bound to
>> Ctrl+Shift+Z (because Redo is the inverse of Undo which is usually on
>> Ctrl+Z).
> I'm used to Redo bound to Ctrl-Y.

Do you use it in Emacs as well?

If you have an idea how to accommodate this kind of existing habit here, 
we're all ears, of course. But I think the best one could hope is to 
make it a part of cua-mode.

Re: Changes for emacs 28

[Eli Zaretskii]

> Cc: rms@gnu.org, spacibba@aol.com, emacs-devel@gnu.org, rekado@elephly.net,
>  ghe@sdf.org, drew.adams@oracle.com
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Sun, 13 Sep 2020 20:36:04 +0300
> 
> On 13.09.2020 17:30, Eli Zaretskii wrote:
> >> The users we’re trying to help are already used to Redo being bound to
> >> Ctrl+Shift+Z (because Redo is the inverse of Undo which is usually on
> >> Ctrl+Z).
> > I'm used to Redo bound to Ctrl-Y.
> 
> Do you use it in Emacs as well?
> 
> If you have an idea how to accommodate this kind of existing habit here, 
> we're all ears, of course.

There are more ears here than just yours.

Re: Changes for emacs 28

[Dmitry Gutov]

On 13.09.2020 06:57, Richard Stallman wrote:
> [[[ 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. ]]]
> 
> There are two problems with C-?:
> 
> * It requires two shift keys, so it is inconvenient.

Do you mean two modifier keys?

It's just one shift key. C-? is the same as C-S-/, at least in GUI version.

 > (The bindings for undo ensure it can be typed with just one
 > shift key on all usual terminals.)

C-_, one of the two existing bindings for 'undo', has the exact same 
problem. Which, for undo, is more significant, I'd say.

> * It does not exist at all on ttys.  (I don't know whether we can
> change that on Linux consoles.)

I don't know either.

It _is_ a drawback, especially for users who tend to switch between GUI 
and terminal, but I don't have any better suggestions about that. But as 
far as new users are concerned, GUI Emacs is a lot more popular.

> Whether constitutes a problem for the undo-redo feature depends on the
> precise meanings of the two commands.  I don't know those details
> so I can't judge.

I don't think it is. As Juri said, the target audience of this feature 
expects 'undo' to be on Ctrl-Z and 'redo' on Ctrl-Shift-Z (though many 
editors bind it to Ctrl-Y as well).

> M-_ is likewise inconvenient because of the need for two shift keys.

I guess you do mean "two modifier keys". See above.

Re: Changes for emacs 28

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

  >  > (The bindings for undo ensure it can be typed with just one
  >  > shift key on all usual terminals.)

  > C-_, one of the two existing bindings for 'undo', has the exact same 
  > problem.

Not on a tty.  On a tty you can type Ctrl-minus and you get that
character.

Undo has two 1-key bindings, C-_ for ttys and C-/ for consoles with
the full space of input characters.  Each requires just one shift key
on the consoles it is meant for.




-- 
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: Changes for emacs 28

[Dmitry Gutov]

On 14.09.2020 06:51, Richard Stallman wrote:
> [[[ 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. ]]]
> 
>    >  > (The bindings for undo ensure it can be typed with just one
>    >  > shift key on all usual terminals.)
> 
>    > C-_, one of the two existing bindings for 'undo', has the exact same
>    > problem.
> 
> Not on a tty.  On a tty you can type Ctrl-minus and you get that
> character.

Interesting. I never would have guessed.

> Undo has two 1-key bindings, C-_ for ttys and C-/ for consoles with
> the full space of input characters.  Each requires just one shift key
> on the consoles it is meant for.

I see. There is certain elegance in that, but I'd say it's not very 
discoverable. Especially when you get C-_ by typing Ctrl-/ in xterm, but 
you need to press Ctrl-- in a tty. And with a yet another behavior in X.

Going back to the proposed bindings for 'redo', a certain popular 
package we have seen mentioned in this discussion uses them (undo-tree). 
So they have been proven in the field, for many years.

Most new users might prefer to see C-z for undo and C-S-z for redo, of 
course, but I don't think we can do anything about that, other than add 
a C-S-z binding to cua-mode.

Re: Changes for emacs 28

[Stefan Monnier]

> Most new users might prefer to see C-z for undo and C-S-z for redo, of
> course, but I don't think we can do anything about that, other than add
> a C-S-z binding to cua-mode.

C-S-z could be added globally by default.  It's currently unbound.


        Stefan

Re: Changes for emacs 28

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

  > I see. There is certain elegance in that, but I'd say it's not very 
  > discoverable.

It is very prominent in documentation, and C-h w will tell you.

-- 
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: Changes for emacs 28

[Dmitry Gutov]

On 15.09.2020 07:43, Richard Stallman wrote:
>    > I see. There is certain elegance in that, but I'd say it's not very
>    > discoverable.
> 
> It is very prominent in documentation, and C-h w will tell you.

It tells me that C-_ is one of the bindings.

It doesn't tell me that C-- will map to C-_.

https://www.gnu.org/software/emacs/manual/html_node/emacs/Undo.html 
mentions, in a footnote, that C-/ is sometimes mapped to C-_. Which is 
true for gnome-terminal, but for ttys on my machine.

There's no mention of C-- being mapped in the manual.

Re: Changes for emacs 28

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

  > It tells me that C-_ is one of the bindings.

  > It doesn't tell me that C-- will map to C-_.

I am surprised.  I thought this was documented.
So I sent a patch to mention it in the Emacs manual.

-- 
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: Changes for emacs 28

[Arthur Miller]

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. ]]]
>
> There are two problems with C-?:
>
> * It requires two shift keys, so it is inconvenient.
> (The bindings for undo ensure it can be typed with just one
> shift key on all usual terminals.)
Doesn't that depend on the keyboard layout?

Some of bindings that you lucky us-layout people use are inconvenient
for oss others. We have to press shift+alt graphic and do some serious
finger gymnastics sometimes to use some Emacs bindings. I think there is
not much to do there, not everybody will be always happy with all
default bindings. We can just re-bind (what I do at least) what we find
awkward.

Could C-- work? Then undo functions will be on C-_ and C--, kind of
similar?

Re: Changes for emacs 28

[Stefan Kangas]

Arthur Miller <arthur.miller@live.com> writes:

> Could C-- work? Then undo functions will be on C-_ and C--, kind of
> similar?

That would be backwards incompatible: C-- runs the command
negative-argument (found in global-map).

Re: Changes for emacs 28

[T.V Raman]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=gb18030, Size: 1072 bytes --]

Richard Stallman <rms@gnu.org> writes:

For what it's worth, I have C-x u undo-only C-x C-u undo-redo > [[[ 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. ]]]
>
> There are two problems with C-?:
>
> * It requires two shift keys, so it is inconvenient.
> (The bindings for undo ensure it can be typed with just one
> shift key on all usual terminals.)
>
> * It does not exist at all on ttys.  (I don't know whether we can
> change that on Linux consoles.)
>
> Whether constitutes a problem for the undo-redo feature depends on the
> precise meanings of the two commands.  I don't know those details
> so I can't judge.
>
> M-_ is likewise inconvenient because of the need for two shift keys.
>
> Defining these keys in addition to the existing binding for 'undo'
> can't do direct harm.  But it may disappoint the users you're trying
> to help.

-- 
7©4 Id: kg:/m/0285kf1  •0Ü8

RE: Changes for emacs 28

[Drew Adams]

> BTW: everybody agrees in set undo-redo to C-? and M-_??

;-)

Do you think everyone agrees on _any_ default key bindings?
___


Such keys should be used/saved for repeatable commands
(hold down the key to repeat command) or for use as
prefix keys.

(FWIW, I use `M-_' for `forward-whitespace'.)

Re: Changes for emacs 28

[Eli Zaretskii]

> Cc: rekado@elephly.net, ghe@sdf.org, emacs-devel@gnu.org,
>  drew.adams@oracle.com
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Sat, 12 Sep 2020 00:00:48 +0300
> 
> > As long as we keep this on the menu and the tool bar, there will be no
> > reason for a "war".
> 
> So there will be contradiction between the menu and the keyboard?

Yes.  We already have quite a few of them, so one or two more cannot
hurt.

> > How can it be confusing that 2 different commands produce different
> > results?  Why isn't it confusing today, when we already have these 2
> > commands?
> 
> The menu item doesn't exactly say which command it is invoking.

It does, if you invoke "C-h k".

If you don't ask Emacs what the menu item invokes, then the text of
the menu item and the help-echo string are the only description you
get, and that is so for all the other menu items.  So there's nothing
new here.

> So I think that statement is missing the point: we should endeavor for 
> predictable and consistent sets of menu items, key bindings, and other 
> features.

I agree, but the criteria for "predictable and consistent" might be
something other than "make the keybindings and menus invoke identical
commands".  Because if that's the criteria, we are already in
violation of them.

Re: Changes for emacs 28

[Dmitry Gutov]

On 12.09.2020 09:12, Eli Zaretskii wrote:
>> Cc: rekado@elephly.net, ghe@sdf.org, emacs-devel@gnu.org,
>>   drew.adams@oracle.com
>> From: Dmitry Gutov <dgutov@yandex.ru>
>> Date: Sat, 12 Sep 2020 00:00:48 +0300
>>
>>> As long as we keep this on the menu and the tool bar, there will be no
>>> reason for a "war".
>>
>> So there will be contradiction between the menu and the keyboard?
> 
> Yes.  We already have quite a few of them, so one or two more cannot
> hurt.

I'm looking to improve the current state of affairs.

Also: confusion about certain basic operations are likely to hit new 
users harder than confusions about other things.

>>> How can it be confusing that 2 different commands produce different
>>> results?  Why isn't it confusing today, when we already have these 2
>>> commands?
>>
>> The menu item doesn't exactly say which command it is invoking.
> 
> It does, if you invoke "C-h k".

Irrelevant, as long as we're talking about new user experience.

> If you don't ask Emacs what the menu item invokes, then the text of
> the menu item and the help-echo string are the only description you
> get, and that is so for all the other menu items.  So there's nothing
> new here.

Hence we shouldn't create a confusing menu item like this.

>> So I think that statement is missing the point: we should endeavor for
>> predictable and consistent sets of menu items, key bindings, and other
>> features.
> 
> I agree, but the criteria for "predictable and consistent" might be
> something other than "make the keybindings and menus invoke identical
> commands".  Because if that's the criteria, we are already in
> violation of them.

That doesn't mean we're not allowed to improve things in specific cases.

Re: Changes for emacs 28

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

  > - Add the extra icon in the toolbar.
  > - Change the undo action in menu-bar and tool-bar by undo-only instead.
  > - Bind undo-redo to something in the keyboard.

Which key?  Finding a good key for this is the hardest part of the
idea.  You need to bite the bullet and make specific proposals.

-- 
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: Changes for emacs 28

[Dmitry Gutov]

On 12.09.2020 06:21, Richard Stallman wrote:
>    > - Add the extra icon in the toolbar.
>    > - Change the undo action in menu-bar and tool-bar by undo-only instead.
>    > - Bind undo-redo to something in the keyboard.
> 
> Which key?  Finding a good key for this is the hardest part of the
> idea.  You need to bite the bullet and make specific proposals.

Proposal has already been made: C-? and M-_

Re: Changes for emacs 28

[Ergus]

On Sat, Sep 12, 2020 at 02:36:45PM +0300, Dmitry Gutov wrote:
>On 12.09.2020 06:21, Richard Stallman wrote:
>>   > - Add the extra icon in the toolbar.
>>   > - Change the undo action in menu-bar and tool-bar by undo-only instead.
>>   > - Bind undo-redo to something in the keyboard.
>>
>>Which key?  Finding a good key for this is the hardest part of the
>>idea.  You need to bite the bullet and make specific proposals.
>
>Proposal has already been made: C-? and M-_

We can't use C-?; it conflicts with some old terminal interfaces we support.

Re: Changes for emacs 28

[Dmitry Gutov]

On 12.09.2020 15:42, Ergus wrote:
> We can't use C-?; it conflicts with some old terminal interfaces we 
> support.

IIUC it simply won't work in those terminals.

But that's what we'll have the other binding for (M-_).

Re: Changes for emacs 28

[Ergus]

On Sat, Sep 12, 2020 at 07:37:21PM +0300, Dmitry Gutov wrote:
>On 12.09.2020 15:42, Ergus wrote:
>>We can't use C-?; it conflicts with some old terminal interfaces we 
>>support.
>
>IIUC it simply won't work in those terminals.
>
>But that's what we'll have the other binding for (M-_).
>
Binding it as "\C-?" actually doesn't work, ?C-? or \^-? either. Only
with kbd I made it work.

So I prefer to ask before breaking anything.

Re: Changes for emacs 28

[Dmitry Gutov]

On 12.09.2020 19:46, Ergus wrote:
> Binding it as "\C-?" actually doesn't work, ?C-? or \^-? either. Only
> with kbd I made it work.

Using kbd is just fine.

(kbd "C-?") evaluates to [67108927], which seems to show right away that 
it's GUI-only and is unlikely to affect anything in terminal.

> So I prefer to ask before breaking anything.

Or you can post a patch and wait for comments.

Re: Changes for emacs 28

[Dmitry Gutov]

On 11.09.2020 15:04, Eli Zaretskii wrote:
>> Cc: rekado@elephly.net, ghe@sdf.org, spacibba@aol.com, drew.adams@oracle.com,
>>   emacs-devel@gnu.org
>> From: Dmitry Gutov <dgutov@yandex.ru>
>> Date: Fri, 11 Sep 2020 14:09:17 +0300
>>
>> On 11.09.2020 13:41, Eli Zaretskii wrote:
>>> If people prefer that, we could change the binding, I won't object.
>>
>> But then we'll have no binding for `undo-redo`, just a menu item?
>>
>> Or would you be fine with adding a binding for it too?
> 
> Why do we need a binding for it in the default configuration?  Not
> every command available through the menus has a keybinding by default.

Existing user expectations, regarding undo-redo, coming from just about 
any other editor or software with text inputs (such as Firefox).

I'm pretty confident that any user that will use 'redo' from the menu 
will look for the binding for it.

Also: we do make an effort to create key bindings for commands that we 
anticipate will be used often. If the user uses 'redo' at all, they will 
do it frequently.

Additionally, the difference between 'undo' and 'undo-only' is likely to 
be surprising for such users.

Re: Changes for emacs 28

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

  > > 'undo'.
  > > 
  > > As opposed to 'undo-only'.

  > If people prefer that, we could change the binding, I won't object.

I might object to this.  People should make a concrete proposal,
then we can all think about 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: Changes for emacs 28

[Ergus]

On Fri, Sep 11, 2020 at 01:10:29PM +0300, Dmitry Gutov wrote:
>On 11.09.2020 09:39, Eli Zaretskii wrote:
>>>Date: Fri, 11 Sep 2020 01:14:20 +0200
>>>From: Ergus<spacibba@aol.com>
>>>Cc: Ricardo Wurmus<rekado@elephly.net>, Gregory Heytings<ghe@sdf.org>,
>>>  emacs-devel@gnu.org
>>>
>>>3) Is it possible/should we: add a redo icon in the toolbar
>>>conditionally when the mode is enabled?
>>>
>>>else
>>>
>>>4) I see a redo added in the menu-bar unconditionally... should we do
>>>the same in the toolbar unconditionally?
>>I indeed think that the Redo icon should be added unconditionally
>>(enabled only when there's something to redo, like the menu item).
>
>Are you not worried about the divergence between the menu items and 
>the toolbar, and the actual available bindings?
>
>And also about the fact the menu item next to 'redo' doesn't call 
>'undo-only'? Which will be contrary to the expectations of users who 
>know the concept of 'redo' from other programs.
>
>I think this created a potential for additional user confusion.
>
Yes these were/are exactly my concerns. 

>A global mode like undo-redo-mode, like suggested by Ergus, would 
>avoid both of these problems. We'd only need to find a key for 
>'undo-redo'.
>
>Perhaps, 'M-_' and 'C-?'? That's what undo-tree uses by default.

I use C-/ for undo so C-? in my keyboard is C-S-/ so it is perfect. But
for people using C-_ (C-S--) maybe M-_ (M-S--) will make more
sense (BTW: in Spanish keyboard it does).

Re: Changes for emacs 28

[Dmitry Gutov]

On 11.09.2020 13:59, Ergus wrote:
>> A global mode like undo-redo-mode, like suggested by Ergus, would 
>> avoid both of these problems. We'd only need to find a key for 
>> 'undo-redo'.
>>
>> Perhaps, 'M-_' and 'C-?'? That's what undo-tree uses by default.
> 
> I use C-/ for undo so C-? in my keyboard is C-S-/ so it is perfect. But
> for people using C-_ (C-S--) maybe M-_ (M-S--) will make more
> sense (BTW: in Spanish keyboard it does).

Right, and I did mean using both key sequences.

Since default Emacs binds 'undo' to both 'C-_' and 'C-/', it would make 
sense to add a corresponding 'redo' binding to each using nearby keys.

Re: Changes for emacs 28

[Juri Linkov]

>>> A global mode like undo-redo-mode, like suggested by Ergus, would avoid
>>> both of these problems. We'd only need to find a key for 'undo-redo'.
>>>
>>> Perhaps, 'M-_' and 'C-?'? That's what undo-tree uses by default.
>> I use C-/ for undo so C-? in my keyboard is C-S-/ so it is perfect. But
>> for people using C-_ (C-S--) maybe M-_ (M-S--) will make more
>> sense (BTW: in Spanish keyboard it does).
>
> Right, and I did mean using both key sequences.
>
> Since default Emacs binds 'undo' to both 'C-_' and 'C-/', it would make
> sense to add a corresponding 'redo' binding to each using nearby keys.

What about adding a transient mode activated by a key sequence.
When the mode is active, it will enable arrow keys to navigate the
undo history in both directions: <left> to undo, and <right> to redo.
This is similar to 'indent-rigidly' bound to 'C-x TAB':

  If called interactively with no prefix argument, activate a
  transient mode in which the indentation can be adjusted interactively
  by typing <left>, <right>, <S-left>, or <S-right>.
  Typing any other key deactivates the transient mode.

Re: Changes for emacs 28

[Ergus]

On Fri, Sep 11, 2020 at 09:39:30AM +0300, Eli Zaretskii wrote:
>> Date: Fri, 11 Sep 2020 01:14:20 +0200
>> From: Ergus <spacibba@aol.com>
>> Cc: Ricardo Wurmus <rekado@elephly.net>, Gregory Heytings <ghe@sdf.org>,
>>  emacs-devel@gnu.org
>>
>> 3) Is it possible/should we: add a redo icon in the toolbar
>> conditionally when the mode is enabled?
>>
>> else
>>
>> 4) I see a redo added in the menu-bar unconditionally... should we do
>> the same in the toolbar unconditionally?
>
>I indeed think that the Redo icon should be added unconditionally
>(enabled only when there's something to redo, like the menu item).

Then Caio Henrique can add his patch from a previous mail to master.

I tried it but there is a problem enabling disabling the icon. It
doesn't enable automatically when I do an undo until I click with the
mouse somewhere.

Maybe it is a redisplay problem?

Re: Changes for emacs 28

[Eli Zaretskii]

> Date: Fri, 11 Sep 2020 12:15:09 +0200
> From: Ergus <spacibba@aol.com>
> Cc: caiohcs0@gmail.com, emacs-devel@gnu.org
> 
> I tried it but there is a problem enabling disabling the icon. It
> doesn't enable automatically when I do an undo until I click with the
> mouse somewhere.
> 
> Maybe it is a redisplay problem?

No, because the Cut and Paste button have no such problems.

Re: Changes for emacs 28

[Caio Henrique]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Fri, 11 Sep 2020 12:15:09 +0200
>> From: Ergus <spacibba@aol.com>
>> Cc: caiohcs0@gmail.com, emacs-devel@gnu.org
>> 
>> I tried it but there is a problem enabling disabling the icon. It
>> doesn't enable automatically when I do an undo until I click with the
>> mouse somewhere.
>> 
>> Maybe it is a redisplay problem?
>
> No, because the Cut and Paste button have no such problems.

I tried that code again and I experienced the same thing as Ergus, but
only in some cases. If I:
1. launch emacs -Q
2. type only the letter "a"
3. click on the "Undo" button on the toolbar

Then the "Redo" button on the toolbar activates and all works well.

But if I try:
1. launch emacs -Q
2. type the letter "a"
3. press RET to insert newline
4. type the letter "b"
5. click on the "Undo" button on the toolbar

In this case the "Redo" toolbar button doesn't activate (but the "Redo"
button on the menu bar works fine). Then if I click with the mouse
anywhere inside the buffer, then the toolbar menu activates.
I don't know what the problem is, any ideas?

> Thanks, but please add a help-echo text for that button.  The menu
> item perhaps could do without it, but not the tool-bar button.

Isn't the help-echo text the one that appears when I place my mouse over
the toolbar button? Isn't this text the same one used for the menu bar
buttons? When I place my mouse over "Redo" on the toolbar, it says "Undo
last undo".

Re: Changes for emacs 28

[Eli Zaretskii]

> From: Caio Henrique <caiohcs0@gmail.com>
> Cc: Ergus <spacibba@aol.com>,  caiohcs0@gmail.com,  emacs-devel@gnu.org
> Date: Fri, 11 Sep 2020 11:02:54 -0300
> 
> >> Maybe it is a redisplay problem?
> >
> > No, because the Cut and Paste button have no such problems.
> 
> I tried that code again and I experienced the same thing as Ergus, but
> only in some cases. If I:
> 1. launch emacs -Q
> 2. type only the letter "a"
> 3. click on the "Undo" button on the toolbar
> 
> Then the "Redo" button on the toolbar activates and all works well.
> 
> But if I try:
> 1. launch emacs -Q
> 2. type the letter "a"
> 3. press RET to insert newline
> 4. type the letter "b"
> 5. click on the "Undo" button on the toolbar
> 
> In this case the "Redo" toolbar button doesn't activate (but the "Redo"
> button on the menu bar works fine). Then if I click with the mouse
> anywhere inside the buffer, then the toolbar menu activates.
> I don't know what the problem is, any ideas?

Did you look at how Cut/Paste solve the same problem?

> > Thanks, but please add a help-echo text for that button.  The menu
> > item perhaps could do without it, but not the tool-bar button.
> 
> Isn't the help-echo text the one that appears when I place my mouse over
> the toolbar button? Isn't this text the same one used for the menu bar
> buttons? When I place my mouse over "Redo" on the toolbar, it says "Undo
> last undo".

Hmm, when I tried that, I didn't see any help-echo for the Redo menu
item.  I do see it now, so I guess I did something wrong when I tried
that back then.  Sorry about that.

Re: Changes for emacs 28

[Ergus]

On Fri, Sep 11, 2020 at 11:02:54AM -0300, Caio Henrique wrote:
>Eli Zaretskii <eliz@gnu.org> writes:
>
>>> Date: Fri, 11 Sep 2020 12:15:09 +0200
>>> From: Ergus <spacibba@aol.com>
>>> Cc: caiohcs0@gmail.com, emacs-devel@gnu.org
>>>
>>> I tried it but there is a problem enabling disabling the icon. It
>>> doesn't enable automatically when I do an undo until I click with the
>>> mouse somewhere.
>>>
>>> Maybe it is a redisplay problem?
>>
>> No, because the Cut and Paste button have no such problems.
>
>I tried that code again and I experienced the same thing as Ergus, but
>only in some cases. If I:
>1. launch emacs -Q
>2. type only the letter "a"
>3. click on the "Undo" button on the toolbar
>
>Then the "Redo" button on the toolbar activates and all works well.
>
>But if I try:
>1. launch emacs -Q
>2. type the letter "a"
>3. press RET to insert newline
>4. type the letter "b"
>5. click on the "Undo" button on the toolbar
>
>In this case the "Redo" toolbar button doesn't activate (but the "Redo"
>button on the menu bar works fine). Then if I click with the mouse
>anywhere inside the buffer, then the toolbar menu activates.
>I don't know what the problem is, any ideas?
>
>> Thanks, but please add a help-echo text for that button.  The menu
>> item perhaps could do without it, but not the tool-bar button.
>
>Isn't the help-echo text the one that appears when I place my mouse over
>the toolbar button? Isn't this text the same one used for the menu bar
>buttons? When I place my mouse over "Redo" on the toolbar, it says "Undo
>last undo".
For me it happens always if I do:

emacs -Q
Do anything
C-/  (for undo)

Independently of how many times I do "undo" with C-/ it never gets
activated. If I click anywhere then it does.

Re: Changes for emacs 28

[Caio Henrique]

Ergus <spacibba@aol.com> writes:

> For me it happens always if I do:
>
> emacs -Q
> Do anything
> C-/  (for undo)
>
> Independently of how many times I do "undo" with C-/ it never gets
> activated. If I click anywhere then it does.

Sorry, I still don't know what is wrong. Looking the code of other
buttons like copy and paste, I don't know what I'm missing.

Re: Changes for emacs 28

[Ergus]

On Fri, Sep 11, 2020 at 06:29:02PM -0300, Caio Henrique wrote:
>Ergus <spacibba@aol.com> writes:
>
>> For me it happens always if I do:
>>
>> emacs -Q
>> Do anything
>> C-/  (for undo)
>>
>> Independently of how many times I do "undo" with C-/ it never gets
>> activated. If I click anywhere then it does.
>
>Sorry, I still don't know what is wrong. Looking the code of other
>buttons like copy and paste, I don't know what I'm missing.
>

Actually this seems to be a bug somewhere updating the {tool,menu}-bars.

Try this:

1) emacs -Q
2) Insert this in scratch:
(global-set-key [menu-bar edit] 'undefined)

3) And at the end of the line do:
C-x C-e

The menu-bar won't hide Edit menu until you click it and for me it
blocks emacs after that when I try to reinsert text.

The backtrace shows this:

(gdb) bt
#0  0x00007fa6ed75cc96 in pselect () at /usr/lib/libc.so.6
#1  0x000055def30f481c in really_call_select (arg=0x7ffde562dc70) at ../../src/thread.c:592
#2  0x000055def30f55ff in flush_stack_call_func (arg=0x7ffde562dc70, func=0x55def30f47b0 <really_call_select>) at ../../src/lisp.h:3791
#3  thread_select (func=<optimized out>, max_fds=max_fds@entry=9, rfds=rfds@entry=0x7ffde562dd70, wfds=wfds@entry=0x7ffde562ddf0, efds=efds@entry=0x0, timeout=timeout@entry=0x7ffde562e3a0, sigmask=0x0)
     at ../../src/thread.c:624
#4  0x000055def310faeb in xg_select (fds_lim=9, rfds=rfds@entry=0x7ffde562e4b0, wfds=wfds@entry=0x7ffde562e530, efds=efds@entry=0x0, timeout=timeout@entry=0x7ffde562e3a0, sigmask=sigmask@entry=0x0)
     at ../../src/xgselect.c:131
#5  0x000055def30d2d85 in wait_reading_process_output
     (time_limit=time_limit@entry=0, nsecs=nsecs@entry=0, read_kbd=read_kbd@entry=-1, do_display=true, wait_for_cell=wait_for_cell@entry=0x0, wait_proc=wait_proc@entry=0x0, just_wait_proc=0)
     at ../../src/process.c:5601
#6  0x000055def301aa5d in kbd_buffer_get_event (end_time=0x0, used_mouse_menu=0x7ffde562ed1b, kbp=<synthetic pointer>) at ../../src/lisp.h:1007
#7  read_event_from_main_queue (used_mouse_menu=0x7ffde562ed1b, local_getcjmp=0x7ffde562e940, end_time=0x0) at ../../src/keyboard.c:2156
#8  read_decoded_event_from_main_queue (used_mouse_menu=<optimized out>, prev_event=<optimized out>, local_getcjmp=<optimized out>, end_time=<optimized out>) at ../../src/keyboard.c:2220
#9  read_char (commandflag=1, map=0x55def4e4b563, prev_event=0x0, used_mouse_menu=0x7ffde562ed1b, end_time=0x0) at ../../src/keyboard.c:2830
#10 0x000055def301d1d4 in read_key_sequence (keybuf=<optimized out>, prompt=0x0, dont_downcase_last=<optimized out>, can_return_switch_frame=true, fix_current_buffer=true, prevent_redisplay=<optimized out>)
     at ../../src/keyboard.c:9547
#11 0x000055def301eb5c in command_loop_1 () at ../../src/lisp.h:1007
#12 0x000055def308c647 in internal_condition_case (bfun=bfun@entry=0x55def301e970 <command_loop_1>, handlers=handlers@entry=0x90, hfun=hfun@entry=0x55def3015080 <cmd_error>) at ../../src/eval.c:1356
#13 0x000055def300f7b4 in command_loop_2 (ignore=ignore@entry=0x0) at ../../src/lisp.h:1007
#14 0x000055def308c5a1 in internal_catch (tag=tag@entry=0xd5f0, func=func@entry=0x55def300f790 <command_loop_2>, arg=arg@entry=0x0) at ../../src/eval.c:1117
#15 0x000055def300f75b in command_loop () at ../../src/lisp.h:1007
#16 0x000055def3014c96 in recursive_edit_1 () at ../../src/keyboard.c:714
#17 0x000055def3014fc2 in Frecursive_edit () at ../../src/keyboard.c:786
#18 0x000055def2f29dac in main (argc=2, argv=<optimized out>) at
../../src/emacs.c:2047

But it is totally frozen.

Re: Changes for emacs 28

[Eli Zaretskii]

> Date: Sat, 12 Sep 2020 05:22:32 +0200
> From: Ergus <spacibba@aol.com>
> Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
> 
> 1) emacs -Q
> 2) Insert this in scratch:
> (global-set-key [menu-bar edit] 'undefined)
> 
> 3) And at the end of the line do:
> C-x C-e
> 
> The menu-bar won't hide Edit menu until you click it and for me it
> blocks emacs after that when I try to reinsert text.

Then don't do that, okay?

Re: Changes for emacs 28

[Ergus]

On September 12, 2020 8:30:48 AM GMT+02:00, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Sat, 12 Sep 2020 05:22:32 +0200
>> From: Ergus <spacibba@aol.com>
>> Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
>> 
>> 1) emacs -Q
>> 2) Insert this in scratch:
>> (global-set-key [menu-bar edit] 'undefined)
>> 
>> 3) And at the end of the line do:
>> C-x C-e
>> 
>> The menu-bar won't hide Edit menu until you click it and for me it
>> blocks emacs after that when I try to reinsert text.
>
>Then don't do that, okay?

Ok. But this is a modified version of the example code in the elisp manual for removing elements from the menu. Is the manual outdated?

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

Re: Changes for emacs 28

[Eli Zaretskii]

> Date: Sat, 12 Sep 2020 10:27:58 +0200
> CC: caiohcs0@gmail.com
> From: Ergus <spacibba@aol.com>
> 
> >> The menu-bar won't hide Edit menu until you click it and for me it
> >> blocks emacs after that when I try to reinsert text.
> >
> >Then don't do that, okay?
> 
> Ok. But this is a modified version of the example code in the elisp manual for removing elements from the menu. Is the manual outdated?

Does the unmodified version of the code in the manual cause the same
problem?  If so, we'd need to revise it.

Re: Changes for emacs 28

[Ergus]

On September 12, 2020 10:38:26 AM GMT+02:00, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Sat, 12 Sep 2020 10:27:58 +0200
>> CC: caiohcs0@gmail.com
>> From: Ergus <spacibba@aol.com>
>> 
>> >> The menu-bar won't hide Edit menu until you click it and for me it
>> >> blocks emacs after that when I try to reinsert text.
>> >
>> >Then don't do that, okay?
>> 
>> Ok. But this is a modified version of the example code in the elisp
>manual for removing elements from the menu. Is the manual outdated?
>
>Does the unmodified version of the code in the manual cause the same
>problem?  If so, we'd need to revise it.

In the manual says that the code is used by dired to disable the edit menu. But dired doesn't disable it. I tried the original example and yes, I have the same 2 problems: needs a click and clocks emacs.

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

Re: Changes for emacs 28

[Eli Zaretskii]

> Date: Sat, 12 Sep 2020 11:38:40 +0200
> CC: emacs-devel@gnu.org,caiohcs0@gmail.com
> From: Ergus <spacibba@aol.com>
> 
> >Does the unmodified version of the code in the manual cause the same
> >problem?  If so, we'd need to revise it.
> 
> In the manual says that the code is used by dired to disable the edit menu. But dired doesn't disable it.

The code is commented out in dired.el.

> I tried the original example and yes, I have the same 2 problems: needs a click and clocks emacs.

It doesn't do that here, FWIW.

Please submit a full bug report with the recipe to reproduce.

Re: Changes for emacs 28

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

  > 1) Could we add an option to enable choosing between the traditional
  > undo or undo-only + undo-redo? something like undo-redo-mode?

That is not concrete.  What exactly is the change in key bindings
you propose?

(Choosing key bindings is the hard part.)


-- 
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: Changes for emacs 28

[Ergus]

On Fri, Sep 11, 2020 at 11:20:04PM -0400, Richard Stallman wrote:
>[[[ 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. ]]]
>
>  > 1) Could we add an option to enable choosing between the traditional
>  > undo or undo-only + undo-redo? something like undo-redo-mode?
>
>That is not concrete.  What exactly is the change in key bindings
>you propose?
>
>(Choosing key bindings is the hard part.)
>
>
I already commented and added some code; but maybe the changes does not
worth creating a mode because undo-redo will be enabled bu default in
the menu-bar.

But the idea was to do:

[remap undo] -> undo-only

+

C-? and M-_ -> undo-redo

But binding C-? could be problematic in some terminals so probably is
better to avoid 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: Changes for emacs 28

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

  > But the idea was to do:

  > [remap undo] -> undo-only

  > +

  > C-? and M-_ -> undo-redo

I wonder if it is possible to modify undo-redo
to work in a meaningful way with the ordinary undo command.
More precisely, if you invoke 'undo-redo' that would cause
'undo' to start acting like 'undo-only' for the time being.

'undo' would go back to normal undo the next time you start a new
chain of undos.

In effect, this way we would have both kinds of undo _behavior_
with just one undo _command_.  That might eliminate the confusion.

-- 
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: Changes for emacs 28

[Dmitry Gutov]

On 13.09.2020 07:07, Richard Stallman wrote:

> I wonder if it is possible to modify undo-redo
> to work in a meaningful way with the ordinary undo command.
> More precisely, if you invoke 'undo-redo' that would cause
> 'undo' to start acting like 'undo-only' for the time being.
> 
> 'undo' would go back to normal undo the next time you start a new
> chain of undos.
> 
> In effect, this way we would have both kinds of undo _behavior_
> with just one undo _command_.  That might eliminate the confusion.

I am wary of this kind of hidden state, which makes a command behave in 
two distinctly different ways. It is likely to increase confusion, 
rather than eliminate it.

It maybe could have worked if people called 'redo' before 'undo', thus 
creating a consistent indication of intent.

But the order is exactly the opposite, of course.

Re: Changes for emacs 28

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

  > I am wary of this kind of hidden state, which makes a command behave in 
  > two distinctly different ways. It is likely to increase confusion, 
  > rather than eliminate it.

I am not convinced.  I urge someone to try implementing my suggestion
so people can see whether they like it.  That will be more useful than
speculating whether people will like 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: Changes for emacs 28

[Achilles Yuce]

Hey,


I was reading this thread and lost in the variety of choices, wondering:

How about something superior to anything and sophisticated for every
taste, shipping a learning algorithm inside/with Emacs?


Best regards,

          Achilles

Re: Changes for emacs 28

[Eli Zaretskii]

> From: Achilles Yuce <ayuce@posteo.mx>
> Date: Sat, 12 Sep 2020 17:28:17 +0300
> 
> How about something superior to anything and sophisticated for every
> taste, shipping a learning algorithm inside/with Emacs?

I think we will gratefully accept patches for that, thank you.

RE: Changes for emacs 28

[Drew Adams]

> > The mode will substitute undo with undo-only. This small contradiction
> > will start a war here.
> 
> As long as we keep this on the menu and the tool bar, there will be no
> reason for a "war".
> 
> > >> Having undo with an undo-redo in the same "state" could be confusing as
> > >> the normal undo could do also redo IMO.
> > >
> > >If the user uses the menus or the tool bar, the confusion will be
> > >spared, right?
> > >
> > If the user expects undo-only behavior; then having our undo will be
> > confusing because not expecting undo becoming a redo at some point.
> 
> How can it be confusing that 2 different commands produce different
> results?  Why isn't it confusing today, when we already have these 2
> commands?
> 
> > IMO we should have one (undo) or the other (undo-only + undo-edor) but
> > not mix them by default.
> 
> Whether to mix them or not is up to the user.

I'm coming to this late, and I won't go back & forth
about it.  I have only one thing to say about this
as a general topic (not limited to undo/redo etc.).

1. The Emacs menu should, above all, serve to help
discoverability.  Discovering what's possible, and
discovering what the current, "normal" _Emacs_ key
sequences are that correspond to menu items.

Above all, it's about discovering what _Emacs_ has
to offer.

2. The menu can _also_ include actions that help you
do some things for which we don't bind keyboard keys
- e.g., File > Open File.  This can be particularly
helpful for new users, who might expect something
that corresponds to what they're used to.

#2 is an addition.  It's not (should not be) the
main purpose of Emacs menus.  Emacs menus are for
all levels of Emacs users, and their main purpose
is for discovering - including rediscovering (i.e.,
finding) useful Emacs commands.  The main purpose
is #1, not #2.
___

#2 could (and does already, to some extent) apply
to undo/redo behavior.

IMO, we should definitely _not_ bind undo/redo
behavior to keys by default.  We should want to
lead new users to the _Emacs_ undo behavior,
which is superior to what they're used to.

IMO, this means classic Emacs `undo', but it could
mean `undo-tree' or some new variant that keeps
the power of classic Emacs `undo'.  It doesn't
mean the undo/redo that, say, an MS Word user is
used to.

A user who uses undo/redo from the menu bar should
_not_ see associated key bindings, and thus just
stay with what s?he is already used to instead of
discovering the superior behavior Emacs offers.

A new user will soon enough (maybe not immediately
but soon enough) find out how to bind keys to
commands, and can then bind the existing `undo'
keys (or any others) to undo/redo behavior, if
desired.

I think it would be a mistake if we go down the
road of both (a) offering menu items to accommodate
what newbies might be used to and (b) bind those
commands to keys.

That works against discoverability of Emacs's own,
superior commands.

This is a sense in which I agree with Dmitry about
inconsistency, but my reasoning is different.

Yes, we can discuss and disagree about whether
classic Emacs `undo' is actually superior to the
simple undo/redo that newbies might be used to.

But that's really beside the point I'm making,
which is not particularly about undo.

When we _do_ have a superior behavior, which we
agree about (which might not be the case for undo),
and that is bound to a keyboard key sequence, then
if we also decide to provide a menu item for an
inferior command with behavior closer to what a
newbie might expect, we should, as a general rule,
NOT bind the latter to a keyboard key by default.

RE: Changes for emacs 28

[arthur miller]

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


-------- Originalmeddelande --------
Från: Drew Adams <drew.adams@oracle.com>
Datum: 2020-09-12 18:29 (GMT+01:00)
Till: Arthur Miller <arthur.miller@live.com>, Ergus <spacibba@aol.com>
Kopia: Gregory Heytings <ghe@sdf.org>, emacs-devel@gnu.org, Dmitry Gutov <dgutov@yandex.ru>
Ämne: RE: Changes for emacs 28

> There is  a commercial package called Maya. They have a pop-up
> window/menu widget they call "hot box". In that pop-up they have all, or
> as few as chosen by the user, menus collected in a transparent window
> they pop-up under the mouse after the spacebar is hold for a while (I
> think it was half a second).

`mouse3.el' does this.  But it's initiated by
a right-click, not by holding the space bar.

It could be made to also or instead be initiated
by a keyboard key.  But why?  If the location of
the popup is at the mouse pointer, why make users
involve _both_ the mouse and the keyboard?

--------
Why?  Because you could continue activating menus with keyboard so you don't need to switch to mouse.

Why also a key even if mouse is active? Because holding spacebar with the thumb is very easy and can be done while moving mouse around,  but first reason is more interesting in my opinion.

Also observe that I don't say it is better or faster. As you commented on the part below, I mean it mostly as something that makes Emacs more explorable for people that use starter kits with minimalistic guis where menubars are off etc.

Emacs aleady has all menus explorable from context menu, C-mouse2 opens global menu. "Hot  box" widget differs in how it renders menus, and adds some context sensitive zones, so it is some kind of explorable all-in-one options widget, or I don't know how to call it. Like a global context menu on steroids with prettier presentation then ordinary context menu.

> Maybe such or similar widget could be good to have in Emacs? As a
> compromise between a minimal GUI, discoverability and avialability of
> menus even when gui elements are disabled? A context menu would still be
> faster though.

See `mouse3.el'.  I think it provides what I
think you've described.
-------

I have checked it. It is not even remotely close,  not in a slightest :-).

[-- Attachment #2: Type: text/html, Size: 3213 bytes --]

RE: Changes for emacs 28

[Drew Adams]

> P.S.  Please review your MUA settings, because they just caused Emacs
> to exclude the mailing list from the recipients, something that is
> unwanted.

+1.  I'm seeing this more lately in the mailing
lists, for some reason.  But I guess only from
specific users.

Re: Changes for emacs 28

[TEC]

Hello everyone,

This is my first time jumping onto the emacs-devel ML so don't be too
harsh :P (also, I'm not subscribed, so if there are anyone wants to
mention me, please CC me).

Yesterday, Gregory Heytings wrote
> FWIW, my own experience with this kind of tools is that those who do
> not have initially a good non-technical reason to use it ...
> This external motivation is necessary to "climb the learning curve",
> so to speak, and "better" defaults will have no influence on it.

If I may interject - I am exactly that user. I started using Emacs via.
Doom early this year, and I honestly doubt that I would still be using
it now otherwise.

The motivating factor was annoyance with JupyterLab. Doom allowed me to
'get started' easily. Looking back on it now, had I had to "climb the
mountain", I don't think I'd be here today. I think I can thank Doom for
turning "climb the mountain" into "slide down the rabbit-hole".

IMO the most significant factor is that Doom allowed me to "just get
started" with the tasks which caused my lingering interest to manifest
into installing. While now I couldn't imagine going without Emacs, that
initial ease was crucial.

If there is further interest in exactly how I think Doom worked for me
when vanilla Emacs wouldn't, I'm more than happy to elaborate :)

All the best,

Timothy.

Re: Changes for emacs 28

[Yuan Fu]

> 
> If there is further interest in exactly how I think Doom worked for me
> when vanilla Emacs wouldn't, I'm more than happy to elaborate :)
> 
> All the best,
> 
> Timothy.
> 

That’ll be very helpful, since many people on this ML are trying to imagine what a new user needs and can’t figure out. Even myself, just started using Emacs 3 years ago, can’t remember what problem I faced as a beginner anymore.

Yuan

Re: Changes for emacs 28

[TEC]

Yuan Fu <casouri@gmail.com> writes:

> That’ll be very helpful, since many people on this ML are trying to
> imagine what a new user needs and can’t figure out. Even myself, just
> started using Emacs 3 years ago, can’t remember what problem I faced
> as a beginner anymore.

All right then, I'll try to give a dot point version of my journey into
Emacs, and background/context. I hope this ends up being useful :)

* Prior editor experience (~2y in each) : total ~8 years
- I started off several years ago in IDLE (yes, that Tk python thing)
- I then used Komodo edit for a bit, started doing web stuff
- I shifted to Brackets for web stuff
- I shifted to VS Code, for everything

* VS Code
- VS Code is a great editor
- Everything just worked™, and the experience was generally smooth
- Used VS Code for: Python, Web(HTML,CSS,JS,TS), Rust, LaTeX
- I started writing /lots/ of LaTeX, so much that I became (for a
  period) the #3 contributor to the 'main' LaTeX extension (~500k users)
  and then went off and developed an extension to that extension :P
  (https://marketplace.visualstudio.com/items?itemName=tecosaur.latex-utilities)
- Why does this matter? At this point I'm *heavily* invested into VS
  Code. I'll need to be quite confident of a better experience in order
  to switch.
* VS Code pain points
- I like windows. VS Code's windows are independent electron instances.
  Not good (for UX, or RAM).
- Extension API felt a bit limiting a few times, I'd gaze at open
  issues/PRs in desperation that they'd actually be resolved

* Emacs, the warmup
- I'd heard a few things that sounded interesting about Emacs
  (read: faint inclination to see what the fuss was about)
- I like living in my editor (as long as it's comfortable), I didn't
  like it when I had to type into a barren textbox on the web (e.g.
  writing a GitHub issue).
- I became aware of the client/server archetecture, and EmacsAnywhere
- Installed EmacsAnywhere, and grabbed Spacemacs because it looked
  trendy (I'm serious, I /care/ about visuals, and the Spacemacs web page
  and screenshots were most attractive)
- Used a little bit, on and off, was pretty underwhelmed.
- Tried setting a few things in Spacemacs, found to be a pain --- recall
  I'm coming from a settings.json, and the layers seemed complicated
- Experience didn't end up meeting the Hype for me. Massive start up
  time also impeded further experimenting.
- Fell out of use

The good:
- Prompts on install asking how I wanted to have the main aspects set up
- Prompts on opening a new file type for the first time saying "We have
  a layer for this, would you like to install it?"

The bad:
- Felt clunky to use
- Felt quite opaque, like I didn't understand what I was doing and how
  it was working
- Sloooow to start

TLDR; gave Spacemacs a brief go, felt overwhelmed and underwhelmed at
the same time. Didn't end up going beyond a novelty.

* The drive to try Org-mode
- A few months later I started a Stats project using Jupyter Lab
- I missed my proper editor experience
- Version control was a pain
- I didn't like having to choose between opening a local server +
  browser, or trying to parse json >:(
- Did I mention I missed the 'full' editor experience? Just simple stuff
  like select word, replace matches. Trying to make any global (all
  cells) edits was a pain
- State was constantly a pain

* Org-mode, my ramp into Emacs pt.1 - vanilla
- I'd heard about Org-mode as a thing markdown + execution
- Maybe this could be better than Jupyter?
- However... I didn't like Spacemacs
- Removed Spacemacs
- Typed 'emacs' into a terminal
- Oh, this looks old.
- Successfully opened a file
  + Where are the line numbers?
  + Why aren't I given much information on the file
  + Where's the completion, the linting, etc.
  + I thought this was supposed to provide a richer experience than
    colourised nano?
- Tried to execute a command interactively (forget which command)
  + Typed M-x
  + Wait, this is just a text box
  + I don't know commands off by heart!
  + I want to be able to type key terms and see options!
- This isn't going to well
- I'm just slightly dissatisfied with notebooks, I don't want to "build
  my editor from scratch!" *before* I can get going with it!

Conclusion: vanilla emacs is:
 - faster starting
 - uglier, way uglier
 - Not sure how this is much better than Nano TBH (remember: new user, not
   intimately familiar with the benefits)
 - so lean that I don't get "basic" editor functionality (remember:
   coming from VS Code where on install I can open a common file and get
   completion, linting, and more! with common file types suggesting
   extensions which can be installed with a single click).
 - Difficult to use
 - Not something I can try in an afternoon
 - Likely not worth the time

* Org-mode, my ramp into Emacs pt.2 - Doom
- I wonder if there's some other option, closer to Spacemacs where I
  feel it actually helps me get stuff done, but isn't Spacemacs
- [Googles] finds out about Doom, screenshot looks way better
- Skim the readme, looks promising
- I run the one-line install
- Ok, so what do we have hear.
- Oh, look for

Re: Changes for emacs 28

[TEC]

NOTE: I accidentally sent a draft before this. Please disregard it.

Yuan Fu <casouri@gmail.com> writes:

> That’ll be very helpful, since many people on this ML are trying to
> imagine what a new user needs and can’t figure out. Even myself, just
> started using Emacs 3 years ago, can’t remember what problem I faced
> as a beginner anymore.

All right then, I'll try to give a dot point version of my journey into
Emacs, and background/context. I hope this ends up being useful :)

* Prior editor experience (~2y in each) : total ~8 years
- I started off several years ago in IDLE (yes, that Tk python thing)
- I then used Komodo edit for a bit, started doing web stuff
- I shifted to Brackets for web stuff
- I shifted to VS Code, for everything

* VS Code
- VS Code is a great editor
- Everything just worked™, and the experience was generally smooth
- Used VS Code for: Python, Web(HTML,CSS,JS,TS), Rust, LaTeX
- I started writing /lots/ of LaTeX, so much that I became (for a
  period) the #3 contributor to the 'main' LaTeX extension (~500k users)
  and then went off and developed an extension to that extension :P
  (https://marketplace.visualstudio.com/items?itemName=tecosaur.latex-utilities)
- Why does this matter? At this point I'm *heavily* invested into VS
  Code. I'll need to be quite confident of a better experience in order
  to switch.
* VS Code pain points
- I like windows. VS Code's windows are independent electron instances.
  Not good (for UX, or RAM).
- Extension API felt a bit limiting a few times, I'd gaze at open
  issues/PRs in desperation that they'd actually be resolved

* Emacs, the warmup
- I'd heard a few things that sounded interesting about Emacs
  (read: faint inclination to see what the fuss was about)
- I like living in my editor (as long as it's comfortable), I didn't
  like it when I had to type into a barren textbox on the web (e.g.
  writing a GitHub issue).
- I became aware of the client/server archetecture, and EmacsAnywhere
- Installed EmacsAnywhere, and grabbed Spacemacs because it looked
  trendy (I'm serious, I /care/ about visuals, and the Spacemacs web page
  and screenshots were most attractive)
- Used a little bit, on and off, was pretty underwhelmed.
- Tried setting a few things in Spacemacs, found to be a pain --- recall
  I'm coming from a settings.json, and the layers seemed complicated
- Experience didn't end up meeting the Hype for me. Massive start up
  time also impeded further experimenting.
- Fell out of use

The good:
- Prompts on install asking how I wanted to have the main aspects set up
- Prompts on opening a new file type for the first time saying "We have
  a layer for this, would you like to install it?"

The bad:
- Felt clunky to use
- Felt quite opaque, like I didn't understand what I was doing and how
  it was working
- Sloooow to start

TLDR; gave Spacemacs a brief go, felt overwhelmed and underwhelmed at
the same time. Didn't end up going beyond a novelty.

* The drive to try Org-mode
- A few months later I started a Stats project using Jupyter Lab
- I missed my proper editor experience
- Version control was a pain
- I didn't like having to choose between opening a local server +
  browser, or trying to parse json >:(
- Did I mention I missed the 'full' editor experience? Just simple stuff
  like select word, replace matches. Trying to make any global (all
  cells) edits was a pain
- State was constantly a pain

* Org-mode, my ramp into Emacs pt.1 - vanilla
- I'd heard about Org-mode as a thing markdown + execution
- Maybe this could be better than Jupyter?
- However... I didn't like Spacemacs
- Removed Spacemacs
- Typed 'emacs' into a terminal
- Oh, this looks old.
- Successfully opened a file
  + Where are the line numbers?
  + Why aren't I given much information on the file
  + Where's the completion, the linting, etc.
  + I thought this was supposed to provide a richer experience than
    colourised nano?
- Tried to execute a command interactively (forget which command)
  + Typed M-x
  + Wait, this is just a text box
  + I don't know commands off by heart!
  + I want to be able to type key terms and see options!
- This isn't going to well
- I'm just slightly dissatisfied with notebooks, I don't want to "build
  my editor from scratch!" *before* I can get going with it!

Conclusion: vanilla emacs is:
 - faster starting
 - uglier, way uglier
 - Not sure how this is much better than Nano TBH (remember: new user, not
   intimately familiar with the benefits)
 - so lean that I don't get "basic" editor functionality (remember:
   coming from VS Code where on install I can open a common file and get
   completion, linting, and more! with common file types suggesting
   extensions which can be installed with a single click).
 - Difficult to use
 - Not something I can try in an afternoon
 - Likely not worth the time

* Org-mode, my ramp into Emacs pt.2 - Doom
- I wonder if there's some other option, closer to Spacemacs where I
  feel it actually helps me get stuff done, but isn't Spacemacs
- [Googles] finds out about Doom, screenshot looks way better
- Skim the readme, looks promising
- I run the one-line install
- Ok, so what do we have hear.
- Oh, look for the file ~/.doom.d/init.el ? I can do that
- Finds commits describing how the file works
  + Doom has 'modules' - bundles of functionality
  + Uncomment the modules you like the sound of, then run 'doom <something>'
  + I can do that!
- It works, I open up a file and it behaves as expected (and in a
  somewhat snappy manner - compared to Spacemacs)
- I try an Org file, it works!
- I gradually get drawn into Emacs, the rest is history
  (for an idea of how I currently am, see:
   https://tecosaur.github.io/emacs-config/config.html)

Ok, so what are the key aspects that allowed Doom to draw me in where
Spacemacs and Vanilla Emacs failed?
- Having an initialisation† file, well commented such that *without knowing
  anything about Emacs* I could have Emacs be set up such that I could
  actually try it with familiar tasks and not be underwhelmed, or have
  to deal with sudden troubleshooting

  †The important bit about this file is that it let me declare which
  bundles of functionality I want easily, and without having to parse
  much unfamiliar lisp (both Spacemacs and Vanilla fail in this regard,
  but in different ways).
- Having good 'discoverability enhancements' used by default
  - counsel for M-x
  - which-key
- Looking 'modern' helped me think of Emacs as something which /could/
  be modern, which helped give me confidence in giving Doom a shot (and
  put me off vanilla Emacs)
- Felt a lot smoother/faster than Spacemacs
- Used Discord for it's community, a recent chat-app which I recognised
  (I'm still warming up to mailing lists).
- I don't think I can stress the init.el/module system enough. I wanted
  to use Org-mode with R. I just needed to uncomment ESS, run doom
  refresh and it worked; and *this was all made obvious to me shortly
  after installing*. When I had combinations which used packages which
  interacted and required work-arounds or modifications to integrate
  with other modules - Doom would just take care of this in the
  background. The modules let me 'hit the ground running' in a way I
  didn't in vanilla.


This has been quite a ramble, but should give an idea of how I
approached Emacs, and why the difference in first impressions Doom
provided ended up being so important to me.

All the best,

Timothy.

Re: Changes for emacs 28

[tomas]

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

On Wed, Sep 09, 2020 at 02:15:24AM +0800, TEC wrote:

[...]

> All right then, I'll try to give a dot point version of my journey into
> Emacs, and background/context. I hope this ends up being useful :)

Thanks for this. Very valuable.

Cheers
 - t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Changes for emacs 28

[Ergus]

Continuing somehow with the profiles approach. (Which seems to be the
only productive conclusion of the thread that everyone more or less
agree)

As a first step:

May we consider to insert use-package, leaf or something similar in
vanilla?

Either of them are developed by people with copyright and reduces the
configuration complexity while more or less standardizes the packages
configuration; they doesn't affect at all the old user's configs.

Maybe we don't need them fully but at least a part of their
functionalities could be inserted in packages.el?



On Tue, Sep 08, 2020 at 09:28:55PM +0200, tomas@tuxteam.de wrote:
>On Wed, Sep 09, 2020 at 02:15:24AM +0800, TEC wrote:
>
>[...]
>
>> All right then, I'll try to give a dot point version of my journey into
>> Emacs, and background/context. I hope this ends up being useful :)
>
>Thanks for this. Very valuable.
>
>Cheers
> - t

Re: Changes for emacs 28

[Stefan Kangas]

Ergus <spacibba@aol.com> writes:

> May we consider to insert use-package, leaf or something similar in
> vanilla?

Work on use-package is ongoing, see its GitHub issues page where they
are sorting out the assignment.  I believe I linked the relevant issue
on this list a couple of days ago.

It is my understanding that the idea is to include it in Emacs itself
(rather than only as an ELPA package).

> Maybe we don't need them fully but at least a part of their
> functionalities could be inserted in packages.el?

What do you have in mind?

Re: Changes for emacs 28

[Ergus]

On Tue, Sep 08, 2020 at 09:01:51PM +0000, Stefan Kangas wrote:

>> Maybe we don't need them fully but at least a part of their
>> functionalities could be inserted in packages.el?
>
>What do you have in mind?
>
Actually nothing specific. I just prevented in case it was not ongoing.

OTOH: While I use use-packages I have seen leaf and it seems to have
some interesting things and it is "syntax coherent" in some aspects
while developed by a single user with all the paperwork done.

We must take the best of both. Could we request Naoya Yamashita and John
Wiegley to create together a sort of super use-package-leaf for vanilla?

Re: Changes for emacs 28

[Stefan Kangas]

Ergus <spacibba@aol.com> writes:

> OTOH: While I use use-packages I have seen leaf and it seems to have
> some interesting things and it is "syntax coherent" in some aspects
> while developed by a single user with all the paperwork done.

Which useful features does leaf provide over use-package?

Re: Changes for emacs 28

[Ergus]

On September 9, 2020 12:14:15 AM GMT+02:00, Stefan Kangas <stefankangas@gmail.com> wrote:
>Ergus <spacibba@aol.com> writes:
>
>> OTOH: While I use use-packages I have seen leaf and it seems to have
>> some interesting things and it is "syntax coherent" in some aspects
>> while developed by a single user with all the paperwork done.
>
>Which useful features does leaf provide over use-package?

Just some details. Some coherent syntax, easier extensibility and extra keywords.

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

Re: Changes for emacs 28

[Daniel Martín]

Ergus <spacibba@aol.com> writes:

>
> Maybe we don't need them fully but at least a part of their
> functionalities could be inserted in packages.el?

Despite the name, use-package is not very related to what package.el
does, so it may be accepted into Emacs, but as its own package.

As a first step, someone should write a proposal that describes in
detail the concept of "profile", what it'll entail, and how it'll help
existing Emacs users and developers. With the help of the experienced
Emacs developers in this ML, I'm sure we could come up with a technical
design for the feature, that works on top of the existing Emacs
architecture.

--
Daniel Martín

Re: Changes for emacs 28

[Stefan Monnier]

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

> * Org-mode, my ramp into Emacs pt.1 - vanilla
> - I'd heard about Org-mode as a thing markdown + execution
> - Maybe this could be better than Jupyter?
> - However... I didn't like Spacemacs
> - Removed Spacemacs
> - Typed 'emacs' into a terminal

So far so good.

> - Oh, this looks old.

Fair enough.  I don't think we (Emacs community) are in a position to
make it look "modern" and sexy.  I know I'm not because my notion of
"modern and sexy" is quite outmoded ;-)

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

> - Successfully opened a file
>   + Where are the line numbers?

Interesting.  It would never occur to me to expect line numbers in
a text editor.  When and why did line numbers become fashionable?
[ My guess is something like "ever since shortscreens became the only
  option, creating a void in the horizontal space that needed
  filling" ;-) ]

I don't oppose enabling line numbers by default, but I do find line
numbers to be an awful waste of valuable screen real estate.

>   + Why aren't I given much information on the file

Could you be more specific in terms of the particular information that
you felt Emacs failed to give (and maybe how you expected it to be given)?

>   + Where's the completion, the linting, etc.

Do I understand you right that you expected company+eglot+flymake to be
enabled (and configured) by default?

I personally find this to be the most glaring concrete problem in
Emacs nowadays.

> - Tried to execute a command interactively (forget which command)
>   + Typed M-x
>   + Wait, this is just a text box
>   + I don't know commands off by heart!
>   + I want to be able to type key terms and see options!

How much of this would be satisfied by icomplete-mode together with the
`substring` completion-style (which would be a smaller change to
the UI than something like helm-M-x or counsel-M-x).

> - Having an initialisation† file, well commented such that *without knowing
>   anything about Emacs* I could have Emacs be set up such that I could
>   actually try it with familiar tasks and not be underwhelmed, or have
>   to deal with sudden troubleshooting

Maybe we could have a "default init file" (consisting of nothing but
commented out code snippets, accompanied by actual comments explaining
them)?

>   †The important bit about this file is that it let me declare which
>   bundles of functionality I want easily, and without having to parse
>   much unfamiliar lisp (both Spacemacs and Vanilla fail in this regard,
>   but in different ways).

Hmm... a "default init file" would still use "unfamiliar Lisp", I'm afraid.

> - Having good 'discoverability enhancements' used by default
>   - counsel for M-x

IIUC this is similar to enabling icomplete-vertical and
icomplete-show-matches-on-no-input, and maybe using a regexp
completion style?

> - Used Discord for it's community, a recent chat-app which I recognised
>   (I'm still warming up to mailing lists).

Definitely a non-starter since it's proprietary.
There are obviously acceptable alternatives.

I think an important aspect is to find a communication medium that can
be used from Emacs.  IRC and Email do satisfy this criteria.
Whenever I have to write text outside Emacs I feel hampered.


        Stefan

Re: Changes for emacs 28

[T.V Raman]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=gb18030, Size: 3787 bytes --]

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


and with taller screens, may be old typewriter  motivated displays with
column numbers running along the top:-)> Thanks, TEC, I found it quite useful.  Further comments and questions below.
>
>> * Org-mode, my ramp into Emacs pt.1 - vanilla
>> - I'd heard about Org-mode as a thing markdown + execution
>> - Maybe this could be better than Jupyter?
>> - However... I didn't like Spacemacs
>> - Removed Spacemacs
>> - Typed 'emacs' into a terminal
>
> So far so good.
>
>> - Oh, this looks old.
>
> Fair enough.  I don't think we (Emacs community) are in a position to
> make it look "modern" and sexy.  I know I'm not because my notion of
> "modern and sexy" is quite outmoded ;-)
>
> But "looks old" is usually not a deal breaker, just a negative
> first impression.
>
>> - Successfully opened a file
>>   + Where are the line numbers?
>
> Interesting.  It would never occur to me to expect line numbers in
> a text editor.  When and why did line numbers become fashionable?
> [ My guess is something like "ever since shortscreens became the only
>   option, creating a void in the horizontal space that needed
>   filling" ;-) ]
>
> I don't oppose enabling line numbers by default, but I do find line
> numbers to be an awful waste of valuable screen real estate.
>
>>   + Why aren't I given much information on the file
>
> Could you be more specific in terms of the particular information that
> you felt Emacs failed to give (and maybe how you expected it to be given)?
>
>>   + Where's the completion, the linting, etc.
>
> Do I understand you right that you expected company+eglot+flymake to be
> enabled (and configured) by default?
>
> I personally find this to be the most glaring concrete problem in
> Emacs nowadays.
>
>> - Tried to execute a command interactively (forget which command)
>>   + Typed M-x
>>   + Wait, this is just a text box
>>   + I don't know commands off by heart!
>>   + I want to be able to type key terms and see options!
>
> How much of this would be satisfied by icomplete-mode together with the
> `substring` completion-style (which would be a smaller change to
> the UI than something like helm-M-x or counsel-M-x).
>
>> - Having an initialisation6¥8 file, well commented such that *without knowing
>>   anything about Emacs* I could have Emacs be set up such that I could
>>   actually try it with familiar tasks and not be underwhelmed, or have
>>   to deal with sudden troubleshooting
>
> Maybe we could have a "default init file" (consisting of nothing but
> commented out code snippets, accompanied by actual comments explaining
> them)?
>
>>   6¥8The important bit about this file is that it let me declare which
>>   bundles of functionality I want easily, and without having to parse
>>   much unfamiliar lisp (both Spacemacs and Vanilla fail in this regard,
>>   but in different ways).
>
> Hmm... a "default init file" would still use "unfamiliar Lisp", I'm afraid.
>
>> - Having good 'discoverability enhancements' used by default
>>   - counsel for M-x
>
> IIUC this is similar to enabling icomplete-vertical and
> icomplete-show-matches-on-no-input, and maybe using a regexp
> completion style?
>
>> - Used Discord for it's community, a recent chat-app which I recognised
>>   (I'm still warming up to mailing lists).
>
> Definitely a non-starter since it's proprietary.
> There are obviously acceptable alternatives.
>
> I think an important aspect is to find a communication medium that can
> be used from Emacs.  IRC and Email do satisfy this criteria.
> Whenever I have to write text outside Emacs I feel hampered.
>
>
>         Stefan
>
>

-- 
7©4 Id: kg:/m/0285kf1  •0Ü8

Re: Changes for emacs 28

[TEC]

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

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

Happy to (try) to help. I'll see if I can elaborate on your
points/queries :)

>> - Oh, this looks old.
>
> Fair enough.  I don't think we (Emacs community) are in a position to
> make it look "modern" and sexy.  I know I'm not because my notion of
> "modern and sexy" is quite outmoded ;-)
>
> But "looks old" is usually not a deal breaker, just a negative
> first impression.

This is a tricky thing. You see, I don't think it's inherently bad.
However, for me at least, most of the editors I've used have had a good
degree of 'visual polish' and 'modern snazziness' that Vanilla Emacs
currently lacks. The editors I've used which haven't are
 - IDLE
 - Nano
 - BlueJ (for all of 30 seconts)
All of which I ended up finding quite lacking.

So the 'issue' here isn't a direct "this doesn't look good so I won't
use this" but a case of association. When I see the vanilla Emacs splash
screen I'm reminded of the *worst* editors I have experienced, which is
(as we both know) completely inaccurate, but first impressions are
coloured by a myriad of factors.

Vim of course also lacks a splash screen, but it's also known as a
terminal-exclusive editor. I know I tend to set different expectations
TUIs and GUIs, so I'd imagine I'd find this less of a subconscious
red-flag.

>> - Successfully opened a file
>>   + Where are the line numbers?
>
> Interesting.  It would never occur to me to expect line numbers in
> a text editor.  When and why did line numbers become fashionable?
> [ My guess is something like "ever since shortscreens became the only
>   option, creating a void in the horizontal space that needed
>   filling" ;-) ]
>
> I don't oppose enabling line numbers by default, but I do find line
> numbers to be an awful waste of valuable screen real estate.

This really is quite minor, and not something to get hung up about in my
opinion. This was more a surprise than anything else, having just been
made used to line numbers by my previous editors.

>>   + Why aren't I given much information on the file
>
> Could you be more specific in terms of the particular information that
> you felt Emacs failed to give (and maybe how you expected it to be given)?

It's almost got all the main attributes, just an issue of clarity and
expected functionality not coming with vanilla Emacs.

- Unsaved changes, I see this is now present but the you have to know
  what you're looking for somewhat
- linter checks/status (of course, I now know this is because there is
  no linter by default)

>>   + Where's the completion, the linting, etc.
>
> Do I understand you right that you expected company+eglot+flymake to be
> enabled (and configured) by default?
>
> I personally find this to be the most glaring concrete problem in
> Emacs nowadays.

Yep. This is the main item, no doubt in my mind. Not having /any/
completion or linting was a bit of a shock.

>> - Tried to execute a command interactively (forget which command)
>>   + Typed M-x
>>   + Wait, this is just a text box
>>   + I don't know commands off by heart!
>>   + I want to be able to type key terms and see options!
>
> How much of this would be satisfied by icomplete-mode together with the
> `substring` completion-style (which would be a smaller change to
> the UI than something like helm-M-x or counsel-M-x).

I'm frankly not sure. Just trying icomplete now for the first time the
horizontal display of options seems a bit odd to my sensibilities.

>> - Having an initialisation† file, well commented such that *without knowing
>>   anything about Emacs* I could have Emacs be set up such that I could
>>   actually try it with familiar tasks and not be underwhelmed, or have
>>   to deal with sudden troubleshooting
>
> Maybe we could have a "default init file" (consisting of nothing but
> commented out code snippets, accompanied by actual comments explaining
> them)?

I feel like this could be a good thing, with the most common/immediate
settings described and commented out. For example, doom has this:

-----

;; Some functionality uses this to identify you, e.g. GPG configuration, email
;; clients, file templates and snippets.
(setq user-full-name "John Doe"
      user-mail-address "john@doe.com")

...

;; This determines the style of line numbers in effect. If set to `nil', line
;; numbers are disabled. For relative line numbers, set this to `relative'.
(setq display-line-numbers-type t)

-----

>>   †The important bit about this file is that it let me declare which
>>   bundles of functionality I want easily, and without having to parse
>>   much unfamiliar lisp (both Spacemacs and Vanilla fail in this regard,
>>   but in different ways).
>
> Hmm... a "default init file" would still use "unfamiliar Lisp", I'm afraid.

This was mostly a comparison to spacemacs. Doom's init.el is mostly
lines like this:

-----
       :lang
       ;;agda              ; types of types of types of types...
       ;;cc                ; C/C++/Obj-C madness
       ;;clojure           ; java with a lisp
       ;;common-lisp       ; if you've seen one lisp, you've seen them all
-----

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

>> - Having good 'discoverability enhancements' used by default
>>   - counsel for M-x
>
> IIUC this is similar to enabling icomplete-vertical and
> icomplete-show-matches-on-no-input, and maybe using a regexp
> completion style?

This sounds like a change I would have appreciated.

>> - Used Discord for it's community, a recent chat-app which I recognised
>>   (I'm still warming up to mailing lists).
>
> Definitely a non-starter since it's proprietary.
> There are obviously acceptable alternatives.

Oh, I don't expect Emacs' community at large (particularly individuals
like the cheif GNUsance) to switch to discord or anything like that, but
a non-IRC IM platform could make asking quick newbie questions seem more
appreciable.

Unfortunately, I feel that a lot of youngsters (myself included) tend to
/expect/ projects to:
 - be on github
 - have public forums
 - use popluar IM services

I'm not saying Email+IRC isn't fit for purpose, it's simply not
something I was used to using like this (until months after I got into
Emacs).

I think we can somewhat see this effect in the benefits that being on
GitHub seems to have had for NeoVim, in terms of visibility and
engagement.

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

> I think an important aspect is to find a communication medium that can
> be used from Emacs.  IRC and Email do satisfy this criteria.

Indeed. Though I think that when trying to make Emacs inviting, having
services that a curious user feels comfortable just jumping onto
(Discord, Gitter, Slack, Discorse,...) may also have value.

Feel free to follow up with more questions, I'll do my best to answer
them :)

Timothy.

Re: Changes for emacs 28

[Stefan Monnier]

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

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

>>> - Successfully opened a file
>>>   + Where are the line numbers?
>>
>> Interesting.  It would never occur to me to expect line numbers in
>> a text editor.  When and why did line numbers become fashionable?
>> [ My guess is something like "ever since shortscreens became the only
>>   option, creating a void in the horizontal space that needed
>>   filling" ;-) ]
>>
>> I don't oppose enabling line numbers by default, but I do find line
>> numbers to be an awful waste of valuable screen real estate.
>
> This really is quite minor, and not something to get hung up about in my
> opinion.

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

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

>> Could you be more specific in terms of the particular information that
>> you felt Emacs failed to give (and maybe how you expected it to be given)?
> It's almost got all the main attributes, just an issue of clarity and
> expected functionality not coming with vanilla Emacs.
> - Unsaved changes, I see this is now present but the you have to know
>   what you're looking for somewhat

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

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

Ah, yes, that ;-)

>>>   + Where's the completion, the linting, etc.
>> Do I understand you right that you expected company+eglot+flymake to be
>> enabled (and configured) by default?
>> I personally find this to be the most glaring concrete problem in
>> Emacs nowadays.
> Yep. This is the main item, no doubt in my mind. Not having /any/
> completion or linting was a bit of a shock.

I'm glad we agree.

>> Maybe we could have a "default init file" (consisting of nothing but
>> commented out code snippets, accompanied by actual comments explaining
>> them)?
> I feel like this could be a good thing, with the most common/immediate
> settings described and commented out. For example, doom has this:

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

> -----
>        :lang
>        ;;agda              ; types of types of types of types...
>        ;;cc                ; C/C++/Obj-C madness
>        ;;clojure           ; java with a lisp
>        ;;common-lisp       ; if you've seen one lisp, you've seen them all
> -----

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

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

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

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

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

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

>  - have public forums

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

>  - use popluar IM services

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

> I'm not saying Email+IRC isn't fit for purpose, it's simply not
> something I was used to using like this (until months after I got into
> Emacs).

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

Any suggestion what this could be?

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

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

>> I think an important aspect is to find a communication medium that can
>> be used from Emacs.  IRC and Email do satisfy this criteria.
> Indeed. Though I think that when trying to make Emacs inviting, having
> services that a curious user feels comfortable just jumping onto
> (Discord, Gitter, Slack, Discorse,...) may also have value.

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


        Stefan

Re: Changes for emacs 28

[Göktuğ Kayaalp]

On 2020-09-09 21:35 +03, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> I'm not getting "hung up on" but I'm curious to know if it's really
> something that's expected nowadays (just like a tool-bar was expected
> at some point and maybe a tab-bar is expected nowadays, tho I find
> both of them completely useless in Emacs for my usage pattern).

Most of the popular graphical text editor applications have it on by
default.  I’ve observed Sublime Text, VS Code, Notepad++ (not sure tho),
and a few others in distant past whose names escape me now.

Notably, tho, IDEs in general don’t seem to have line numbers on by
default.

Enabling line numbers by default is, IDK.  In most special-mode type of
buffers they don’t make any sense.  In text-mode, not really needed
either.  Maybe in prog-mode, but then usually you have flymake,
flycheck, lsp or similar and they just highlight the relevant line, and
compilation errors are usually clickable (tho possibly not everybody are
using M-x compile).  Maybe when navigating via prefix args (e.g. C-5
C-n)?

Maybe, if we ever have something like a initial config wizard, we could:

  Do you want to enable line number display on the left side of the
  window in any of the following contexts?

      ( ) Programming modes only
      ( ) Text editing modes only
      ( ) Both programming and text editing modes
      ( ) Everywhere

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

Maybe a toggle inserted into the very left hand side of the mode line?
E.g., try:

(setq
 mode-line-format
 (cons
  '(:eval
    (propertize
     "# "
     'help-echo  "mouse-1: Toggle line number display"
     'mouse-face 'mode-line-highlight

     'local-map
     (make-mode-line-mouse-map
      'mouse-1 #'display-line-numbers-mode)))
  mode-line-format))

>> I'm not saying Email+IRC isn't fit for purpose, it's simply not
>> something I was used to using like this (until months after I got into
>> Emacs).
> Yup.  So the only possible meeting point is one that is ethically
> acceptable (Free Software, open protocol, non-centralized control), and
> can be accessed from within Emacs as well as via more popular UIs.
>
> Any suggestion what this could be?

A Mastodon (or equivalent) instance for Emacs?  A lot of Emacs users
there already.

There’s an Emacs client, mastodon.el, which is nice but has some
polishing to be done.  Haven’t used it much tho.


--
İ. Göktuğ Kayaalp / @cadadr / <https://www.gkayaalp.com/>
pgp:   024C 30DD 597D 142B 49AC 40EB 465C D949 B101 2427

RE: Changes for emacs 28

[Drew Adams]

> Enabling line numbers by default ...
> Maybe a toggle inserted into the very left hand side of the mode line?

Isn't what we have now sufficient for discovery
and setting line-number display on, if that's
what someone wants?  (Not a snarky or rhetorical
question - I'm curious.)

How hard is it to find this submenu?

`Options' >
    `Show/Hide' >
      `Line Numbers for All Lines'

Perhaps that submenu should be moved up, before
submenu `Scroll Bars', i.e., as the first submenu
of `Show/Hide'.  And perhaps submenu `Show/Hide'
should be moved higher in the `Options' menu.

(I've also argued in the past to rename `Options'
to `Preferences', as that's more common, and
as it covers faces also.  That wasn't done.)

Re: Changes for emacs 28

[Yuri Khan]

On Fri, 11 Sep 2020 at 00:43, Drew Adams <drew.adams@oracle.com> wrote:

> How hard is it to find this submenu?
>
> `Options' >
>     `Show/Hide' >
>       `Line Numbers for All Lines'

By CUA, Show/Hide should be a top-level menu named View. Someone who
is (subconsciously) familiar with that convention will not think to
look in Options.

Re: Changes for emacs 28

[Eli Zaretskii]

> From: Yuri Khan <yuri.v.khan@gmail.com>
> Date: Fri, 11 Sep 2020 00:56:41 +0700
> Cc: Göktuğ Kayaalp <self@gkayaalp.com>,
>  Gregory Heytings <ghe@sdf.org>, Yuan Fu <casouri@gmail.com>,
>  TEC <tecosaur@gmail.com>, Emacs developers <emacs-devel@gnu.org>
> 
> > `Options' >
> >     `Show/Hide' >
> >       `Line Numbers for All Lines'
> 
> By CUA, Show/Hide should be a top-level menu named View.

Emacs doesn't have a View menu.  And frankly, in an editor, too many
things are about "viewing" for View to be of any use.

Also, Options in many apps is not easily discovered, its place is not
fixed: sometimes in Tools, sometimes somewhere else.  Emacs, being a
highly-customizable application, cannot avoid having Options at top
level.

Re: Changes for emacs 28

[Ricardo Wurmus]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Yuri Khan <yuri.v.khan@gmail.com>
>> Date: Fri, 11 Sep 2020 00:56:41 +0700
>> Cc: Göktuğ Kayaalp <self@gkayaalp.com>,
>>  Gregory Heytings <ghe@sdf.org>, Yuan Fu <casouri@gmail.com>,
>>  TEC <tecosaur@gmail.com>, Emacs developers <emacs-devel@gnu.org>
>> 
>> > `Options' >
>> >     `Show/Hide' >
>> >       `Line Numbers for All Lines'
>> 
>> By CUA, Show/Hide should be a top-level menu named View.
>
> Emacs doesn't have a View menu.  And frankly, in an editor, too many
> things are about "viewing" for View to be of any use.
>
> Also, Options in many apps is not easily discovered, its place is not
> fixed: sometimes in Tools, sometimes somewhere else.  Emacs, being a
> highly-customizable application, cannot avoid having Options at top
> level.

I wonder if it makes sense to link directly to the customize “feature”
(for the lack of a better word), i.e. to remove options from the menu
and replace them with an item that essentially does “M-x customize”.
Customize provides an intuitive interface for many options and is not
constrained by the limitations of a single menu.

As a bonus it would lead users to learn more about Emacs and how to
customize it.

If the customize buffers are too intimidating or too “full”, perhaps
this means that we should find more groups and better organize them.

-- 
Ricardo

Re: Changes for emacs 28

[Eli Zaretskii]

> From: Ricardo Wurmus <rekado@elephly.net>
> Cc: Yuri Khan <yuri.v.khan@gmail.com>, casouri@gmail.com, ghe@sdf.org,
>  self@gkayaalp.com, drew.adams@oracle.com, tecosaur@gmail.com,
>  emacs-devel@gnu.org
> Date: Thu, 10 Sep 2020 21:48:01 +0200
> 
> I wonder if it makes sense to link directly to the customize “feature”
> (for the lack of a better word), i.e. to remove options from the menu
> and replace them with an item that essentially does “M-x customize”.
> Customize provides an intuitive interface for many options and is not
> constrained by the limitations of a single menu.

Customize is in the Options menu.

For simple on/off options, especially the popular ones, it makes sense
to offer them as simple menu toggles, so that we don't force the user
to use the more complex UI of Customize for such simple tasks.

Re: Changes for emacs 28

[Göktuğ Kayaalp]

On 2020-09-10 21:21 +03, Eli Zaretskii <eliz@gnu.org> wrote:
> Emacs doesn't have a View menu.  And frankly, in an editor, too many
> things are about "viewing" for View to be of any use.
>
> Also, Options in many apps is not easily discovered, its place is not
> fixed: sometimes in Tools, sometimes somewhere else.  Emacs, being a
> highly-customizable application, cannot avoid having Options at top
> level.

It appears that in Emacs we have the extra trouble of menu-bar-mode
being one of the first things people disable, and some major ‘distros’
like Spacemacs seem to disable them by default, so many people never
even see it.  Also, FWIW, I just noticed the Options menu for the first
time in my life, after reading Drew’s message, even though the menu bar
has been sitting there before my eyes for years...

There was an idea in another thread that we could ask major distros to
not disable menu bar, and I said I could create the issues, but I though
I’d wait for some of the maintainers (dis)agree first. What do you
think, would such a thing be useful?

--
İ. Göktuğ Kayaalp / @cadadr / <https://www.gkayaalp.com/>
pgp:   024C 30DD 597D 142B 49AC 40EB 465C D949 B101 2427

Re: Changes for emacs 28

[Gregory Heytings via Emacs development discussions.]

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


Göktuğ Kayaalp:
>
> There was an idea in another thread that we could ask major distros to 
> not disable menu bar, and I said I could create the issues, but I though 
> I’d wait for some of the maintainers (dis)agree first. What do you 
> think, would such a thing be useful?
>

I'm not a maintainer, but FWIW my opinion is that what will most likely 
happen is that they will never agree to do this.  Menus are not "modern".

Re: Changes for emacs 28

[Ricardo Wurmus]

Gregory Heytings via Emacs development discussions. <emacs-devel@gnu.org> writes:

> Göktuğ Kayaalp:
>>
>> There was an idea in another thread that we could ask major distros
>> to not disable menu bar, and I said I could create the issues, but I
>> though I’d wait for some of the maintainers (dis)agree first. What
>> do you think, would such a thing be useful?
>>
>
> I'm not a maintainer, but FWIW my opinion is that what will most
> likely happen is that they will never agree to do this.  Menus are not
> "modern".

FWIW, we don’t disable the menu bar in Guix.

It seems super weird to me to disable a feature like that for all users
of the package.  We disable anti-features (like an application phoning
home), but why would any distribution maintainer decide for the users on
something like that?

I personally don’t use the menus, but it would never occur to me to
disable them for new users or to suggest they disable them.

If you use a distribution that disables the menu bar, I would suggest
talking to them.  Perhaps this was done by an over-zealous person and
has long been forgotten by whoever maintains the package today.

-- 
Ricardo

Re: Changes for emacs 28

[Gregory Heytings via Emacs development discussions.]

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


>> There was an idea in another thread that we could ask major distros to 
>> not disable menu bar, and I said I could create the issues, but I 
>> though I’d wait for some of the maintainers (dis)agree first. What do 
>> you think, would such a thing be useful?
>
> FWIW, we don’t disable the menu bar in Guix.
>

The words "major distros" here are not clear without the context.  They 
mean "Spacemacs", "Doom Emacs" and the like.  Not Guix, Debian and the 
like.

RE: Changes for emacs 28

[Drew Adams]

> It seems super weird to me to disable a feature like that for all users
> of the package.  We disable anti-features (like an application phoning
> home), but why would any distribution maintainer decide for the users on
> something like that?

<scratchy-voice>E.T. menu-phone HOME!</ scratchy -voice>

Re: Changes for emacs 28

[Stefan Kangas]

Gregory Heytings via "Emacs development discussions."
<emacs-devel@gnu.org> writes:

> I'm not a maintainer, but FWIW my opinion is that what will most likely
> happen is that they will never agree to do this.  Menus are not "modern".

Maybe not.  But we don't know until we have given them the opportunity
to think about this problem.  Even if just a small number of popular
distributions choose to listen it would be an improvement.

The same explanatory text could be used to file several bug reports.
That makes it worth spending the extra couple of minutes to make sure
that it's a convincing text.

Re: Changes for emacs 28

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

  > I'm not a maintainer, but FWIW my opinion is that what will most likely 
  > happen is that they will never agree to do this.  Menus are not "modern".

What in the world?  This strikes me as incomprehensible.

Who thinks "Menus are not modern"?  Why?
What do they use instead of menus?

(Perhaps they use a different kind of menu
but do not think of it as a manu.)

-- 
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: Changes for emacs 28

[Philip K.]

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. ]]]
>
>   > I'm not a maintainer, but FWIW my opinion is that what will most likely 
>   > happen is that they will never agree to do this.  Menus are not "modern".
>
> What in the world?  This strikes me as incomprehensible.
>
> Who thinks "Menus are not modern"?  Why?
> What do they use instead of menus?
>
> (Perhaps they use a different kind of menu
> but do not think of it as a manu.)

I think that this is the case, most programmes seem to use the
"Hamburger Menu"[0] instead of a transitional top-menu. I'm not sure
what the reason for this change was, but I have a hunch one of the
motivating reasons was the attempt to merge applications and the window
frames (as GNOME does in the free software world, but Chrome, MS Office,
etc. do in the non-free world). When no space is left between the
application and it's frame, the menu must be moved somewhere
else. Another reason is probably the influence of mobile applications,
that use these kinds of menus due to lack of space.

[0] https://en.wikipedia.org/wiki/Hamburger_button

-- 
	Philip K.

Re: Changes for emacs 28

[Eli Zaretskii]

> From: "Philip K." <philipk@posteo.net>
> Date: Fri, 11 Sep 2020 09:04:59 +0200
> Cc: Gregory Heytings <ghe@sdf.org>, emacs-devel@gnu.org
> 
> I think that this is the case, most programmes seem to use the
> "Hamburger Menu"[0] instead of a transitional top-menu. I'm not sure
> what the reason for this change was, but I have a hunch one of the
> motivating reasons was the attempt to merge applications and the window
> frames

I think the reason is likely to be compatibility with mobile platforms,
where screen space is at premium.

Re: Changes for emacs 28

[tomas]

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

On Fri, Sep 11, 2020 at 10:12:01AM +0300, Eli Zaretskii wrote:
> > From: "Philip K." <philipk@posteo.net>
> > Date: Fri, 11 Sep 2020 09:04:59 +0200
> > Cc: Gregory Heytings <ghe@sdf.org>, emacs-devel@gnu.org
> > 
> > I think that this is the case, most programmes seem to use the
> > "Hamburger Menu"[0] instead of a transitional top-menu. I'm not sure
> > what the reason for this change was, but I have a hunch one of the
> > motivating reasons was the attempt to merge applications and the window
> > frames
> 
> I think the reason is likely to be compatibility with mobile platforms,
> where screen space is at premium.

This is a friendly interpretation. You're such a friendly person [1].

Me? I'd say the Hamburger menu is the latest fad, to be taken over
next year by the Sushi menu, or the Falafel-Halloumi-Magali menu,
depending on the alignment of the stars.

Never forget that the current trendsetters care for user's well-being
as much as the cattle-herders care for their cattle's well-being.

They are the wares. Their customers are elsewhere.

Cheers

[1] Someone might be tempted to read irony in this. That'd be wrong.

 - t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Changes for emacs 28

[Arthur Miller]

<tomas@tuxteam.de> writes:

> On Fri, Sep 11, 2020 at 10:12:01AM +0300, Eli Zaretskii wrote:
>> > From: "Philip K." <philipk@posteo.net>
>> > Date: Fri, 11 Sep 2020 09:04:59 +0200
>> > Cc: Gregory Heytings <ghe@sdf.org>, emacs-devel@gnu.org
>> > 
>> > I think that this is the case, most programmes seem to use the
>> > "Hamburger Menu"[0] instead of a transitional top-menu. I'm not sure
>> > what the reason for this change was, but I have a hunch one of the
>> > motivating reasons was the attempt to merge applications and the window
>> > frames
>> 
>> I think the reason is likely to be compatibility with mobile platforms,
>> where screen space is at premium.
>
> This is a friendly interpretation. You're such a friendly person [1].
>
> Me? I'd say the Hamburger menu is the latest fad, to be taken over
> next year by the Sushi menu, or the Falafel-Halloumi-Magali menu,
> depending on the alignment of the stars.
:-) Haha, what is Magali? Never tried that. Wikipedia says it is a river
in Guinea and Google shows me pictures of different dishes.

"Hamburger icon" has become a standard icon for a menu; I don't think
there was an established "menu icon" before the "responsive design"
kicked in. People used '+' sign och '...' or something else. Responsive
design is all the rage nowadays; I think it started already with Java
introducing layout managers, but it didn't become a thing until mobile
platforms made it popular due to necessity.

Re: Changes for emacs 28

[tomas]

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

On Fri, Sep 11, 2020 at 12:27:13PM +0200, Arthur Miller wrote:

[...]

> :-) Haha, what is Magali? Never tried that. Wikipedia says it is a river
> in Guinea and Google shows me pictures of different dishes.

In the Sudanese take-outs around here, they serve you diced, fried 
vegetables [1]. Yummy.

Cheers
[1] https://saharaimbiss.de/en/
 - t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Changes for emacs 28

[Arthur Miller]

tomas@tuxteam.de writes:

> On Fri, Sep 11, 2020 at 12:27:13PM +0200, Arthur Miller wrote:
>
> [...]
>
>> :-) Haha, what is Magali? Never tried that. Wikipedia says it is a river
>> in Guinea and Google shows me pictures of different dishes.
>
> In the Sudanese take-outs around here, they serve you diced, fried 
> vegetables [1]. Yummy.
No, we don't have those, but I believe you that fried veggies are
delicious. Anything fried ususally is :).

Re: Changes for emacs 28

[Göktuğ Kayaalp]

On 2020-09-11 10:44 +03, tomas@tuxteam.de wrote:
>> I think the reason is likely to be compatibility with mobile platforms,
>> where screen space is at premium.
>
> This is a friendly interpretation. You're such a friendly person [1].
>
> Me? I'd say the Hamburger menu is the latest fad, to be taken over
> next year by the Sushi menu, or the Falafel-Halloumi-Magali menu,
> depending on the alignment of the stars.

This is so true...

Tho it’s a fact that there are two main sources of UI ‘innovation’ in
desktop these days: copy web and copy mobile.

Another fact is we already have hamburger menus in Emacs: the onese
bound to C-mouse.

> Never forget that the current trendsetters care for user's well-being
> as much as the cattle-herders care for their cattle's well-being.
>
> They are the wares. Their customers are elsewhere.
>
> Cheers
>
> [1] Someone might be tempted to read irony in this. That'd be wrong.
>
>  - t


--
İ. Göktuğ Kayaalp / @cadadr / <https://www.gkayaalp.com/>
pgp:   024C 30DD 597D 142B 49AC 40EB 465C D949 B101 2427

Re: Changes for emacs 28

[Juri Linkov]

>> > I think that this is the case, most programmes seem to use the
>> > "Hamburger Menu"[0] instead of a transitional top-menu. I'm not sure
>> > what the reason for this change was, but I have a hunch one of the
>> > motivating reasons was the attempt to merge applications and the window
>> > frames

If the menu-bar isn't displayed then we could display the Hamburger icon
in the tool-bar, and clicking on it will pop-up the menu with items from
the menu-bar, so users won't need to display both menu-bar and tool-bar.

> Me? I'd say the Hamburger menu is the latest fad, to be taken over
> next year by the Sushi menu

Unlike the Hamburger menu that has three sticks,
the Sushi menu icon should have two chopsticks.

Re: Changes for emacs 28

[tomas]

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

On Sun, Sep 13, 2020 at 11:41:45AM +0300, Juri Linkov wrote:
> >> > I think that this is the case, most programmes seem to use the
> >> > "Hamburger Menu"[0] instead of a transitional top-menu. I'm not sure
> >> > what the reason for this change was, but I have a hunch one of the
> >> > motivating reasons was the attempt to merge applications and the window
> >> > frames
> 
> If the menu-bar isn't displayed then we could display the Hamburger icon
> in the tool-bar, and clicking on it will pop-up the menu with items from
> the menu-bar, so users won't need to display both menu-bar and tool-bar.
> 
> > Me? I'd say the Hamburger menu is the latest fad, to be taken over
> > next year by the Sushi menu
> 
> Unlike the Hamburger menu that has three sticks,
> the Sushi menu icon should have two chopsticks.

Perhaps with something mushy and fishy in-between, to differentiate
it from the spring-roll menu.

On a more serious note, what I wanted to point out is that there
are many forces shaping what is currently perceived as "usage
friendly". Some of them stem from ergonomy research (which, of
course, focuses on some population already exposed to software
"out there", so it's part of a feedback loop), some of it stems
from some manufacturer's attempt to differentiate itself, to
grow sales, some of it, even, from a strategy of appealing to
potential decision takers (who are /not/ those who have to use
the sofware later).

As we focus on user freedom here, not all those forces are our
friends. Some are, some are not.

The table TEC posted (Message-ID: <87o8maj1kh.fsf@gmail.com>)
is very interesting. Do you think the popularity of vscode
and vs (both at the  list's top) stems from the colours? Or
rather from the fact that there is an incredibly rich behemoth
behind both of them and that many developers are working,
directly or indirectly for it? Or from some mixture of both?

Microsoft has a long record of trying to suck in users into
their dependency from them. It's their business model.

The fact that Microsoft put 7 billions on the table to
acquire Github should be telling, in itself. A platform
which transforms Git's inherently decentralised model into
a centralised service (when I worked for some big company,
developers there saw Github as a synonym for git, and that
was before the acquisition).

Exchange Microsoft for any other company whose revenue comes
from dependent users, there are many.

The latter runs counter our core principles, I think.

I'm not arguing that Emacs shoud make it hard for people coming
from vscode, on the contrary. But the argument "it's more popular,
so it must be better" is too naive, I think.

Cheers
 - t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Changes for emacs 28

[Göktuğ Kayaalp]

On 2020-09-13 13:30 +03, tomas@tuxteam.de wrote:
> On a more serious note, what I wanted to point out is that there
> are many forces shaping what is currently perceived as "usage
> friendly". Some of them stem from ergonomy research (which, of
> course, focuses on some population already exposed to software
> "out there", so it's part of a feedback loop), some of it stems
> from some manufacturer's attempt to differentiate itself, to
> grow sales, some of it, even, from a strategy of appealing to
> potential decision takers (who are /not/ those who have to use
> the sofware later).

A lot of that research is pseudo scientific.  E.g. some famous
‘principles’ of UX design are based on academesified opition or
misappropriation of unrelated research.  E.g. see this one [1].  If you
read the ‘scientific’ background to the ‘laws’, what you’ll see is that
some of those are shaky, and some of those are lesser than that.

We should focus on what makes users *stay* with Emacs, and what makes
such a stay comfortable.  While I see no harm in making the first steps
easier---so long as it’s reasonably backwards compatible---, I firmly
believe that Emacs is a piece of software users should come to with a
knowledge of what to expect.  That’s not to mean it should be difficult,
as some are tending to interpret, but that Emacs constitutes a certain
paradigm of computing, and that that’s the main thing it has to offer.

As an example---tho it’s inevitably a single data point---I’ve never
been a user who is unable to figure out how to change the theme or
modify something in Emacs.  But I’ve only came to stick with it when I
uncovered what _actually_ it has to offer, over some keybindings and
random customisation.  It should also be considered how so many users
stick to Emacs despite it’s apparent that they are pretty much aware
that many other editors are way easier than Emacs, for some measure of
easy, and yet they stick to Emacs, despite the unfamiliarity, despite
the supposed difficulty.

We’re asking "why people aren’t coming to Emacs in hordes" too much,
when "why are people using Emacs in the first place" is the more
important one.

[1] https://lawsofux.com/

--
İ. Göktuğ Kayaalp / @cadadr / <https://www.gkayaalp.com/>
pgp:   024C 30DD 597D 142B 49AC 40EB 465C D949 B101 2427

Re: Changes for emacs 28

[tomas]

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

On Sun, Sep 13, 2020 at 01:59:02PM +0300, Göktuğ Kayaalp wrote:

[...]

> A lot of that research is pseudo scientific.  E.g. some famous
> ‘principles’ of UX design are based on academesified opition or
> misappropriation of unrelated research.  E.g. see this one [1].  If you
> read the ‘scientific’ background to the ‘laws’, what you’ll see is that
> some of those are shaky, and some of those are lesser than that.

Thanks for the link, and thanks for your appreciation. Yes, I
see it similarly; this research may be, at the bottom, genuine,
but it is strongly modulated by marketing departments (at several
points: for one, of course, the software vendor's, but also the
UX research company's).

> We should focus on what makes users *stay* with Emacs [...]

This is an important point, I think.

> We’re asking "why people aren’t coming to Emacs in hordes" too much,
> when "why are people using Emacs in the first place" is the more
> important one.

Yes. It's always a balancing act, where the equilibrium point shifts
over time.

Diverging too far from what is "customary" isn't user friendly
(most of us use other software besides Emacs, and it raises the
barrier to entry), following the "customary" too closely creates
a lot of churn along the random walk, at the cost of Emacs users.

Cheers
 - t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Changes for emacs 28

[Ergus]

On Sun, Sep 13, 2020 at 01:59:02PM +0300, Göktuğ Kayaalp wrote:
>On 2020-09-13 13:30 +03, tomas@tuxteam.de wrote:
>> On a more serious note, what I wanted to point out is that there
>> are many forces shaping what is currently perceived as "usage
>> friendly". Some of them stem from ergonomy research (which, of
>> course, focuses on some population already exposed to software
>> "out there", so it's part of a feedback loop), some of it stems
>> from some manufacturer's attempt to differentiate itself, to
>> grow sales, some of it, even, from a strategy of appealing to
>> potential decision takers (who are /not/ those who have to use
>> the sofware later).
>
>A lot of that research is pseudo scientific.  E.g. some famous
>‘principles’ of UX design are based on academesified opition or
>misappropriation of unrelated research.  E.g. see this one [1].  If you
>read the ‘scientific’ background to the ‘laws’, what you’ll see is that
>some of those are shaky, and some of those are lesser than that.
>
>We should focus on what makes users *stay* with Emacs, and what makes
>such a stay comfortable.  While I see no harm in making the first steps
>easier---so long as it’s reasonably backwards compatible---, I firmly
>believe that Emacs is a piece of software users should come to with a
>knowledge of what to expect.  That’s not to mean it should be difficult,
>as some are tending to interpret, but that Emacs constitutes a certain
>paradigm of computing, and that that’s the main thing it has to offer.
>
>As an example---tho it’s inevitably a single data point---I’ve never
>been a user who is unable to figure out how to change the theme or
>modify something in Emacs.  But I’ve only came to stick with it when I
>uncovered what _actually_ it has to offer, over some keybindings and
>random customisation.  It should also be considered how so many users
>stick to Emacs despite it’s apparent that they are pretty much aware
>that many other editors are way easier than Emacs, for some measure of
>easy, and yet they stick to Emacs, despite the unfamiliarity, despite
>the supposed difficulty.
>
>We’re asking "why people aren’t coming to Emacs in hordes" too much,
>when "why are people using Emacs in the first place" is the more
>important one.
>
I would make also these questions:

Why the vanilla emacs users almost hasn't increased or has decreases if
the number of programmers has exponentially grow in the world?  And
being emacs so powerful and old; how is it possible that it is
frequently not even listed in the GNU/Linux popular editors articles or
it is back in the list?  The emacs popularity is so low these days (even
in GNU/Linux users) that some distros still comes with emacs 24. And if
we split spacemacs and doom apart it is almost negligible... we are even
after vim.

How the emacs modifications (specially spacemacs) have found a set of
frequent developers, and a big younger community? (which is not bigger
because it is a bit overloaded of external packages IMO)

How is it possible that all those dummy and young editors have multiple
times more users and community than Emacs when they don't really bring
anything much better than us?

Are we sure we don't need that "fresh air", "new ideas" and "lot of
work" to be happening in vanilla directly? Even if we (former users)
disagree with some of them and have to add 3, 4 or 10 extra lines to our
config to disable them?

I think that when emacs was created it was a revolutionary thing; it
brought an "easier" way to do "complex" things in that time's standard
and broke many paradigms. Why now we constantly insist in "paradigm of
computing" and "historic reasons" or "because in the 90's ..."? I am a
big supporter of backward compatibility, but sometimes the problem
becomes "evolve or die".

Every software has a complex social part; and part of that is to satisfy
general user's needs (because not all the users must be programmers and
even not all programmers have to be lisp programmers or understand the
emacs internals).

Just a recent example:

It's worth nothing to have a better technical feature if most of the
users prefer something else or don't really care the benefits if they
sacrifice simplicity (like for example undo) or don't know about them or
are used to, and like something else. OTOH the strong positions about
having a normal undo-redo in vanilla ()even not by default for years and
trying to enforce the user to follow our "technically better paradigm"
just made that alternative buggy undo-redo implementations grow like
mushrooms; some of them with bad implementations and giving a bad
experience to final users.

One of the things we must understand is that even not all developers
need to be programmers, know lisp or understand the benefits of undo
over undo-redo. We need help with the documentation, the web sites,
sysadmins, designers, web designers, javascript, CSS and the other
beasts, even youtubers, publishers and journalists etc. And is more
probable that all those help here if they can do part of their work in
emacs; even if they have no idea about lisp, packages, and prefer a
black screen and CUA mode.

It's my opinion.

>[1] https://lawsofux.com/
>
>--
>İ. Göktuğ Kayaalp / @cadadr / <https://www.gkayaalp.com/>
>pgp:   024C 30DD 597D 142B 49AC 40EB 465C D949 B101 2427
>

Re: Changes for emacs 28

[Göktuğ Kayaalp]

On 2020-09-13 15:53 +03, Ergus <spacibba@aol.com> wrote:
> Why the vanilla emacs users almost hasn't increased or has decreases if
> the number of programmers has exponentially grow in the world?  And
> being emacs so powerful and old; how is it possible that it is
> frequently not even listed in the GNU/Linux popular editors articles or
> it is back in the list?  The emacs popularity is so low these days (even
> in GNU/Linux users) that some distros still comes with emacs 24. And if
> we split spacemacs and doom apart it is almost negligible... we are even
> after vim.

Those distros are part of the Emacs community.  And IMHO a very good
part.  With them, a very diverse set of users find ways to make use of
Emacs.

As to why Emacs is not more popular, well, why should it be popular in
the first place?  I’d say Emacs has thrived in the last decade and
personally I’d fancy a stable but content community over a large one.

> How the emacs modifications (specially spacemacs) have found a set of
> frequent developers, and a big younger community? (which is not bigger
> because it is a bit overloaded of external packages IMO)

Because they are producing great software that helps people in ways
Emacs core may not.

> How is it possible that all those dummy and young editors have multiple
> times more users and community than Emacs when they don't really bring
> anything much better than us?

That’s insulting to the users and developers of those editors, which
are, again, great software.

> Are we sure we don't need that "fresh air", "new ideas" and "lot of
> work" to be happening in vanilla directly? Even if we (former users)
> disagree with some of them and have to add 3, 4 or 10 extra lines to our
> config to disable them?

Nobody’s against that so long as breakage is not _disastrous_.  And
certain changes proposed, like those regarding default colours, have the
potential to be so.

It’s not our configs.  It’s many packages that are built upon those
values.  Ultimately software evolves and APIs get outdated, but big
changes should be done with as much discussion and criticism as
possible, so please don’t think that the more conservative members of
the community are trying to hamper the development of Emacs or are
gatekeeping.  Everyone’s views are important and necessary.

> I think that when emacs was created it was a revolutionary thing; it
> brought an "easier" way to do "complex" things in that time's standard
> and broke many paradigms. Why now we constantly insist in "paradigm of
> computing" and "historic reasons" or "because in the 90's ..."? I am a
> big supporter of backward compatibility, but sometimes the problem
> becomes "evolve or die".

You’re over-dramatising it.  Emacs was a nice idea that built upon the
paradigm of software it was created in.  Lisp machines, screen editors
becoming a thing after the introduction of cursor adressable screens.

And there’s definitely ways to evolve compatibly.  Linux doesn’t die
because not everyone uses Yggdrasil anymore.

> Every software has a complex social part; and part of that is to satisfy
> general user's needs (because not all the users must be programmers and
> even not all programmers have to be lisp programmers or understand the
> emacs internals).

That’s a false tautology.  Not every piece of software needs to satisfy
every type of users’ needs.  In fact, software that tries to do that,
dies.



--
İ. Göktuğ Kayaalp / @cadadr / <https://www.gkayaalp.com/>
pgp:   024C 30DD 597D 142B 49AC 40EB 465C D949 B101 2427

Re: Changes for emacs 28

[Ergus]

On Sun, Sep 13, 2020 at 06:05:33PM +0300, Göktuğ Kayaalp wrote:
>On 2020-09-13 15:53 +03, Ergus <spacibba@aol.com> wrote:
>> Why the vanilla emacs users almost hasn't increased or has decreases if
>> the number of programmers has exponentially grow in the world?  And
>> being emacs so powerful and old; how is it possible that it is
>> frequently not even listed in the GNU/Linux popular editors articles or
>> it is back in the list?  The emacs popularity is so low these days (even
>> in GNU/Linux users) that some distros still comes with emacs 24. And if
>> we split spacemacs and doom apart it is almost negligible... we are even
>> after vim.
>
>Those distros are part of the Emacs community.  And IMHO a very good
>part.  With them, a very diverse set of users find ways to make use of
>Emacs.
>
Agree. But many times they need to reinvent the wheel and duplicate
efforts to add things unavailable and claimed in vanilla (there are many
examples of unneeded duplication in melpa with almost no differences
between them.)


>> How the emacs modifications (specially spacemacs) have found a set of
>> frequent developers, and a big younger community? (which is not bigger
>> because it is a bit overloaded of external packages IMO)
>
>Because they are producing great software that helps people in ways
>Emacs core may not.
>
Sometimes maybe, but in general... Why emacs may not?

>> How is it possible that all those dummy and young editors have multiple
>> times more users and community than Emacs when they don't really bring
>> anything much better than us?
>
>That’s insulting to the users and developers of those editors, which
>are, again, great software.
>
Sorry, I should have added: compared to emacs ;p

>> I think that when emacs was created it was a revolutionary thing; it
>> brought an "easier" way to do "complex" things in that time's standard
>> and broke many paradigms. Why now we constantly insist in "paradigm of
>> computing" and "historic reasons" or "because in the 90's ..."? I am a
>> big supporter of backward compatibility, but sometimes the problem
>> becomes "evolve or die".
>
>You’re over-dramatising it.  Emacs was a nice idea that built upon the
>paradigm of software it was created in.  Lisp machines, screen editors
>becoming a thing after the introduction of cursor adressable screens.
>
>And there’s definitely ways to evolve compatibly.  Linux doesn’t die
>because not everyone uses Yggdrasil anymore.
>
The difference is that vanilla is not a kernel not a "distro" but both.

The number of kernel developers is relatively big and the number of
GNU/Linux distros is huge, so they come and go without affecting the
kernel at all. There are also some companies implied to support the
kernel in different ways and of course the sort of "monopoly" the kernel
has in some fields like HPC and IOT.

While in our case emacs vanilla IS the distro, with many alternatives
around and a small set of developers doing their best.

So in case of a comparison, maybe openBSD is a more realistic
parallelism... and to compare with a distro you should look at spacemacs
or equivalents. If a distro disappears there are others coming, but if
the kernel disappears (or die) then also the distros will.

>> Every software has a complex social part; and part of that is to satisfy
>> general user's needs (because not all the users must be programmers and
>> even not all programmers have to be lisp programmers or understand the
>> emacs internals).
>
>That’s a false tautology.  Not every piece of software needs to satisfy
>every type of users’ needs.  In fact, software that tries to do that,
>dies.
>
>
I agree there, but not every piece of code is emacs. Otherwise we won't
have a music player, eww, mail client, terminal and gui interface,
dired and so on.

We can't expect to do the same than a specialized program (unless we
try). But text editing es something that almost everyone does so almost
everyone needs a text editor.

>
>--
>İ. Göktuğ Kayaalp / @cadadr / <https://www.gkayaalp.com/>
>pgp:   024C 30DD 597D 142B 49AC 40EB 465C D949 B101 2427
>

Re: Changes for emacs 28

[Göktuğ Kayaalp]

On 2020-09-13 19:17 +03, Ergus <spacibba@aol.com> wrote:
> Agree. But many times they need to reinvent the wheel and duplicate
> efforts to add things unavailable and claimed in vanilla (there are many
> examples of unneeded duplication in melpa with almost no differences
> between them.)

That’s not a net negative.  Similar packages cater to similar but
different needs.

By that logic why have different text editors one ed(1) can handle all
text editing?

If you don’t think about it in competitive and/or corporate terms,
coexistence of similar but different projects is a net positive for any
use case because people’s needs are similar but different.

> Sometimes maybe, but in general... Why emacs may not?

B a c k w a r d s   c o m p a t i b i l i t y .

> Sorry, I should have added: compared to emacs ;p

Doesn’t change much.  Many of the editors we’re talking about are as
good and as capable as Emacs.

> The difference is that vanilla is not a kernel not a "distro" but both.
>
> The number of kernel developers is relatively big and the number of
> GNU/Linux distros is huge, so they come and go without affecting the
> kernel at all. There are also some companies implied to support the
> kernel in different ways and of course the sort of "monopoly" the kernel
> has in some fields like HPC and IOT.
>
> While in our case emacs vanilla IS the distro, with many alternatives
> around and a small set of developers doing their best.
>
> So in case of a comparison, maybe openBSD is a more realistic
> parallelism... and to compare with a distro you should look at spacemacs
> or equivalents. If a distro disappears there are others coming, but if
> the kernel disappears (or die) then also the distros will.

I don’t get what this is supposed to mean.  Emacs has lived on with way
smaller popularity and a smaller number of core developers for decades.

And the main roadblock there is the C core, not anything else.  There
are efforts like Remacs and Guile-Emacs, which are relevant in that
space.

> I agree there, but not every piece of code is emacs. Otherwise we won't
> have a music player, eww, mail client, terminal and gui interface,
> dired and so on.
>
> We can't expect to do the same than a specialized program (unless we
> try). But text editing es something that almost everyone does so almost
> everyone needs a text editor.

You’d be surprised.  The majority of computer users mainly use phones
and the majority of users don’t even know what plain text is, let alone
editing is.  You’d be surprised how hard it is to explain the concept of
plain text to people.

We’re a niche within a niche within a niche.

--
İ. Göktuğ Kayaalp / @cadadr / <https://www.gkayaalp.com/>
pgp:   024C 30DD 597D 142B 49AC 40EB 465C D949 B101 2427

Re: Changes for emacs 28

[Arthur Miller]

tomas@tuxteam.de writes:

> On Sun, Sep 13, 2020 at 11:41:45AM +0300, Juri Linkov wrote:
>> >> > I think that this is the case, most programmes seem to use the
>> >> > "Hamburger Menu"[0] instead of a transitional top-menu. I'm not sure
>> >> > what the reason for this change was, but I have a hunch one of the
>> >> > motivating reasons was the attempt to merge applications and the window
>> >> > frames
>> 
>> If the menu-bar isn't displayed then we could display the Hamburger icon
>> in the tool-bar, and clicking on it will pop-up the menu with items from
>> the menu-bar, so users won't need to display both menu-bar and tool-bar.
>> 
>> > Me? I'd say the Hamburger menu is the latest fad, to be taken over
>> > next year by the Sushi menu
>> 
>> Unlike the Hamburger menu that has three sticks,
>> the Sushi menu icon should have two chopsticks.
>
> Perhaps with something mushy and fishy in-between
Please keep it vegan!

> The table TEC posted (Message-ID: <87o8maj1kh.fsf@gmail.com>)
> is very interesting. Do you think the popularity of vscode
> and vs (both at the  list's top) stems from the colours? Or
> rather from the fact that there is an incredibly rich behemoth
> behind both of them and that many developers are working,
> directly or indirectly for it? Or from some mixture of both?
Money certainly plays role when it comes to making software; paid devs =
more development; but I wouldn't say VS (Studion or Code) are that
popular just because MS is behind.

> Microsoft has a long record of trying to suck in users into
> their dependency from them. It's their business model.
Yes, and now they are realeasing their "security services" to GNU/Linux
too to such in some of those users who are not using their OS:

https://techcommunity.microsoft.com/t5/microsoft-defender-atp/microsoft-defender-atp-for-linux-is-coming-and-a-sneak-peek-into/ba-p/1192251

I guess they will need to send some "feedback" data back to MS servers
for "security" analysis? :-)

> The fact that Microsoft put 7 billions on the table to
> acquire Github should be telling, in itself. A platform
> which transforms Git's inherently decentralised model into
> a centralised service (when I worked for some big company,
> developers there saw Github as a synonym for git, and that
> was before the acquisition).
They are out for user data; information is everything, big data and how
people use computers, exchange information etc is where money seems to
be. Probably same reason why they penetrate GNU/Linux too. I am sure one
day, operating system will go same destiny as text editors, web browsers
and compiler - be free of charge. It is probably a matter of time when
Windows will become free to user for "priate" and/or some business users.

> I'm not arguing that Emacs shoud make it hard for people coming
> from vscode, on the contrary. But the argument "it's more popular,
> so it must be better" is too naive, I think.
Indeed, popularity is not always a measure of quality. Best technology
does not always win, unfortunately, political, financial or other
reasons can unfortunately stand in the way of quality.

Re: Changes for emacs 28

[tomas]

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

On Sun, Sep 13, 2020 at 02:15:55PM +0200, Arthur Miller wrote:
> tomas@tuxteam.de writes:

[...]

> > Perhaps with something mushy and fishy in-between
> Please keep it vegan!

But then, non-vegan users will protest!

> > The table TEC posted [...]

> Money certainly plays role when it comes to making software; paid devs =
> more development;

...and thus mindshare

> but I wouldn't say VS (Studion or Code) are that
> popular just because MS is behind.

It's the mindshare effect I'm hinting at: if you are using
X at work (because you must: someone else has made that
choice for you), you'll tend to use X privately, since you
already invested in learning it. Perhaps you even don't notice
how much you invested (a kind of Stockholm syndrome), because
you did that "on pay".

Comparing "that ease of learning" to any other has to result
in a slanted playing field.

> They are out for user data [...]

I think that's only part of it. Dependency is key.

I've watched people trying to change their search engine.

Cheers
 - t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Changes for emacs 28

[chad]

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

On Sun, Sep 13, 2020 at 3:31 AM <tomas@tuxteam.de> wrote:

> But the argument "it's more popular, so it must be better" is too naive, I
> think.
>

As conversations progress, details get dropped because context builds up.
That said, I think it's important to realize that "it's more popular, so it
must be better" isn't the argument that brought up this (current wave of
this periodically-recurring) discussion; rather, the argument is "people
try emacs but go (back) to VSCode, because ...". Usually, that sentence
ends in some form of "it's much easier/more intuitive to get started" or
"it's quick/easy/obvious how to get it to 'it just-works'".

In other words, the popularity is a symptom, not a cause. It's worthwhile
to remind ourselves of this now and then, but it's not the central thrust
of the original argument (even if it is sometimes used as evidence for
subsequent points).

Similarly, this point:

On Sun, Sep 13, 2020 at 3:59 AM Göktuğ Kayaalp <self@gkayaalp.com> wrote:

> We’re asking "why people aren’t coming to Emacs in hordes" too much,
> when "why are people using Emacs in the first place" is the more
> important one.


The argument that started (this wave) is more about how and why people
`bounce off of Emacs' so often. While there are always new people with
unique viewpoints, I have personally seen many, _many_ potential emacs
users (including programmers, scientists, and other professionals who very
much understand the concept of investing time in mastering tools) try
emacs, and give up, often very quickly. This has been happening for decades
-- For example, way back when I was an undergrad, I used to work user
support for students, faculty, and staff. Emacs was the default text
editor, and still we saw lots of people try emacs and give it up for other
choices, even when those options were known to be less powerful, buggier,
and not officially supported.

My point here is not to call anyone out in the discussion, but to remind
(reassert?) that Emacs' "approachability" has always been a concern, and
that issue has gotten more intense as the baseline of computer familiarity
and competence has increased dramatically. This issue doesn't concern
"market share" or "general popularity", although that has some obvious
upsides -- it's about the large numbers of people who understand that Emacs
should be especially interesting to them, and invest some effort into
trying it, and don't get very far. In addition to the fringe benefits of
network effects, there are a bunch of potential hackers, maintainers,
porters, documentation writers, editors, and the like that bounce off of
emacs. I think it's clear that it would be very helpful to the project to
have more of those people bounce off less quickly, at least.

Hope that helps,
~Chad

[-- Attachment #2: Type: text/html, Size: 3784 bytes --]

Re: Changes for emacs 28

[tomas]

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

On Mon, Sep 14, 2020 at 11:45:27AM -0700, chad wrote:
> On Sun, Sep 13, 2020 at 3:31 AM <tomas@tuxteam.de> wrote:
> 
> > But the argument "it's more popular, so it must be better" is too naive, I
> > think.

[...]

> try emacs but go (back) to VSCode, because ...". Usually, that sentence
> ends in some form of "it's much easier/more intuitive to get started" or
> "it's quick/easy/obvious how to get it to 'it just-works'".
> 
> In other words, the popularity is a symptom, not a cause.

This is exactly the point I was putting in question: My
take is that popularity is part of a giant feedback loop,
so it's *both*, a symptom and a cause. And a (non-negligible)
set of forces driving that feedback loop are the marketing
departments of big corps [1]. They wouldn't be doing their
jobs if it weren't so.

Failing to see this leads to this over-eager "how can we
change Emacs to make it more popular" thing, instead of
to a more balanced view, where potential changes are
judged against a more complete set of principles and
goals (newcomer friendliness surely being one of them!).

[...]

Cheers

[1] Whose goals and values don't always align with ours,
   to put it politely.

 - t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Changes for emacs 28

[Dmitry Gutov]

On 15.09.2020 11:12, tomas@tuxteam.de wrote:
> On Mon, Sep 14, 2020 at 11:45:27AM -0700, chad wrote:
>> On Sun, Sep 13, 2020 at 3:31 AM <tomas@tuxteam.de> wrote:
>>
>>> But the argument "it's more popular, so it must be better" is too naive, I
>>> think.
> 
> [...]
> 
>> try emacs but go (back) to VSCode, because ...". Usually, that sentence
>> ends in some form of "it's much easier/more intuitive to get started" or
>> "it's quick/easy/obvious how to get it to 'it just-works'".
>>
>> In other words, the popularity is a symptom, not a cause.
> 
> This is exactly the point I was putting in question: My
> take is that popularity is part of a giant feedback loop,
> so it's *both*, a symptom and a cause. And a (non-negligible)
> set of forces driving that feedback loop are the marketing
> departments of big corps [1]. They wouldn't be doing their
> jobs if it weren't so.

A feedback loop is of course there.

But since we're not in marketing department, and we're not outlining a 
promotional campaign, it's also irrelevant.

We're not living in a vacuum, and we try to help real people. If a 
feature, or a UI design, or etc, has reached a significant level of 
popularity, adopting it in our program is likely to be beneficial. When 
someone comes in with just basic familiarity of other programs such as 
VS Code, and manages to become productive enough in Emacs faster because 
of that, it _is_ good.

It's far from the only consideration we should make, but scoffing at 
"popular" misses the point.

> Failing to see this leads to this over-eager "how can we
> change Emacs to make it more popular" thing, instead of
> to a more balanced view, where potential changes are
> judged against a more complete set of principles and
> goals (newcomer friendliness surely being one of them!).

As long as we don't discount familiarity when talking about newcomer 
friendliness, I agree.

Re: Changes for emacs 28

[tomas]

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

On Tue, Sep 15, 2020 at 09:27:42PM +0300, Dmitry Gutov wrote:

[...]

> >This is exactly the point I was putting in question: My
> >take is that popularity is part of a giant feedback loop,

[...]

> A feedback loop is of course there.
> 
> But since we're not in marketing department, and we're not outlining
> a promotional campaign, it's also irrelevant.

I think it's relevant, inasmuch as we should try to understand
where things come from, and especially how they impact user
freedom whenever we consider emulating them.

> We're not living in a vacuum, and we try to help real people. If a
> feature, or a UI design, or etc, has reached a significant level of
> popularity, adopting it in our program is likely to be beneficial.
> When someone comes in with just basic familiarity of other programs
> such as VS Code, and manages to become productive enough in Emacs
> faster because of that, it _is_ good.
> 
> It's far from the only consideration we should make,

Exactly.

>       but scoffing at "popular" misses the point.

I'm not for scoffing. But most definitely for a critical valuation
and for an understanding where things come from.

Some "features" coming from our "commercial competitors" may be
good ideas. Some are just attempts at differentiation, to gather
attention or market share. Copy the first, not necessarily the
second.

> >Failing to see this leads to this over-eager "how can we
> >change Emacs to make it more popular" [...]

> As long as we don't discount familiarity when talking about newcomer
> friendliness, I agree.

Alternatively, we can just offer bridges. Emacs is flexible
enough to play vi, after all :-)

Cheers
 - t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Changes for emacs 28

[Gregory Heytings via Emacs development discussions.]

>
> This is exactly the point I was putting in question: My take is that 
> popularity is part of a giant feedback loop, so it's *both*, a symptom 
> and a cause. And a (non-negligible) set of forces driving that feedback 
> loop are the marketing departments of big corps [1]. They wouldn't be 
> doing their jobs if it weren't so.
>

This is not clear at all IMO.  When users choose to use VS Code or Atom or 
Emacs or ..., they choose between a number of free (as in beer) products. 
In such cases I tend to think that marketing plays little if any role, and 
that it's the quality of the product that matters.  More precisely, not 
the absolute quality, but the quality for newcomers.  As Chad wrote: "it's 
much easier/more intuitive to get started" or "it's quick/easy/obvious how 
to get it to 'it just-works'".

>
> Failing to see this leads to this over-eager "how can we change Emacs to 
> make it more popular" thing, instead of to a more balanced view, where 
> potential changes are judged against a more complete set of principles 
> and goals (newcomer friendliness surely being one of them!).
>

IMO, it's pointless to discuss whether Emacs should be changed, or how 
potential changes should be judged.  In fact I don't understand why such 
discussions/debates take place: Emacs is likely the most flexible of all 
available editors, and can be adapted to all imaginable needs.

So the only thing that should change in Emacs is that it should be made 
easier (even more: as easy as possible) to customize and understand for 
newcomers.

Re: Changes for emacs 28

[tomas]

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

On Tue, Sep 15, 2020 at 08:45:56PM +0000, Gregory Heytings wrote:
> 
> >
> >This is exactly the point I was putting in question: My take is
> >that popularity is part of a giant feedback loop [...]

> This is not clear at all IMO.  When users choose to use VS Code or
> Atom or Emacs or ..., they choose between a number of free (as in
> beer) products. In such cases [1] I tend to think that marketing plays
> little if any role, and that it's the quality of the product that
> matters.  More precisely, not the absolute quality, but the quality
> for newcomers.  As Chad wrote: "it's much easier/more intuitive to
> get started" or "it's quick/easy/obvious how to get it to 'it
> just-works'".

[1] But "such cases" are the exception. When I worked at a bigger
company, I /had/ to use (to me) horrible software. After a while,
most people got used to it and enjoyed their Stockholm syndrome.
I seem to be somewhat stubborn (which didn't make my life easier,
mind you).

[...]

> IMO, it's pointless to discuss whether Emacs should be changed, or
> how potential changes should be judged.  In fact I don't understand
> why such discussions/debates take place [...]

No, no. I think such debates are important, to help shape Emacs's
evolution.

> flexible of all available editors, and can be adapted to all
> imaginable needs.
> 
> So the only thing that should change in Emacs is that it should be
> made easier (even more: as easy as possible) to customize and
> understand for newcomers.

In this we agree.

Cheers
 - t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Changes for emacs 28

[Alan Third]

On Tue, Sep 15, 2020 at 08:45:56PM +0000, Gregory Heytings via Emacs development discussions. wrote:
> This is not clear at all IMO.  When users choose to use VS Code or Atom or
> Emacs or ..., they choose between a number of free (as in beer) products. In
> such cases I tend to think that marketing plays little if any role, and that
> it's the quality of the product that matters.

One thing I see come up time and again is how so many people believe
that all Emacs users have crippled, arthritic hands because of the use
of modifiers. I'm sure it genuinely puts people off Emacs.

That is "marketing".
-- 
Alan Third

Re: Changes for emacs 28

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Date: Sun, 13 Sep 2020 11:41:45 +0300
> Cc: emacs-devel@gnu.org
> 
> If the menu-bar isn't displayed then we could display the Hamburger icon
> in the tool-bar, and clicking on it will pop-up the menu with items from
> the menu-bar, so users won't need to display both menu-bar and tool-bar.

If the menu bar isn't displayed, C-mouse-3 already displays a menu
that shows all the top-level menu-bar items.  So we don't really need
the Hamburger icon (but it wouldn't hurt to have it, of course --
provided they don't disable the tool bar as well...)

Re: Changes for emacs 28

[Juri Linkov]

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

>> If the menu-bar isn't displayed then we could display the Hamburger icon
>> in the tool-bar, and clicking on it will pop-up the menu with items from
>> the menu-bar, so users won't need to display both menu-bar and tool-bar.
>
> If the menu bar isn't displayed, C-mouse-3 already displays a menu
> that shows all the top-level menu-bar items.  So we don't really need
> the Hamburger icon (but it wouldn't hurt to have it, of course --
> provided they don't disable the tool bar as well...)

Yes, this is useful when they don't disable the tool bar,
then the Hamburger menu will look like this:


[-- Attachment #2: tool-bar-menu.png --]
[-- Type: image/png, Size: 21830 bytes --]

[-- Attachment #3: Type: text/plain, Size: 838 bytes --]


with this patch:

diff --git a/lisp/tool-bar.el b/lisp/tool-bar.el
index 7df1e28e06..3bb8f70ca1 100644
--- a/lisp/tool-bar.el
+++ b/lisp/tool-bar.el
@@ -249,6 +249,16 @@ tool-bar-local-item-from-menu
 (defun tool-bar-setup ()
   (setq tool-bar-separator-image-expression
 	(tool-bar--image-expression "separator"))
+
+  (let ((tool-bar-map (default-value 'tool-bar-map)))
+    (tool-bar-add-item "newsticker/narrow"
+                       (lambda ()
+			 (interactive)
+			 (popup-menu (mouse-menu-bar-map)))
+		       'menu-bar
+		       :visible '(zerop (or (frame-parameter nil 'menu-bar-lines) 0))
+		       :vert-only t
+		       :help "Pop up the global menu bar"))
   (tool-bar-add-item-from-menu 'find-file "new" nil :label "New File"
 			       :vert-only t)
   (tool-bar-add-item-from-menu 'menu-find-file-existing "open" nil

Re: Changes for emacs 28

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: tomas@tuxteam.de,  emacs-devel@gnu.org
> Date: Sun, 13 Sep 2020 21:05:28 +0300
> 
> +    (tool-bar-add-item "newsticker/narrow"

This doesn't exactly look like a Hamburger menu icon...

Also, we'd like to have this at the right edge of the tool bar, where
users will expect it, I think.

Thanks.

Re: Changes for emacs 28

[Juri Linkov]

>> +    (tool-bar-add-item "newsticker/narrow"
>
> This doesn't exactly look like a Hamburger menu icon...

Really?  Maybe someone could help to draw a real hamburger.

> Also, we'd like to have this at the right edge of the tool bar, where
> users will expect it, I think.

IDK, some programs display it on the left, some on the right.

Anyway, there is a bug in tool-bar code that doesn't allow to use
align-to, whereas align-to works perfectly when used on the tab-bar.

Here is the test case to reproduce the bug on the tool-bar:

emacs -Q and eval:

  (define-key-after (default-value 'tool-bar-map) [global-menu-bar]
    `(menu-item (propertize " " 'display '(space :align-to (- right 5)))
                (lambda ()
                  (interactive)
                  (popup-menu (mouse-menu-bar-map)))
                :image ,(tool-bar--image-expression "newsticker/narrow")
                :help "Pop up the global menu bar"))
  (force-mode-line-update)

It doesn't align the icon to the right edge of the tool-bar
whereas the same code aligns it on the tab-bar.

Re: Changes for emacs 28

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: tomas@tuxteam.de,  emacs-devel@gnu.org
> Date: Sun, 13 Sep 2020 22:17:19 +0300
> 
> >> +    (tool-bar-add-item "newsticker/narrow"
> >
> > This doesn't exactly look like a Hamburger menu icon...
> 
> Really?  Maybe someone could help to draw a real hamburger.

You need 3 lines, not 4, for starters.

> > Also, we'd like to have this at the right edge of the tool bar, where
> > users will expect it, I think.
> 
> IDK, some programs display it on the left, some on the right.

But not in the middle, I presume?

> Anyway, there is a bug in tool-bar code that doesn't allow to use
> align-to, whereas align-to works perfectly when used on the tab-bar.
> 
> Here is the test case to reproduce the bug on the tool-bar:
> 
> emacs -Q and eval:
> 
>   (define-key-after (default-value 'tool-bar-map) [global-menu-bar]
>     `(menu-item (propertize " " 'display '(space :align-to (- right 5)))
>                 (lambda ()
>                   (interactive)
>                   (popup-menu (mouse-menu-bar-map)))
>                 :image ,(tool-bar--image-expression "newsticker/narrow")
>                 :help "Pop up the global menu bar"))
>   (force-mode-line-update)
> 
> It doesn't align the icon to the right edge of the tool-bar
> whereas the same code aligns it on the tab-bar.

Here, the above displays nothing at all on the tool bar.

Re: Changes for emacs 28

[Ergus]

On Fri, Sep 11, 2020 at 09:04:59AM +0200, Philip K. wrote:
>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. ]]]
>>
>>   > I'm not a maintainer, but FWIW my opinion is that what will most likely
>>   > happen is that they will never agree to do this.  Menus are not "modern".
>>
>> What in the world?  This strikes me as incomprehensible.
>>
>> Who thinks "Menus are not modern"?  Why?
>> What do they use instead of menus?
>>
>> (Perhaps they use a different kind of menu
>> but do not think of it as a manu.)
>
>I think that this is the case, most programmes seem to use the
>"Hamburger Menu"[0] instead of a transitional top-menu. I'm not sure
>what the reason for this change was, but I have a hunch one of the
>motivating reasons was the attempt to merge applications and the window
>frames (as GNOME does in the free software world, but Chrome, MS Office,
>etc. do in the non-free world). When no space is left between the
>application and it's frame, the menu must be moved somewhere
>else. Another reason is probably the influence of mobile applications,
>that use these kinds of menus due to lack of space.
>
>[0] https://en.wikipedia.org/wiki/Hamburger_button
>
>-- 
>	Philip K.
>
I agree that people are using such "Hamburger Menu" (not telling we
should do the same or not) Because in the same way some users are
concerned about space saving and line-numbers; others are concerned
about vertical space and menu-bar + toolbar space saving. Usually
screens are wider than taller.

The other thing is the addiction to right click and find everything
there (undo, redo, copy, paste, goto, select all, goto). 

Re: Changes for emacs 28

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

  > The other thing is the addiction to right click and find everything
  > there (undo, redo, copy, paste, goto, select all, goto). 

If we think about this, maybe we could make Emacs handle right-click
in a way they would like.  But it needs to be studied concretely
to make a concrete proposal.

-- 
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: Changes for emacs 28

[Ergus]

On Fri, Sep 11, 2020 at 11:21:41PM -0400, Richard Stallman wrote:
>[[[ 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. ]]]
>
>  > The other thing is the addiction to right click and find everything
>  > there (undo, redo, copy, paste, goto, select all, goto).
>
>If we think about this, maybe we could make Emacs handle right-click
>in a way they would like.  But it needs to be studied concretely
>to make a concrete proposal.
>
Actually there are already some context menus for right click.

https://github.com/zonuexe/right-click-context
or
https://www.emacswiki.org/emacs/mouse3.el

In the simplest case we only need to put in the right-click menu what is
already in the tool-bar.

The real problem is that now the right click is bind to
mouse-save-then-kill which I have never ever used, but probably others
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: Changes for emacs 28

[Juri Linkov]

> In the simplest case we only need to put in the right-click menu what is
> already in the tool-bar.

The right-click menu needs to be a combination of submenus with:

1. tool-bar items;
2. major-mode menu (currently on <C-down-mouse-3>);
3. buffer menu (currently on <C-down-mouse-1>);
4. face menu (currently on <C-down-mouse-2>);
5. appearance menu (currently on <S-down-mouse-1>);
...

> The real problem is that now the right click is bind to
> mouse-save-then-kill which I have never ever used, but probably others
> have.

Not a problem, just add a new customization option to disable
mouse-save-then-kill on mouse-3, and use the context menu instead.

RE: Changes for emacs 28

[Drew Adams]

> > > I'm not a maintainer, but FWIW my opinion is that what will most likely
> > > happen is that they will never agree to do this.  Menus are not "modern".
> >
> > What in the world?  This strikes me as incomprehensible.
> > Who thinks "Menus are not modern"?  Why?
> > What do they use instead of menus?
> > (Perhaps they use a different kind of menu
> > but do not think of it as a manu.)
> 
> I think that this is the case, most programmes seem to use the
> "Hamburger Menu"[0] instead of a transitional top-menu. I'm not sure
> what the reason for this change was, but I have a hunch one of the
> motivating reasons was the attempt to merge applications and the window
> frames (as GNOME does in the free software world, but Chrome, MS Office,
> etc. do in the non-free world). When no space is left between the
> application and it's frame, the menu must be moved somewhere
> else. Another reason is probably the influence of mobile applications,
> that use these kinds of menus due to lack of space.

1. `C-mouse-3' does that - essentially a hamburger menu.

2. Library `tool-bar+.el' offers something similar for
the tool-bar: `tool-bar-pop-up-mode'.  It adds a pseudo
menu to the menu-bar, which, if clicked, shows the
tool-bar for the use of a single action.  This saves the
tool-bar real estate most of the time.

If the menu-bar isn't displayed then you can just use
`C-mouse-3' to show it, and choose the pseudo menu that
pops up the tool-bar temporarily.

https://www.emacswiki.org/emacs/ToolBar#ToolBarPlus

Re: Changes for emacs 28

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

  > I think that this is the case, most programmes seem to use the
  > "Hamburger Menu"[0] instead of a transitional top-menu.

The people who say "menus are not modern" are failing to clearly
analyze what are complaining about -- or else their message has
been garbled in transmission to us.

They do not dislike menus.  They dislike one particular way of
displaying menus.

I have seen programs with hamburger buttons.  If you don't want to use
the menus very often, that interface is ok.

Now that we understand what they meant, maybe we can give them what
they want.  Can we implement Emacs menus through the hamburger systems
of various toolkits?  Run them through the meatgrinder, shall we say?
;-}

-- 
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: Changes for emacs 28

[Dmitry Gutov]

On 11.09.2020 00:21, Gregory Heytings via Emacs development discussions. 
wrote:
> 
> I'm not a maintainer, but FWIW my opinion is that what will most likely 
> happen is that they will never agree to do this.  Menus are not "modern".

That's certainly the current trend in Emacs customizations, but it's not 
a universal rule.

VS Code has a traditional menu. Atom has a menu. Visual Studio and 
IntelliJ IDEA of course have them too.

Re: Changes for emacs 28

[Arthur Miller]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 11.09.2020 00:21, Gregory Heytings via Emacs development discussions. wrote:
>> I'm not a maintainer, but FWIW my opinion is that what will most likely happen
>> is that they will never agree to do this.  Menus are not "modern".
>
> That's certainly the current trend in Emacs customizations, but it's not a
> universal rule.
>
> VS Code has a traditional menu. Atom has a menu. Visual Studio and IntelliJ IDEA
> of course have them too.
When I used to make money by programming VBA with MS Office and C++ with
VStudio I used to turn off all toolbars and menus I could. Back then
computer screens where much smaller then today, and even today I still
fight for vertical screen estate on my computer.

For that reason, on my home computer I run a WM without decorations, Emacs
without any gui elements more then main gui window, Firefox & Gimp with
menus and gui hidden etc. I have never used IntellliJ software, but I
guess they will give you option to maximize the working area by
disabling the gui items too.

Anyway, I don't think GUI should be disabled by default; that should be left to
the user. I am really curious which distro you run :-)?

Re: Changes for emacs 28

[Dmitry Gutov]

On 11.09.2020 14:00, Arthur Miller wrote:
> Dmitry Gutov <dgutov@yandex.ru> writes:
> 
>> On 11.09.2020 00:21, Gregory Heytings via Emacs development discussions. wrote:
>>> I'm not a maintainer, but FWIW my opinion is that what will most likely happen
>>> is that they will never agree to do this.  Menus are not "modern".
>>
>> That's certainly the current trend in Emacs customizations, but it's not a
>> universal rule.
>>
>> VS Code has a traditional menu. Atom has a menu. Visual Studio and IntelliJ IDEA
>> of course have them too.
> When I used to make money by programming VBA with MS Office and C++ with
> VStudio I used to turn off all toolbars and menus I could. Back then
> computer screens where much smaller then today, and even today I still
> fight for vertical screen estate on my computer.

I do too. But menus should be helpful for newcomers (and when they are 
not, we should improve them). So having "starter kits" disable the menus 
right away seems counter-productive.

BTW, the Unity DE and Sublime Text editor included an alternative UI for 
menus, where you hit a key (Alt, in the case of Unity) and then fuzzy 
match on command description.

> For that reason, on my home computer I run a WM without decorations, Emacs
> without any gui elements more then main gui window, Firefox & Gimp with
> menus and gui hidden etc. I have never used IntellliJ software, but I
> guess they will give you option to maximize the working area by
> disabling the gui items too.
> 
> Anyway, I don't think GUI should be disabled by default; that should be left to
> the user. I am really curious which distro you run :-)?

I use Ubuntu with GNOME and the Unite extension which emulates Unity to 
the best extent possible. That means removing application title bars 
when the app is maximized, moving their contents (such as menus) to the 
top panel when possible.

So it's the kind of changes as you did, but to a smaller extent.

Re: Changes for emacs 28

[Ergus]

On Fri, Sep 11, 2020 at 03:50:24PM +0300, Dmitry Gutov wrote:
>On 11.09.2020 14:00, Arthur Miller wrote:
>>Dmitry Gutov <dgutov@yandex.ru> writes:
>>
>>>On 11.09.2020 00:21, Gregory Heytings via Emacs development discussions. wrote:
>>>>I'm not a maintainer, but FWIW my opinion is that what will most likely happen
>>>>is that they will never agree to do this.� Menus are not "modern".
>>>
>>>That's certainly the current trend in Emacs customizations, but it's not a
>>>universal rule.
>>>
>>>VS Code has a traditional menu. Atom has a menu. Visual Studio and IntelliJ IDEA
>>>of course have them too.
>>When I used to make money by programming VBA with MS Office and C++ with
>>VStudio I used to turn off all toolbars and menus I could. Back then
>>computer screens where much smaller then today, and even today I still
>>fight for vertical screen estate on my computer.
>
>I do too. But menus should be helpful for newcomers (and when they are 
>not, we should improve them). So having "starter kits" disable the 
>menus right away seems counter-productive.
>
>BTW, the Unity DE and Sublime Text editor included an alternative UI 
>for menus, where you hit a key (Alt, in the case of Unity) and then 
>fuzzy match on command description.
>
Just a question as I don't use sublime anymore. Do you mean something
like "autohiding" the toolbar or part of it?

>>For that reason, on my home computer I run a WM without decorations, Emacs
>>without any gui elements more then main gui window, Firefox & Gimp with
>>menus and gui hidden etc. I have never used IntellliJ software, but I
>>guess they will give you option to maximize the working area by
>>disabling the gui items too.
>>
>>Anyway, I don't think GUI should be disabled by default; that should be left to
>>the user. I am really curious which distro you run :-)?
>
>I use Ubuntu with GNOME and the Unite extension which emulates Unity 
>to the best extent possible. That means removing application title 
>bars when the app is maximized, moving their contents (such as menus) 
>to the top panel when possible.
>
>So it's the kind of changes as you did, but to a smaller extent.
>
The toolbar is less useful if the right click offers the expected
options in a panel (copy, paste, cut, select all, upcase, highlight all
like this, show error at point).

That's why many applications have removed or hided the toolbar; because
a right click is usually faster than moving the mouse to the top of the
screen. (they also use the <menu> key to show the right click panel from
keyboard but we use it for execute-extended-command)

Sadly we have <mouse-3> bind to mouse-save-then-kill which I don't find
useful at all, but maybe somebody will complain if we change it to
C-<mouse-3> and move the panel to <mouse-3>. Also our right click panel
does not offer those options so it is not as useful now.

Actually there is an external package for that:

https://github.com/zonuexe/right-click-context

So the implementation seems to be pretty simple if we agree in this. WDYT?

RE: Changes for emacs 28

[Drew Adams]

> Sadly we have <mouse-3> bind to mouse-save-then-kill which I don't find
> useful at all, but maybe somebody will complain if we change it to
> C-<mouse-3> and move the panel to <mouse-3>.

1. `mouse-save-then-kill' is very useful, IMO.

2. Library `mouse3.el' gives you any behavior you want
   for mouse-3 - in particular, popup context menus of
   any sort.

   AND it gives you the usual `mouse-save-then-kill'
   behavior.

   IOW, you don't have to choose one or the other, you
   can have both: choose what you want on the fly.

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

https://www.emacswiki.org/emacs/download/mouse3.el


This option lets you do whatever you want with a second
mouse-3 click.  And option `mouse3-double-click-command'
does the same thing for a double-click.

,----
| mouse3-second-click-default-command is a variable defined in `mouse3.el'.
| Its value is mouse3-popup-menu
| 
| Command used for a second `mouse-3' click at the same location.
| The command must accept 2 args: mouse click event and prefix arg.
| 
| This is a default value, which can be programmatically overridden in
| various contexts.  This option is used only if variable
| `mouse3-save-then-kill-command' is nil.
| 
| Two particular values:
|  `mouse3-popup-menu': Pop up a menu of actions on the region.
|  `mouse3-kill/delete-region': Kill or delete the region, according to
|                               `mouse-drag-copy-region'.
| 
| See also `mouse3-double-click-command'.  You will probably want to
| customize these two options together.  To make either a no-op, set the
| value to command `ignore'.
| 
| Note that setting `mouse3-double-click-command' to `mouse3-popup-menu'
| and `mouse3-second-click-default-command' to
| `mouse3-kill/delete-region' is not recommended, because in Emacs a
| double-click event is always preceded automatically by the associated
| single-click event.  See `(elisp) Repeat Events'.
| 
| You can customize this variable.
`----

Re: Changes for emacs 28

[Ergus]

Hi Drew:

This looks interesting. I will give it a look in a while.

Why you don't add your packages to elpa :( otherwise I/us will never
discover them?

Also, if integration with use-packages finally arrives many elpa
packages could be installed on the fly for the new users. And some of
your improvements seems to be good candidates.

And if you update them, the users will get the improvements immediately.

Is it too much work?

On Fri, Sep 11, 2020 at 11:29:41AM -0700, Drew Adams wrote:
>> Sadly we have <mouse-3> bind to mouse-save-then-kill which I don't find
>> useful at all, but maybe somebody will complain if we change it to
>> C-<mouse-3> and move the panel to <mouse-3>.
>
>1. `mouse-save-then-kill' is very useful, IMO.
>
>2. Library `mouse3.el' gives you any behavior you want
>   for mouse-3 - in particular, popup context menus of
>   any sort.
>
>   AND it gives you the usual `mouse-save-then-kill'
>   behavior.
>
>   IOW, you don't have to choose one or the other, you
>   can have both: choose what you want on the fly.
>
>https://www.emacswiki.org/emacs/Mouse3
>
>https://www.emacswiki.org/emacs/download/mouse3.el
>
>
>This option lets you do whatever you want with a second
>mouse-3 click.  And option `mouse3-double-click-command'
>does the same thing for a double-click.
>
>,----
>| mouse3-second-click-default-command is a variable defined in `mouse3.el'.
>| Its value is mouse3-popup-menu
>|
>| Command used for a second `mouse-3' click at the same location.
>| The command must accept 2 args: mouse click event and prefix arg.
>|
>| This is a default value, which can be programmatically overridden in
>| various contexts.  This option is used only if variable
>| `mouse3-save-then-kill-command' is nil.
>|
>| Two particular values:
>|  `mouse3-popup-menu': Pop up a menu of actions on the region.
>|  `mouse3-kill/delete-region': Kill or delete the region, according to
>|                               `mouse-drag-copy-region'.
>|
>| See also `mouse3-double-click-command'.  You will probably want to
>| customize these two options together.  To make either a no-op, set the
>| value to command `ignore'.
>|
>| Note that setting `mouse3-double-click-command' to `mouse3-popup-menu'
>| and `mouse3-second-click-default-command' to
>| `mouse3-kill/delete-region' is not recommended, because in Emacs a
>| double-click event is always preceded automatically by the associated
>| single-click event.  See `(elisp) Repeat Events'.
>|
>| You can customize this variable.
>`----

RE: Changes for emacs 28

[Drew Adams]

> Hi Drew:
> 
> This looks interesting. I will give it a look in a while.
> 
> Why you don't add your packages to elpa :( otherwise I/us will never
> discover them?
> 
> Also, if integration with use-packages finally arrives many elpa
> packages could be installed on the fly for the new users. And some of
> your improvements seems to be good candidates.
> 
> And if you update them, the users will get the improvements immediately.
> 
> Is it too much work?

Sorry.  I prefer to upload to Emacs Wiki (locked pages).

https://www.reddit.com/r/emacs/comments/7vocqa/update_on_melpa_removing_emacswiki_packages_they/dtuhzmt/

It's not hard to discover my Lisp libraries.
It's not hard to use them.  YMMV.

Re: Changes for emacs 28

[Ergus]

On Fri, Sep 11, 2020 at 12:23:34PM -0700, Drew Adams wrote:
>> Hi Drew:
>>
>> This looks interesting. I will give it a look in a while.
>>
>> Why you don't add your packages to elpa :( otherwise I/us will never
>> discover them?
>>
>> Also, if integration with use-packages finally arrives many elpa
>> packages could be installed on the fly for the new users. And some of
>> your improvements seems to be good candidates.
>>
>> And if you update them, the users will get the improvements immediately.
>>
>> Is it too much work?
>
>Sorry.  I prefer to upload to Emacs Wiki (locked pages).
>
>https://www.reddit.com/r/emacs/comments/7vocqa/update_on_melpa_removing_emacswiki_packages_they/dtuhzmt/
>
>It's not hard to discover my Lisp libraries.

I haven't find any reference to mouse-3 anywhere and I have been looking
for alternatives like that for months. Actually I tried many of
them...

>It's not hard to use them.  YMMV.
>
It depends of what we understand by hard... but ok.

RE: Changes for emacs 28

[Drew Adams]

> >It's not hard to discover my Lisp libraries.
> 
> I haven't find any reference to mouse-3 anywhere and I have been looking
> for alternatives like that for months. Actually I tried many of
> them...

Googling for the file name finds some, for me.
Of course, if looking for some `mouse-3' context
menu library you won't know the file name.

But even searching just for "emacs mouse-3" finds
the wiki page for it - for me.  But maybe that's
because my use of the search engine knows me. ;-)

---

All of my libraries (though I sometimes forget to
update this page) are listed and described here:

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

But yes, going there assumes you're looking for
one of my libraries, not that you're looking for
a library that shows a `mouse-3' context menu.

> >It's not hard to use them.  YMMV.
>
> It depends of what we understand by hard... but ok.

Yes.

You need to (1) download a library, (2) put it in a
dir that's in your `load-path', then (3) `require' it
in your init file.

Re: Changes for emacs 28

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

  > I haven't find any reference to mouse-3 anywhere and I have been looking
  > for alternatives like that for months. Actually I tried many of
  > them...

I confused Mouse-3 with C-Mouse-3 in my previous responses.
Please pardon my memory.

I am getting the impression that Emacs differs from "modern" editors
in that they put the menu on Mouse-3 (no Ctrl).  In Emacs,
Mouse-3 is an editing command.

I think we patterned the Emacs bindings of the mouse keys Mouse-1,
Mouse-2 and Mouse-3 after what was the standard in X Windows around
1990.  We could create a global minor mode in which they do
what "modern" editors do -- if that is a well-defined thing.
This would include putting the local menu on Mouse-3 (as well as on C-Mouse-3).

Is that something that new users would make new users much happier?


-- 
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: Changes for emacs 28

[Dmitry Gutov]

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

On 11.09.2020 16:23, Ergus wrote:

>> BTW, the Unity DE and Sublime Text editor included an alternative UI 
>> for menus, where you hit a key (Alt, in the case of Unity) and then 
>> fuzzy match on command description.
>>
> Just a question as I don't use sublime anymore. Do you mean something
> like "autohiding" the toolbar or part of it?

I don't have Sublime installed either. Not sure if it was used in 
conjunction with auto-hiding, but the user could probably pref the menu off.

The feature I meant is also present in Atom and VS Code. You can trigger 
it with Ctrl-Shift-P.

Here's a screenshot.

[-- Attachment #2: Screenshot from 2020-09-12 00-06-06.png --]
[-- Type: image/png, Size: 248625 bytes --]

Re: Changes for emacs 28

[Arthur Miller]

Ergus <spacibba@aol.com> writes:

> On Fri, Sep 11, 2020 at 03:50:24PM +0300, Dmitry Gutov wrote:
>>On 11.09.2020 14:00, Arthur Miller wrote:
>>>Dmitry Gutov <dgutov@yandex.ru> writes:
>>>
>>>>On 11.09.2020 00:21, Gregory Heytings via Emacs development discussions. wrote:
>>>>>I'm not a maintainer, but FWIW my opinion is that what will most likely happen
>>>>>is that they will never agree to do this.� Menus are not "modern".
>>>>
>>>>That's certainly the current trend in Emacs customizations, but it's not a
>>>>universal rule.
>>>>
>>>>VS Code has a traditional menu. Atom has a menu. Visual Studio and IntelliJ IDEA
>>>>of course have them too.
>>>When I used to make money by programming VBA with MS Office and C++ with
>>>VStudio I used to turn off all toolbars and menus I could. Back then
>>>computer screens where much smaller then today, and even today I still
>>>fight for vertical screen estate on my computer.
>>
>> I do too. But menus should be helpful for newcomers (and when they are not, we
>> should improve them). So having "starter kits" disable the menus right away
>> seems counter-productive.
>>
>> BTW, the Unity DE and Sublime Text editor included an alternative UI for
>> menus, where you hit a key (Alt, in the case of Unity) and then fuzzy match on
>> command description.
>>
> Just a question as I don't use sublime anymore. Do you mean something
> like "autohiding" the toolbar or part of it?
>
>>>For that reason, on my home computer I run a WM without decorations, Emacs
>>>without any gui elements more then main gui window, Firefox & Gimp with
>>>menus and gui hidden etc. I have never used IntellliJ software, but I
>>>guess they will give you option to maximize the working area by
>>>disabling the gui items too.
>>>
>>>Anyway, I don't think GUI should be disabled by default; that should be left to
>>>the user. I am really curious which distro you run :-)?
>>
>> I use Ubuntu with GNOME and the Unite extension which emulates Unity to the
>> best extent possible. That means removing application title bars when the app
>> is maximized, moving their contents (such as menus) to the top panel when
>> possible.
>>
>>So it's the kind of changes as you did, but to a smaller extent.
>>
> The toolbar is less useful if the right click offers the expected
> options in a panel (copy, paste, cut, select all, upcase, highlight all
> like this, show error at point).
>
> That's why many applications have removed or hided the toolbar; because
> a right click is usually faster than moving the mouse to the top of the
> screen. (they also use the <menu> key to show the right click panel from
> keyboard but we use it for execute-extended-command)
I also agree, some few years ago before I switched to Helm on "full-time
basis" I used context menus a lot. I had menu-bar and tool-bar turned
off and used mouse to switch buffers and so on. Nowadays it is all Helm
for me since it is even faster to fuzzy complete with a shortcut key
than to move hand to the mouse for the context menu.

There is  a commercial package called Maya. They have a pop-up
window/menu widget they call "hot box". In that pop-up they have all, or
as few as chosen by the user, menus collected in a transparent window
they pop-up under the mouse after the spacebar is hold for a while (I
think it was half a second). As info, the application itself could be
called "emacs for 3d modellers"; it is completely scriptable/extensible
(in-house dialect of TCL), all gui elements can be turned off/on etc.
You can see a demo in action:

https://www.youtube.com/watch?v=o2FB6UIK1rc

(sorry for the YT and non-free JS but it is what it is).

Maybe such or similar widget could be good to have in Emacs? As a
compromise between a minimal GUI, discoverability and avialability of
menus even when gui elements are disabled? A context menu would still be
faster though.

RE: Changes for emacs 28

[Drew Adams]

> There is  a commercial package called Maya. They have a pop-up
> window/menu widget they call "hot box". In that pop-up they have all, or
> as few as chosen by the user, menus collected in a transparent window
> they pop-up under the mouse after the spacebar is hold for a while (I
> think it was half a second). 

`mouse3.el' does this.  But it's initiated by
a right-click, not by holding the space bar.

It could be made to also or instead be initiated
by a keyboard key.  But why?  If the location of
the popup is at the mouse pointer, why make users
involve _both_ the mouse and the keyboard?

> Maybe such or similar widget could be good to have in Emacs? As a
> compromise between a minimal GUI, discoverability and avialability of
> menus even when gui elements are disabled? A context menu would still be
> faster though.

See `mouse3.el'.  I think it provides what I
think you've described.

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

https://www.emacswiki.org/emacs/download/mouse3.el

Re: Changes for emacs 28

[Arthur Miller]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 11.09.2020 14:00, Arthur Miller wrote:
>> Dmitry Gutov <dgutov@yandex.ru> writes:
>> 
>>> On 11.09.2020 00:21, Gregory Heytings via Emacs development discussions. wrote:
>>>> I'm not a maintainer, but FWIW my opinion is that what will most likely happen
>>>> is that they will never agree to do this.  Menus are not "modern".
>>>
>>> That's certainly the current trend in Emacs customizations, but it's not a
>>> universal rule.
>>>
>>> VS Code has a traditional menu. Atom has a menu. Visual Studio and IntelliJ IDEA
>>> of course have them too.
>> When I used to make money by programming VBA with MS Office and C++ with
>> VStudio I used to turn off all toolbars and menus I could. Back then
>> computer screens where much smaller then today, and even today I still
>> fight for vertical screen estate on my computer.
>
> I do too. But menus should be helpful for newcomers (and when they are not, we
> should improve them). So having "starter kits" disable the menus right away
> seems counter-productive.
Yeah I agree; I got it clarified you ment starter kits when you thought
about "distros".

> BTW, the Unity DE and Sublime Text editor included an alternative UI for menus,
> where you hit a key (Alt, in the case of Unity) and then fuzzy match on command
> description.
Ok; I didn't know. I am using Rofi to achieve this in X11/OS and Helm in
Emacs.

>> For that reason, on my home computer I run a WM without decorations, Emacs
>> without any gui elements more then main gui window, Firefox & Gimp with
>> menus and gui hidden etc. I have never used IntellliJ software, but I
>> guess they will give you option to maximize the working area by
>> disabling the gui items too.
>> Anyway, I don't think GUI should be disabled by default; that should be left
>> to
>> the user. I am really curious which distro you run :-)?
>
> I use Ubuntu with GNOME and the Unite extension which emulates Unity to the best
> extent possible. That means removing application title bars when the app is
> maximized, moving their contents (such as menus) to the top panel when possible.
>
> So it's the kind of changes as you did, but to a smaller extent.
I understand; yes it sounds pretty much what I except the top-level bar.
Last time I logged into a Gnome or KDE session was like 4 years agoI
think. Thanks for the answer.

Re: Changes for emacs 28

[Caio Henrique]

Göktuğ Kayaalp <self@gkayaalp.com> writes:

> It appears that in Emacs we have the extra trouble of menu-bar-mode
> being one of the first things people disable

Yeah, I started using Emacs ~11 months ago. Disabling the menu-bar was
the first thing that I did. I learned how to use Emacs watching these video
tutorials https://www.youtube.com/watch?v=8Zkte37UOnA and on the first 5
minutes he teaches how to disable the menu-bar to make Emacs look more
modern.

As a beginner I loved these video tutorials. He has short videos
that teaches how to install and configure use-package, which-key, then
he shows how to change themes and fonts, then he gives an introduction
to org-mode and teaches how to create a literate emacs configuration
file, then he continues teaching how to install and configure
ido-vertical, avy, rainbow-mode etc...

Because of these video tutorials I never bothered trying Doom or
Spacemacs, I just started creating my own configuration on
vanilla. Besides not using the menu-bar, I also never looked the Emacs
tutorial or the Emacs Guided Tour.

Re: Changes for emacs 28

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

  > the first thing that I did. I learned how to use Emacs watching these video
  > tutorials https://www.youtube.com/watch?v=8Zkte37UOnA and on the first 5
  > minutes he teaches how to disable the menu-bar to make Emacs look more
  > modern.

Is it the case that you wanted a hamburger key menu?

-- 
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: Changes for emacs 28

[Caio Henrique]

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. ]]]
>
>   > the first thing that I did. I learned how to use Emacs watching these video
>   > tutorials https://www.youtube.com/watch?v=8Zkte37UOnA and on the first 5
>   > minutes he teaches how to disable the menu-bar to make Emacs look more
>   > modern.
>
> Is it the case that you wanted a hamburger key menu?

No, I wanted to just disable both the menu and the toolbar to have a
more minimalist look and save more screen space. But I do think that
regular menus like the one that Emacs has are better than hamburger
button menus, since IMO it is easier to find specific options and
buttons.

Re: Changes for emacs 28

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

  > There was an idea in another thread that we could ask major distros to
  > not disable menu bar, and I said I could create the issues, but I though
  > I’d wait for some of the maintainers (dis)agree first. What do you
  > think, would such a thing be useful?

I think that would be a good idea.

Another idea: code that runs for beginning users could tell the user,

  To learn what is available in Emacs, we recommend you type
  C-u M-x menu-bar-mode RET
  and then look at all the entries in each menu.

Maybe C-h t could 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: Changes for emacs 28

[Göktuğ Kayaalp]

On 2020-09-11 07:16 +03, Richard Stallman <rms@gnu.org> wrote:
>   > There was an idea in another thread that we could ask major distros to
>   > not disable menu bar, and I said I could create the issues, but I though
>   > I’d wait for some of the maintainers (dis)agree first. What do you
>   > think, would such a thing be useful?
> I think that would be a good idea.

So I just opened three tickets:

https://github.com/syl20bnr/spacemacs/issues/13939
https://github.com/hlissner/doom-emacs/issues/3926
https://github.com/bbatsov/prelude/issues/1278

and contacted Phil Hagelberg, author of better-defaults.el, in private,
because the Github repo was archived and I couldn’t figure out how to
report a bug on his sr.ht repo (looks like the feature is disabled).

If anybody else knows of other prolific distributions, please reply here
and I can add open tickets on their bug trackers too.

> Another idea: code that runs for beginning users could tell the user,
>
>   To learn what is available in Emacs, we recommend you type
>   C-u M-x menu-bar-mode RET
>   and then look at all the entries in each menu.

You mean if menu-bar-mode is disabled?

There is a variety of ideas like this, and they are nice, but IMHO the
social side of this issue is more relevant---why users don’t find and/or
look for all the help and docs bundled with Emacs?---and a social
solution would be of greater use.  E.g. we could prominently feature the
easy availability of extensive docs in Emacs right up top on
<gnu.org/s/emacs>.

If I was to give an Emacs intro class tomorrow to non-programmers, the
very first thing I’d teach, after a very brief description/demo of
Emacs, would be C-h i/f/v/k and how to navigate Info and Help buffers.
That’s because offline documentation is simply _absent_ from most
software people use daily, and many even lack any online
documentation---you’re expected to look at it and /know/.


--
İ. Göktuğ Kayaalp / @cadadr / <https://www.gkayaalp.com/>
pgp:   024C 30DD 597D 142B 49AC 40EB 465C D949 B101 2427

Re: Changes for emacs 28

[Lars Ingebrigtsen]

Göktuğ Kayaalp <self@gkayaalp.com> writes:

> On 2020-09-11 07:16 +03, Richard Stallman <rms@gnu.org> wrote:
>>   > There was an idea in another thread that we could ask major distros to
>>   > not disable menu bar, and I said I could create the issues, but I though
>>   > I’d wait for some of the maintainers (dis)agree first. What do you
>>   > think, would such a thing be useful?
>> I think that would be a good idea.
>
> So I just opened three tickets:
>
> https://github.com/syl20bnr/spacemacs/issues/13939
> https://github.com/hlissner/doom-emacs/issues/3926
> https://github.com/bbatsov/prelude/issues/1278

For what it's worth, I do not think this is a good idea.  Emacs
distributors should do whatever they think is best, and for emacs-devel
to chide them (even as gently as in these issues) for their decisions is
counter-productive at best.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Changes for emacs 28

[Stefan Kangas]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> For what it's worth, I do not think this is a good idea.  Emacs
> distributors should do whatever they think is best, and for emacs-devel
> to chide them (even as gently as in these issues) for their decisions is
> counter-productive at best.

Good point.  I never considered that it could be seen as chiding them.
Maybe it was a mistake for me to insist on this idea.

RE: Changes for emacs 28

[Drew Adams]

> If I was to give an Emacs intro class tomorrow to non-programmers, the
> very first thing I’d teach, after a very brief description/demo of
> Emacs, would be C-h i/f/v/k and how to navigate Info and Help buffers.
> That’s because offline documentation is simply _absent_ from most
> software people use daily, and many even lack any online
> documentation---you’re expected to look at it and /know/.

Yes!  Learning to ask Emacs is learning Emacs...

Re: Changes for emacs 28

[Stefan Kangas]

Göktuğ Kayaalp <self@gkayaalp.com> writes:

> So I just opened three tickets:

Thanks for doing that.

> If anybody else knows of other prolific distributions, please reply here
> and I can add open tickets on their bug trackers too.

There's a list here, but I don't know how complete it is:
https://www.emacswiki.org/emacs/StarterKits

Best regards,
Stefan Kangas

Re: Changes for emacs 28

[Göktuğ Kayaalp]

On 2020-09-11 22:09 +03, Stefan Kangas <stefankangas@gmail.com> wrote:
> Thanks for doing that.

You’re welcome!

> There's a list here, but I don't know how complete it is:
> https://www.emacswiki.org/emacs/StarterKits

Thanks for the link.  I feel like waiting to see how the projects I
contacted behave before contacting others would be a good idea?  Sounds
sensible?

--
İ. Göktuğ Kayaalp / @cadadr / <https://www.gkayaalp.com/>
pgp:   024C 30DD 597D 142B 49AC 40EB 465C D949 B101 2427

Re: Changes for emacs 28

[Stefan Kangas]

Göktuğ Kayaalp <self@gkayaalp.com> writes:

> Thanks for the link.

Thanks for the work you have done so far.

> I feel like waiting to see how the projects I contacted behave before
> contacting others would be a good idea?  Sounds sensible?

Sounds reasonable.  But given that Lars had some reservations about
doing this at all, perhaps we could just leave it at that.  See his
separate email about this.

Re: Changes for emacs 28

[Göktuğ Kayaalp]

On 2020-09-12 00:40 +03, Stefan Kangas <stefankangas@gmail.com> wrote:
> Sounds reasonable.  But given that Lars had some reservations about
> doing this at all, perhaps we could just leave it at that.  See his
> separate email about this.

Saw the message, yes, reasonable indeed.  I’ve tried to make it as clear
as possible that it’s just a suggestion for the greater good of the
community, but it coming from a place of ‘authority’, can definitely be
read that way.

IMO, let’s see how upstreams respond, tho.  If it’s positive, we talk
again and /maybe/ continue, if it’s negative, we stop.



--
İ. Göktuğ Kayaalp / @cadadr / <https://www.gkayaalp.com/>
pgp:   024C 30DD 597D 142B 49AC 40EB 465C D949 B101 2427

Re: Changes for emacs 28

[Eli Zaretskii]

> From: Göktuğ Kayaalp <self@gkayaalp.com>
> Cc: Yuri Khan <yuri.v.khan@gmail.com>, drew.adams@oracle.com,
>  self@gkayaalp.com, ghe@sdf.org, casouri@gmail.com, tecosaur@gmail.com,
>  emacs-devel@gnu.org
> Date: Fri, 11 Sep 2020 00:01:29 +0300
> 
> It appears that in Emacs we have the extra trouble of menu-bar-mode
> being one of the first things people disable, and some major ‘distros’
> like Spacemacs seem to disable them by default, so many people never
> even see it.  Also, FWIW, I just noticed the Options menu for the first
> time in my life, after reading Drew’s message, even though the menu bar
> has been sitting there before my eyes for years...
> 
> There was an idea in another thread that we could ask major distros to
> not disable menu bar, and I said I could create the issues, but I though
> I’d wait for some of the maintainers (dis)agree first. What do you
> think, would such a thing be useful?

Disabling the menu bar and the tool bar, let alone doing that by
default, makes very little sense to me.  I'm running with both of them
enable, although I rarely if ever use them.

So yes, please do urge those distros not to disable these UI features.

Thanks.

Re: Changes for emacs 28

[Dmitry Gutov]

On 11.09.2020 09:01, Eli Zaretskii wrote:
> Disabling the menu bar and the tool bar, let alone doing that by
> default, makes very little sense to me.  I'm running with both of them
> enable, although I rarely if ever use them.

Toolbar takes up space. We also reportedly have less than high quality 
icons in there, on some platforms more than others.

The distros we're talking about usually pride themselves (among other 
things) on "slick" appearance and keyboard-only interaction.

There's a small chance they will enable the menu by default just because 
you asked, but the toolbar is a lost cause.

Re: Changes for emacs 28

[Gregory Heytings via Emacs development discussions.]

>
> The distros we're talking about usually pride themselves (among other 
> things) on "slick" appearance and keyboard-only interaction.
>
> There's a small chance they will enable the menu by default just because 
> you asked
>

If, and only if, Emacs adapts the appearance of the menu bar to the chosen 
theme.  A boring gray oldish menu bar above a dark mode buffer goes 
against "slick" appearance.

Re: Changes for emacs 28

[Robert Pluim]

>>>>> On Fri, 11 Sep 2020 09:19:03 +0000, Gregory Heytings via "Emacs development discussions." <emacs-devel@gnu.org> said:

    >> 
    >> The distros we're talking about usually pride themselves (among
    >> other things) on "slick" appearance and keyboard-only interaction.
    >> 
    >> There's a small chance they will enable the menu by default just
    >> because you asked
    >> 

    Emacs> If, and only if, Emacs adapts the appearance of the menu bar to the
    Emacs> chosen theme.  A boring gray oldish menu bar above a dark mode buffer
    Emacs> goes against "slick" appearance.

Which build of emacs are you using? Emacs+GTK on Gnu/Linux here
follows the theme set in the desktop environment for menus (the buffer
itself is still white on black, but thatʼs a different discussion).

Robert

Re: Changes for emacs 28

[Gregory Heytings via Emacs development discussions.]

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


>
>> If, and only if, Emacs adapts the appearance of the menu bar to the 
>> chosen theme.  A boring gray oldish menu bar above a dark mode buffer 
>> goes against "slick" appearance.
>
> Which build of emacs are you using? Emacs+GTK on Gnu/Linux here follows 
> the theme set in the desktop environment for menus (the buffer itself is 
> still white on black, but thatʼs a different discussion).
>

I did not mean "to the chosen desktop theme" but "to the chosen Emacs 
theme".  IOW, if it were possible for example for Doom Emacs to force the 
menu bar to have white text on a dark gray background.  That might be 
possible in fact, but I don't know how this could be done.  There is a 
`menu' face and a `tool-bar' face, but changing them does not seem to have 
any effect.

Re: Changes for emacs 28

[Robert Pluim]

>>>>> On Fri, 11 Sep 2020 14:10:22 +0000, Gregory Heytings <ghe@sdf.org> said:

    >> Which build of emacs are you using? Emacs+GTK on Gnu/Linux here
    >> follows the theme set in the desktop environment for menus (the
    >> buffer itself is still white on black, but thatʼs a different
    >> discussion).
    >> 

    Gregory> I did not mean "to the chosen desktop theme" but "to the chosen Emacs
    Gregory> theme".  IOW, if it were possible for example for Doom Emacs to force
    Gregory> the menu bar to have white text on a dark gray background.  That might
    Gregory> be possible in fact, but I don't know how this could be done.  There
    Gregory> is a `menu' face and a `tool-bar' face, but changing them does not
    Gregory> seem to have any effect.

I think the answer is going to be 'it depends on the platform and the
toolkit in use'.

Robert

Re: Changes for emacs 28

[Arthur Miller]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 11.09.2020 09:01, Eli Zaretskii wrote:
>> Disabling the menu bar and the tool bar, let alone doing that by
>> default, makes very little sense to me.  I'm running with both of them
>> enable, although I rarely if ever use them.
>
> Toolbar takes up space. We also reportedly have less than high quality icons in
> there, on some platforms more than others.
>
> The distros we're talking about usually pride themselves (among other things) on
> "slick" appearance and keyboard-only interaction.
>
> There's a small chance they will enable the menu by default just because you
> asked, but the toolbar is a lost cause.
Which distro does disable menus and toolbars in a text editor by
default? I don't even know of a distro that offers Emacs as a default
text editor. In some distros Emacs is only the "community effort", not
even packaged by distro developers. Anyway, if users choose such a
distro, which is not some of mainstream distros I guess, then they are
probably aware and experienced enough to sort out things for themselves
and enable Emacs gui if they wish, or they should be left to explore it
by themselves.

Re: Changes for emacs 28

[Göktuğ Kayaalp]

On 2020-09-11 13:36 +03, Arthur Miller <arthur.miller@live.com> wrote:
> Which distro does disable menus and toolbars in a text editor by
> default?

We’re talking about some canned configurations of Emacs, not OS
distributions.  Like Spacemacs, Doom Emacs, etc.  Some of these are
called distr{o,ibution}s, some ‘starter kits’.

These are more like Anaconda Python.  But yeah, the terms are a bit
confusing.

--
İ. Göktuğ Kayaalp / @cadadr / <https://www.gkayaalp.com/>
pgp:   024C 30DD 597D 142B 49AC 40EB 465C D949 B101 2427

Re: Changes for emacs 28

[Arthur Miller]

Göktuğ Kayaalp <self@gkayaalp.com> writes:

> On 2020-09-11 13:36 +03, Arthur Miller <arthur.miller@live.com> wrote:
>> Which distro does disable menus and toolbars in a text editor by
>> default?
>
> We’re talking about some canned configurations of Emacs, not OS
> distributions.  Like Spacemacs, Doom Emacs, etc.  Some of these are
> called distr{o,ibution}s, some ‘starter kits’.
Aha, ok; sorry, yes, I am aware of started kits, just never used any of
those :-). Anyway, I agree they should not disable gui elements by
default, that is definitely best left to the end user.

Re: Changes for emacs 28

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

  > We’re talking about some canned configurations of Emacs, not OS
  > distributions.  Like Spacemacs, Doom Emacs, etc.  Some of these are
  > called distr{o,ibution}s, some ‘starter kits’.

Please let's NOT use the term "distros" or "distributions" for these!
It is confusing.  Even if some others do use it, let's firmly not
follow them.

-- 
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: Changes for emacs 28

[Göktuğ Kayaalp]

On 2020-09-12 06:21 +03, Richard Stallman <rms@gnu.org> wrote:
> Please let's NOT use the term "distros" or "distributions" for these!
> It is confusing.  Even if some others do use it, let's firmly not
> follow them.

It looks like the term is fairly settled in the community, and what
studying linguistics has tought me is fighting that is an uphill battle,
optimistically speaking.  Not to mention just coining a new term would
only add to the confusion.

There is even a duality of terms: distribution and starter kit.  The
former seems to apply to larger, all encompassing, framework like
constructs, like Spacemacs and Doom; whereas starter kits are more like
nicer defaults and some popular packages, with less intervention as to
how user interacts with Emacs and configures it.


--
İ. Göktuğ Kayaalp / @cadadr / <https://www.gkayaalp.com/>
pgp:   024C 30DD 597D 142B 49AC 40EB 465C D949 B101 2427

Re: Changes for emacs 28

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

  > > Please let's NOT use the term "distros" or "distributions" for these!
  > > It is confusing.  Even if some others do use it, let's firmly not
  > > follow them.

  > It looks like the term is fairly settled in the community, and what
  > studying linguistics has tought me is fighting that is an uphill battle,
  > optimistically speaking.

They can say what they like, but _here_ please don't use the term
"distributions" except_ for operating system distributions.

We fight many uphill battles, because it is worth the trouble
to advance even if we don't "win" in a permanent sense.

-- 
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: Changes for emacs 28

[Dmitry Gutov]

On 11.09.2020 13:36, Arthur Miller wrote:
> Which distro does disable menus and toolbars in a text editor by
> default? I don't even know of a distro that offers Emacs as a default
> text editor.

This is about "Emacs distros" like Spacemacs, Doom and Prelude.

> In some distros Emacs is only the "community effort", not
> even packaged by distro developers. Anyway, if users choose such a
> distro, which is not some of mainstream distros I guess, then they are
> probably aware and experienced enough to sort out things for themselves
> and enable Emacs gui if they wish, or they should be left to explore it
> by themselves.

I tend to agree. But all popular "Emacs distros" do that. So there's 
really not much alternative for users who would like something different 
than the "vanilla" experience.

RE: Changes for emacs 28

[Drew Adams]

> > Disabling the menu bar and the tool bar, let alone doing that by
> > default, makes very little sense to me.  I'm running with both of them
> > enable, although I rarely if ever use them.
> 
> Toolbar takes up space. We also reportedly have less than high quality
> icons in there, on some platforms more than others.
> 
> The distros we're talking about usually pride themselves (among other
> things) on "slick" appearance and keyboard-only interaction.
> 
> There's a small chance they will enable the menu by default just because
> you asked, but the toolbar is a lost cause.

See my reply about `tool-bar-pop-up-mode'.
Show the tool-bar only when you want, for
one-off uses.

RE: Changes for emacs 28

[Drew Adams]

> > How hard is it to find this submenu?
> >
> > `Options' >
> >     `Show/Hide' >
> >       `Line Numbers for All Lines'
> 
> By CUA, Show/Hide should be a top-level menu named View. 

Really?  Even for setting persistent preferences?
I can imagine using `View' for changing something
for the time being, but not necessarily for
setting preferences (persistent configuration).

`Options' provides both behaviors.

[Some apps have an `Options' menu that stuff for
non-persistent changes and a `Preferences' submenu
for persisitent changes (configuration).]

> Someone who is (subconsciously) familiar with that
> convention will not think to look in Options.

I, like everyone, use lots of apps.  I have no idea
which (if any) follow the CUA convention (nor do I
care).

Some of them have `View' menus (not always top-level).
And some of them have `Preferences' or `Options' menus,
sometimes as a submenu under `File', `Edit', or `Tools'.

Different apps do things differently.  I really
don't think it's hard to find the ability to turn
line-number display on/off, either temporarily or
persistently, even for someone who might be looking
for it under a nonexistent `View' menu.  Do you?

Not difficult, that is, provide the menu-bar is shown.

Re: Changes for emacs 28

[Yuri Khan]

On Fri, 11 Sep 2020 at 01:44, Drew Adams <drew.adams@oracle.com> wrote:

> > By CUA, Show/Hide should be a top-level menu named View.
>
> Really?  Even for setting persistent preferences?
> I can imagine using `View' for changing something
> for the time being, but not necessarily for
> setting preferences (persistent configuration).

Yes. In many applications, View is the place to go if you want to
toggle any optional UI parts (toolbars, sidebars, sometimes menu bar).
These toggles are usually persisted immediately.

It would be nice if the CUA specification was available somewhere on
the Web. Unfortunately, Wikipedia only links to an incomplete Wayback
Machine mirror that does not have the page on the View menu, so I
can’t quote from there.

Re: Changes for emacs 28

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

  > It would be nice if the CUA specification was available somewhere on
  > the Web. Unfortunately, Wikipedia only links to an incomplete Wayback
  > Machine mirror that does not have the page on the View menu, so I
  > can’t quote from there.

Do any developers these days try to follow the CUA spec?
If so, they must get it from somewhere.

If developers these days don't try to follow it,
why do any users expect us (or anyone) to follow 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: Changes for emacs 28

[Yuri Khan]

On Fri, 11 Sep 2020 at 11:16, Richard Stallman <rms@gnu.org> wrote:

>   > It would be nice if the CUA specification was available somewhere on
>   > the Web. Unfortunately, Wikipedia only links to an incomplete Wayback
>   > Machine mirror that does not have the page on the View menu, so I
>   > can’t quote from there.
>
> Do any developers these days try to follow the CUA spec?
> If so, they must get it from somewhere.
>
> If developers these days don't try to follow it,
> why do any users expect us (or anyone) to follow it?

Developers follow the guidelines of their respective GUI toolkit, OS
or desktop environment. Which are many and somewhat diverse, but, in
the end, most of them ultimately descend from CUA.

Re: Changes for emacs 28

[Eli Zaretskii]

> From: Yuri Khan <yuri.v.khan@gmail.com>
> Date: Fri, 11 Sep 2020 02:34:47 +0700
> Cc: Göktuğ Kayaalp <self@gkayaalp.com>,
>  Gregory Heytings <ghe@sdf.org>, Yuan Fu <casouri@gmail.com>,
>  TEC <tecosaur@gmail.com>, Emacs developers <emacs-devel@gnu.org>
> 
> On Fri, 11 Sep 2020 at 01:44, Drew Adams <drew.adams@oracle.com> wrote:
> 
> > > By CUA, Show/Hide should be a top-level menu named View.
> >
> > Really?  Even for setting persistent preferences?
> > I can imagine using `View' for changing something
> > for the time being, but not necessarily for
> > setting preferences (persistent configuration).
> 
> Yes. In many applications, View is the place to go if you want to
> toggle any optional UI parts (toolbars, sidebars, sometimes menu bar).
> These toggles are usually persisted immediately.
> 
> It would be nice if the CUA specification was available somewhere on
> the Web.

It doesn't really matter, because whatever any specification says, we
don't blindly follow it, we treat such specifications as
recommendations, and fit them to what we think is best for Emacs and
the GNU Project.

(Needless to say, when the current menu arrangement was discussed, we
took into considerations user expectations and what other applications
do with their menus.)

Re: Changes for emacs 28

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

  > By CUA, Show/Hide should be a top-level menu named View. Someone who
  > is (subconsciously) familiar with that convention will not think to
  > look in Options.

1. The difficulty is that some moides are running out of space in the
menu bar,  Adding a View menu WOULD screw some users.

2. Someone who won't try each menu to see what is in it
seems to be dispose to lose.

-- 
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: Changes for emacs 28

[Juri Linkov]

> A Mastodon (or equivalent) instance for Emacs?  A lot of Emacs users
> there already.

I recommend a Pleroma instance: easier to maintain and requires less resources.

> There’s an Emacs client, mastodon.el, which is nice but has some
> polishing to be done.  Haven’t used it much tho.

mastodon.el can be used for Pleroma because Pleroma supports Mastodon API.

Re: Changes for emacs 28

[tomas]

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

On Thu, Sep 10, 2020 at 12:45:18AM +0800, TEC wrote:

[...]

> Vim of course also lacks a splash screen

You never started vim without a file name argument, did you?

;-)

Cheers
 - t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Changes for emacs 28

[Howard Melman]

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

TEC <tecosaur@gmail.com> writes:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>>> - Tried to execute a command interactively (forget which command)
>>>   + Typed M-x
>>>   + Wait, this is just a text box
>>>   + I don't know commands off by heart!
>>>   + I want to be able to type key terms and see options!
>>
>> How much of this would be satisfied by icomplete-mode together with the
>> `substring` completion-style (which would be a smaller change to
>> the UI than something like helm-M-x or counsel-M-x).
>
> I'm frankly not sure. Just trying icomplete now for the first time the
> horizontal display of options seems a bit odd to my sensibilities.

FWIW and for those that might not know, this is how
counsel-M-x looks for me:


[-- Attachment #2: Screen Shot 2020-09-09 at 5.24.08 PM.png --]
[-- Type: image/png, Size: 175014 bytes --]

[-- Attachment #3: Type: text/plain, Size: 275 bytes --]


The short description and the keybindings are quite useful.
Even after 30 years of using emacs, there are so many new
packages and features I'm always learning more, and these
help a lot.

I get similar displays using describe-function,
describe-variable, etc.

-- 

Howard

RE: Changes for emacs 28

[Drew Adams]

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

> FWIW ... this is how counsel-M-x looks for me

FWIW, attached is how it looks with Icicles.

First line of current candidate's doc string is shown in
mode line temporarily.  (Hit a key to see its full doc.)

Otherwise, mode-line shows:

* Number of matching candidates (51, in this case).
* Current completion method (vanilla, in this case).
* Current sort order (alphabetical, in this case).

`Icy' lighter in mode-line indicates:

* Must-match completion, not lax (blue bars).
* Case-sensitive completion (`ICY' for insensitive).
* Multi-command (`+'): can act on multiple candidates.

[-- Attachment #2: throw-M-x-find.png --]
[-- Type: image/png, Size: 84920 bytes --]

Re: Changes for emacs 28

[Ricardo Wurmus]

TEC <tecosaur@gmail.com> writes:

> So the 'issue' here isn't a direct "this doesn't look good so I won't
> use this" but a case of association. When I see the vanilla Emacs splash
> screen I'm reminded of the *worst* editors I have experienced, which is
> (as we both know) completely inaccurate, but first impressions are
> coloured by a myriad of factors.
>
> Vim of course also lacks a splash screen, but it's also known as a
> terminal-exclusive editor. I know I tend to set different expectations
> TUIs and GUIs, so I'd imagine I'd find this less of a subconscious
> red-flag.

This is something I have seen in other people who wanted to learn Emacs
after they saw me use it and heard me evangelize… When they get started
with vanilla Emacs they see something that looks like it’s going to be a
lot of work to make it work well for them.

Many of them do know of Vim, if only for the fact that they don’t know
how to exit it.  (They realize then that they also don’t know how to
exit Emacs.)  They remember that Vim requires a lot of work to make it
do things that it doesn’t do out of the box, and they fear they’ll have
to do the same with Emacs.

At that point their initial enthusiasm has all but disappeared and they
glance over to their colleagues who use Rstudio or Atom (in 2017) or
that proprietary editor Sublime.  Everything seems so easy and
approachable and just as extensible.  They see their colleague use Git
from within Rstudio and wonder if they’d ever get to that point if they
will first have to configure Emacs to do all the basic things first.

When I started to use Emacs (after the third serious attempt switching
from vim) I had lots of time on my hands — literally, because I had just
decided to learn touch typing with Dvorak.  Everything was uncomfortable
and new, so the pain of learning Emacs and making Emacs learn about me
disappeared in an ocean of unrelated discomfort.  This situation doesn’t
seem to be very common in those that are curious about Emacs.

-- 
Ricardo

Re: Changes for emacs 28

[Göktuğ Kayaalp]

On 2020-09-10 14:20 +03, Ricardo Wurmus <rekado@elephly.net> wrote:
> At that point their initial enthusiasm has all but disappeared and they
> glance over to their colleagues who use Rstudio or Atom (in 2017) or
> that proprietary editor Sublime.  Everything seems so easy and
> approachable and just as extensible.  They see their colleague use Git
> from within Rstudio and wonder if they’d ever get to that point if they
> will first have to configure Emacs to do all the basic things first.

IMO we should draw a line between attracting users into a detrimental
experience for them and making Emacs more approachable.  Rstudio is a
_great_ fundamental project, and if the rest of my life wasn’t inside
Emacs, I’d be using it these days as I’m studying R.  Org mode is better
than Rmarkdown in certain respects, but if it’s just ‘do statistics in a
nice environment’, I’d definitely recommend Rstudio over Emacs (or
anything else, for that matter).  There’s no way Emacs will ever be as
good at that particular task set, especially if that’s the only task set
one will need it for.

--
İ. Göktuğ Kayaalp / @cadadr / <https://www.gkayaalp.com/>
pgp:   024C 30DD 597D 142B 49AC 40EB 465C D949 B101 2427

Re: Changes for emacs 28

[Ricardo Wurmus]

Göktuğ Kayaalp <self@gkayaalp.com> writes:

> On 2020-09-10 14:20 +03, Ricardo Wurmus <rekado@elephly.net> wrote:
>> At that point their initial enthusiasm has all but disappeared and they
>> glance over to their colleagues who use Rstudio or Atom (in 2017) or
>> that proprietary editor Sublime.  Everything seems so easy and
>> approachable and just as extensible.  They see their colleague use Git
>> from within Rstudio and wonder if they’d ever get to that point if they
>> will first have to configure Emacs to do all the basic things first.
>
> IMO we should draw a line between attracting users into a detrimental
> experience for them and making Emacs more approachable.  Rstudio is a
> _great_ fundamental project, and if the rest of my life wasn’t inside
> Emacs, I’d be using it these days as I’m studying R.  Org mode is better
> than Rmarkdown in certain respects, but if it’s just ‘do statistics in a
> nice environment’, I’d definitely recommend Rstudio over Emacs (or
> anything else, for that matter).  There’s no way Emacs will ever be as
> good at that particular task set, especially if that’s the only task set
> one will need it for.

In my work environment R is essential, but it’s not nearly the only
thing people have to use regularly.  A lot of work is done in Python and
with Jupyter, and RStudio is almost useless for those tasks.  There’s
also a lot of command line drudgery that could be done more conveniently
with “M-x shell” (editing the output of a tool directly), etc.

So there is a palpable desire for better tools to avoid the constant
context switching, but for every task people end up on the hill of a
local maximum, unable to reach something better (presumably Emacs),
because it doesn’t seem worth the effort to climb that mountain if you
first need to descend into the valley of inscrutable configuration.

-- 
Ricardo

Re: Changes for emacs 28

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

  > At that point their initial enthusiasm has all but disappeared and they
  > glance over to their colleagues who use Rstudio or Atom (in 2017) or
  > that proprietary editor Sublime.  Everything seems so easy and
  > approachable and just as extensible.  They see their colleague use Git
  > from within Rstudio and wonder if they’d ever get to that point if they
  > will first have to configure Emacs to do all the basic things first.

The tone of that text seems harsh -- it feels like venting hostility.
Would you like to make some constructive suggestions?

-- 
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: Changes for emacs 28

[Ricardo Wurmus]

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. ]]]
>
>   > At that point their initial enthusiasm has all but disappeared and they
>   > glance over to their colleagues who use Rstudio or Atom (in 2017) or
>   > that proprietary editor Sublime.  Everything seems so easy and
>   > approachable and just as extensible.  They see their colleague use Git
>   > from within Rstudio and wonder if they’d ever get to that point if they
>   > will first have to configure Emacs to do all the basic things first.
>
> The tone of that text seems harsh -- it feels like venting hostility.
> Would you like to make some constructive suggestions?

This is certainly not meant to come across as harsh.  It is a
description of what I have observed dozens of times while watching
people who had initial enthusiasm to try out Emacs, only to realize that
it requires much more time to get started than they imagined.  At that
point they have mentally moved on and are already on the lookout for
something else that gets them close to what they had been looking for
initially — even if that falls short of what they could have reached
with Emacs.

I agree with what others have pointed out earlier, namely that a lack of
pre-configuration of features such as automatic completion as you type
and more helpful matching and suggestion of inputs at dreaded empty
prompts would go a long way to reduce what is seen as an intimidating
amount of configuration that users would have to perform for features
that are readily available in most editors and IDEs (and of course
Emacs, once configured).

This drop in initial enthusiasm and motivation is real and closely
linked to defaults.  It is also why I shifted to recommend Spacemacs
(for people familiar with Vim) or Doom Emacs (for all others), because
people can dive right into the interesting stuff without getting bogged
down at the worst time: while learning something that is completely
foreign to them.

-- 
Ricardo

Re: Changes for emacs 28

[TEC]

Hi Ricardo,

In your reply I found something that I think really sums up my experience well.

Ricardo Wurmus <rekado@elephly.net> writes:
> [Doom and Spacemacs are good] because
> people can dive right into the interesting stuff without getting bogged
> down at the worst time: while learning something that is completely
> foreign to them.

For me, and for others, I feel that this is the crux of the matter.
All my comments about Doom's modules allowing me to 'just get started'
are in this vein, as are completion, linting, etc.

I think Emacs is tremendous (no surprise to anyone reading this 😛,
I'm sure). However, I fear that there are many  people who /would/
discover how brilliant Emacs is ... were it not for this initial hurdle.

I think there are essentially three categories of changes we'd likely
want in trying to make Emacs less off-putting:
 1. Look - theme, splash screen, etc.
 2. Feel - completion, linting, etc.
 3. Defaults - changes to functionality already present, e.g. setting
    utf8 at the default text encoding

I hear those long-time users who have years to decades of configuration
built on Emacs' current behaviour, I appreciate your need for Emacs'
behaviour to stay consistent.

I can't see any simple solution which I imagine makes both long-time
users, and 'just seeing what this is' newcomers happy --- but that
doesn't mean there isn't a way forward.

* Some potential avenues to investigate:

The most promising idea I've heard is to come up with a clean, and
elegant way to allow for users to easily select from/combine different
Emacs experiences.

Profiles are a nice idea I think. They sound good for easily selecting
from a selection of 'presets', but perhaps aren't so good when it comes
when use cases blur (as they often do) and one wants to combine
functionality.

Modules are a nicer approach in this respect, in that you partition
common/related functionality into discrete bundles that can be used (or
not) as one wishes.

Another approach may be to essentially delegate this to 'downstream
distributions' like Doom or Spacemacs, by making them trivially easy for
the user to chose to use --- as opposed to having them be something that
the user has to independently discover/investigate/install.

The reason I suggest this is because:
 - a lot of commonly used packages which help shape Emacs into what I
   consider a more approachable UX are only in MELPA
 - these packages seem to generally be frequently updated, and I fear
   that baking them into Emacs will result in a bifurcation of
   versions/features/development. This also opens up the annoyance
   backporting bug fixes etc.

That said, I for some 'key' aspects of functionality like code
completion, I feel that it would make sense to have something like
Company baked into Emacs.

Hopefully this can provide some food for thought,

Timothy.

Re: Changes for emacs 28

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

  > I think there are essentially three categories of changes we'd likely
  > want in trying to make Emacs less off-putting:
  >  1. Look - theme, splash screen, etc.

How about if you to discuss with some interested people
which specific changes to propose?

  >  2. Feel - completion, linting, etc.

I think that turning some of these things on by default would not annoy
old users who don't want them.  We would only need to disable them once.
As long as disabling them is easy and straightforward, that is.

  >  3. Defaults - changes to functionality already present, e.g. setting
  >     utf8 at the default text encoding

Some of these might be good for everyone.  For those that aren't, I
think it would be enough to provide a function to call to switch to
the old defaults.

  > * Some potential avenues to investigate:

  > The most promising idea I've heard is to come up with a clean, and
  > elegant way to allow for users to easily select from/combine different
  > Emacs experiences.

  > Profiles are a nice idea I think. They sound good for easily selecting
  > from a selection of 'presets', but perhaps aren't so good when it comes
  > when use cases blur (as they often do) and one wants to combine
  > functionality.

Maybe -- but first how about trying the simpler approach described
above, and seeing how far it can go?


-- 
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: Changes for emacs 28

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

  > This is certainly not meant to come across as harsh.

I believe you.  I am sorry if my message sounded like criticism of
you.

                                                          It is a
  > description of what I have observed dozens of times while watching
  > people who had initial enthusiasm to try out Emacs, only to realize that
  > it requires much more time to get started than they imagined.

Now I understand.  There was hostility in those words, but it was not
your hostility.  You were describing the reactions of various others,
and what they were doing was venting their hostility.  You portrayed
that hostility and it came through and hit me in the face.

What you observed is an important fact, and reporting it was
potentially very useful.  But please, in the future, avoid repeating
the actual words with which they express hostility.  That is not the
part that can be helpful for Emacs development.

  > I agree with what others have pointed out earlier, namely that a lack of
  > pre-configuration of features such as automatic completion as you type
  > and more helpful matching and suggestion of inputs at dreaded empty
  > prompts would go a long way to reduce what is seen as an intimidating
  > amount of configuration that users would have to perform for features
  > that are readily available in most editors and IDEs (and of course
  > Emacs, once configured).

I think we're convinced of this, in general.




-- 
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: Changes for emacs 28

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

  > This is a tricky thing. You see, I don't think it's inherently bad.
  > However, for me at least, most of the editors I've used have had a good
  > degree of 'visual polish' and 'modern snazziness' that Vanilla Emacs
  > currently lacks.

I have no idea what looks "good" or "bad" in a splash screen; it never
occurs to me to judge such a question.  Do you have any idea where
to get objective advice about what users will judge as "good"?

It might be easy to implement such advice if we had 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: Changes for emacs 28

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

  > ;; This determines the style of line numbers in effect. If set to `nil', line
  > ;; numbers are disabled. For relative line numbers, set this to `relative'.
  > (setq display-line-numbers-type t)

The default for this should depend on the screen width!

Maybe most young people make wide Emacs frames, since modern laptop
screens are lengthwise and width foolish. but PLEASE do not propose
defaults that cater to ONLY to one kind of usage.  DTRT for multiple
kinds!

-- 
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: Changes for emacs 28

[Ergus]

On Wed, Sep 09, 2020 at 12:05:54PM -0400, Stefan Monnier wrote:
>Thanks, TEC, I found it quite useful.  Further comments and questions below.
>
>> * Org-mode, my ramp into Emacs pt.1 - vanilla
>> - I'd heard about Org-mode as a thing markdown + execution
>> - Maybe this could be better than Jupyter?
>> - However... I didn't like Spacemacs
>> - Removed Spacemacs
>> - Typed 'emacs' into a terminal
>
>So far so good.
>
>> - Oh, this looks old.
>
>Fair enough.  I don't think we (Emacs community) are in a position to
>make it look "modern" and sexy.  I know I'm not because my notion of
>"modern and sexy" is quite outmoded ;-)
>
>But "looks old" is usually not a deal breaker, just a negative
>first impression.
>
Actually spacemacs made it to look a bit more modern by just changing
some colors.

>> - Successfully opened a file
>>   + Where are the line numbers?
>
>Interesting.  It would never occur to me to expect line numbers in
>a text editor.  When and why did line numbers become fashionable?
>[ My guess is something like "ever since shortscreens became the only
>  option, creating a void in the horizontal space that needed
>  filling" ;-) ]
>
>I don't oppose enabling line numbers by default, but I do find line
>numbers to be an awful waste of valuable screen real estate.
>
I use line numbers, but instead of enabling them by default we could
make it very very accessible in the toolbar or initial config dialog.

>>   + Why aren't I given much information on the file
>
>Could you be more specific in terms of the particular information that
>you felt Emacs failed to give (and maybe how you expected it to be given)?
>
>>   + Where's the completion, the linting, etc.
>
>Do I understand you right that you expected company+eglot+flymake to be
>enabled (and configured) by default?
>
>I personally find this to be the most glaring concrete problem in
>Emacs nowadays.
>
Again we just don't need to enable them by default, but just make them
easier to config. I still find myself in the dichotomy between company
or auto-complete modes after 6 years in emacs.

flymake is good enough, but not very easy to find on the beginning, and
it still requires a lot of work. Also most of the documentation around
recommends using flycheck and actually for me it works much better in
most of the situations and languages I use.

>> - Tried to execute a command interactively (forget which command)
>>   + Typed M-x
>>   + Wait, this is just a text box
>>   + I don't know commands off by heart!
>>   + I want to be able to type key terms and see options!
>
>How much of this would be satisfied by icomplete-mode together with the
>`substring` completion-style (which would be a smaller change to
>the UI than something like helm-M-x or counsel-M-x).
>
Yes please.. If you think that icomplete/fido-mode can be improved
somehow, just make specific requests.

>> - Having an initialisation† file, well commented such that *without knowing
>>   anything about Emacs* I could have Emacs be set up such that I could
>>   actually try it with familiar tasks and not be underwhelmed, or have
>>   to deal with sudden troubleshooting
>
>Maybe we could have a "default init file" (consisting of nothing but
>commented out code snippets, accompanied by actual comments explaining
>them)?
>
This is why I have been asking for use-package integration. As a
starting point this is the easier we can provide to starters to
find/know about the different options and modes.

>>   †The important bit about this file is that it let me declare which
>>   bundles of functionality I want easily, and without having to parse
>>   much unfamiliar lisp (both Spacemacs and Vanilla fail in this regard,
>>   but in different ways).
>
>Hmm... a "default init file" would still use "unfamiliar Lisp", I'm afraid.
>
with use-packages the lisp knowledge needed to configure is
minimal. Just to understand (this detail)

>> - Having good 'discoverability enhancements' used by default
>>   - counsel for M-x
>
>IIUC this is similar to enabling icomplete-vertical and
>icomplete-show-matches-on-no-input, and maybe using a regexp
>completion style?
>
There is not icomplete-vertical yet ;).

Any way icomplete is too far to compete with counsel/ivy/swiper in
functionality and termination level.  (at the moment icomplete is Donald
Duck and counsel is James Bond).

I don't ask to add counsel to vanilla because it requires many external
optional dependencies that I would never like to see in vanilla and
retards the startup time.

>> - Used Discord for it's community, a recent chat-app which I recognised
>>   (I'm still warming up to mailing lists).
>
>Definitely a non-starter since it's proprietary.
>There are obviously acceptable alternatives.
>
>I think an important aspect is to find a communication medium that can
>be used from Emacs.  IRC and Email do satisfy this criteria.
>Whenever I have to write text outside Emacs I feel hampered.
>
>
Emacs has even a telegram client, jabber client, and IRC... so of course
any method we use to communicate must have an emacs client, a web or
desktop client and a mobile client.



>        Stefan
>
>

Re: Changes for emacs 28

[Gregory Heytings via Emacs development discussions.]

Ergus:
>
> There is not icomplete-vertical yet ;).
>

Of course there is: https://github.com/oantolin/icomplete-vertical .

Re: Changes for emacs 28

[Ergus]

On Wed, Sep 09, 2020 at 05:08:05PM +0000, Gregory Heytings via Emacs development discussions. wrote:
>
>Ergus:
>>
>>There is not icomplete-vertical yet ;).
>>
>
>Of course there is: https://github.com/oantolin/icomplete-vertical .
>

That's an external package not even in elpa and it has some issues. We
have been talking to add it to internal icomplete and finally there is a
feature branch with the WIP.

RE: Changes for emacs 28

[Drew Adams]

> I use line numbers, but instead of enabling them by default we could
> make it very very accessible in the toolbar or initial config dialog.

Menu Options >
  Show/Hide >
    Line Numbers for All Lines (submenu)

(And yes, the menu-bar needs to be shown initially,
i.e., by default.)

> with use-packages the lisp knowledge needed to configure
> is minimal. Just to understand (this detail)

Maybe so, but I see _lots_ of questions posted that
come from not understanding the syntax, or rather
the behavior of certain bits of the syntax.

Some of that is not understanding Lisp, I think.
Most of it is not, perhaps.

Re: Changes for emacs 28

[Caio Henrique]

>I use line numbers, but instead of enabling them by default we could
>make it very very accessible in the toolbar or initial config dialog.
On the menu-bar, one can go into [Options] -> [Show/Hide] -> [Line numbers
for all lines].

Related to this: I can't find where is redo (undo-redo) on the
menu-bar, so I suppose that it isn't there. Maybe it should be included?
(I'm not sure how useful it is since I use undo-tree).


Caio Henrique

Re: Changes for emacs 28

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

  > IMO the most significant factor is that Doom allowed me to "just get
  > started" with the tasks which caused my lingering interest to manifest
  > into installing. While now I couldn't imagine going without Emacs, that
  > initial ease was crucial.

That describes how it felt, subjectively, to you.
That's a consequence of some concrete things about DOOM,
I am sure -- but I have no idea what those concrete things _are_.

Can you describe even a few of the concrete differences of DOOM that
made it so easy for you?  I suggest not aiming for completeness,
but rather mentioning the ones that are most important.

That would be the information we might perhaps draw concrete lessons
from.

  > IMO the most significant factor is that Doom allowed me to "just get
  > started" with the tasks

Could you describe a few of those tasks, and what would have been
hard about them, which DOOM made easier?

I'm also curious about how why you decided to change from DOOM
to standard Emacs?

-- 
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: Changes for emacs 28

[TEC]

Richard Stallman <rms@gnu.org> writes:

> That describes how it felt, subjectively, to you.
> That's a consequence of some concrete things about DOOM,
> I am sure -- but I have no idea what those concrete things _are_.

I appreciate the difficulty.
Unfortunately, as you point out this is a single subjective impression
of qualitative factors that are generally hard to pin down.
I welcome any attempt to corral my jumbled thoughts into something
actually useful, and will try my best to communicate which factors had
the most impact on my experience :)

> Can you describe even a few of the concrete differences of DOOM that
> made it so easy for you?  I suggest not aiming for completeness,
> but rather mentioning the ones that are most important.
>
> That would be the information we might perhaps draw concrete lessons
> from.
>
>   > IMO the most significant factor is that Doom allowed me to "just get
>   > started" with the tasks
>
> Could you describe a few of those tasks, and what would have been
> hard about them, which DOOM made easier?

So, the task that got me started was using R, notebook style
 --- i.e. R + Org.

This is what the process was like with Doom:
 - run the one-line install script
 - opening the config dir is prominently listed (with the associated
   keybinding) on the 'home'/init/welcome buffer
 - I find three files, well commented, describing what they are and what
   to do with them
 - I see ESS listed in init.el as a 'statistics' module under :lang
   C-c c k pulls up the documentation on it (as I am told by comments at
   the start of the file) and I see that it does indeed add support for
   R. I uncomment the line and run 'doom refresh'
 - Excluding install time, I think this took me ~5 minutes

At this point I have:
 - Support for R
 - Completion via Company
 - Linting via Flycheck
 - A fuzzy searcher for commands I don't know with Ivy
 - When I pause on keybindings (what was that next part?)
   which-key pops up.
 - An editor that appeals to my 'flashy modern' sensibles
   + A UI/theme more inline with Atom/VS Code/etc.
   + Git status gutters
   + A modeline that tells me nice stuff like

To get here all I needed to know is that I wanted to use R,
notebook-style with Org, hoping to see the 'editor features' that I
missed in JupyterLab.

In order to get to this same point with Vanilla emacs I'd need to:
 - Identify ESS as the package for R (quick search online)
 - Work out how to install packages
   + come across conflicting answers on the web. use-package? straight?
     package-install?
 - I'd try an R block in org, and get told:
   "No org-babel-execute function for R!"
   + what's this? how do I fix it?
 - Once I get that working - where's the completion I was hoping for?
   + another internet trip...
 - Etc.

Unfortunately I can't imagine this taking a comparable length of time,
or being nearly as easy.

I'm not sure that Emacs can embrace the behaviours that people who have
primarily experienced the likes of VS Code/Atom/JetBrains/Sublime/etc.
will be looking for, without compromising the experience that long-time
users have come to expect. Perhaps the way forward may be to treat
standard Emacs as a core and prominently offer 'distributions' of Emacs?

Possibly the best thing about Emacs IMO is its versatility. I suspect
that trying to be all things to all people could be a futile task,
but maybe Emacs can lean into this and say to a new user:
 - if you're looking to use Emacs like X, here you go
 - looking for Y instead? Then just use/do this
 - actually want Z? Here's that option...

This seems like something where some selection of:
 - modules
 - profiles
 - embracing distributions

could improve the situation.

Anyway, that's just my thoughts. Hopefully they're of some interest.

> I'm also curious about how why you decided to change from DOOM
> to standard Emacs?

Erm. I haven't switched from Doom to standard Emacs. Apologies if I
incorrectly implied that somewhere.
My journey was (excluding pre-emacs):
  Spacemacs (for a brief period) → Vanilla (for mere hours) → Doom

[aside: why I'm still on doom, http://ix.io/2wUw]

I feel that for the purposes of this discussion, it would have been nice
if I'd spent longer trying to get vanilla/standard Emacs working --- but
I didn't. However I'll still offer what I can in the hope that it may be
useful.

All the best,

Timothy.

Re: Changes for emacs 28

[Göktuğ Kayaalp]

On 2020-09-09 09:26 +03, TEC <tecosaur@gmail.com> wrote:
[...]
> Unfortunately I can't imagine this taking a comparable length of time,
> or being nearly as easy.

I think experiences like this highlight two major clusters among Emacs
users: those who come to Emacs for Emacs, and those whow are attracted
to it because it has Org mode (or sth. else, but it seems to be Org mode
most of the time).

Those who come to Emacs for Emacs are mainly here because they
appreciate how Emacs caters to their need for an extensible,
customisable system which they can use to build up a computing
environment that’s tailor-made for their needs.  I fall within this
category.  I started with a blank init.el some 6 years ago.  When I
found Org mode or ESS or Elfeed or whatnot, it was because I was
actively looking for how to do the relevant thing in Emacs, because I
assumed that doing it in Emacs would allow me to sculpt the experience
to my liking, fine tune everything, and tie things nicely together.

Those who come to Emacs for Org mode, mu4e, or maybe something else
(I’ll just say Org mode from here on; assume a dangling ‘or maybe
something else’ for each instance), are fundamentally different.  You
fall into this category.  I of course can’t know your particular
experience, but what I deduce from reading /r/emacs to this day is this
kind of user generally finds out about Emacs as the thing that hosts Org
mode.  They are mainly interested in Org mode and some related
features.  They won’t find out about what users like me think are the
main virtues of Emacs until later, and they won’t find out about how
Emacs is traditionally used, customised, until even later.

There maybe is a third kind of user who thinks of it just another text
editor with some programming support, but I won’t risk more detailed
assumptions for this hypothetical category.

But, what I’ve described above is IMO something that’ll render itself
pretty obvious e.g. if you go to /r/emacs and read it for a week or two.

> I'm not sure that Emacs can embrace the behaviours that people who have
> primarily experienced the likes of VS Code/Atom/JetBrains/Sublime/etc.
> will be looking for, without compromising the experience that long-time
> users have come to expect. Perhaps the way forward may be to treat
> standard Emacs as a core and prominently offer 'distributions' of Emacs?

If what I said above is indeed relevant and truthy, it might be a nice
basis for introducing people to Emacs (the term ‘marketing’ is really
ugly, IMHO simply means ‘to deceive into thinking, with greedy malice’)
and proves, along with your experience that you document in your OP, how
useful could distributions be to cater to this particular category of
users, without compromising others.

I’d say we should leave distributions to the community, support them and
maybe ‘bless’ the projects that are willing as GNU projects, and make
sure that <gnu.org/s/emacs> and <orgmode.org> are displaying to the
users what’s available, possibly with some video introductions for each
which briefly introduce and overview the thing, and also some for a
variety of common use cases.

--
İ. Göktuğ Kayaalp / @cadadr / <https://www.gkayaalp.com/>
pgp:   024C 30DD 597D 142B 49AC 40EB 465C D949 B101 2427

Re: Changes for emacs 28

[Boruch Baum]

On Tue, 08 Sep 2020 13:50:37 +0100, João Távora wrote:
> Boruch Baum <boruch_baum@gmx.com> writes:
>
> > On Tue, 08 Sep 2020 12:13:04 +0100, João Távora wrote:
> >> It must be a command-line option because when reproducing and fixing
> >> bugs on Emacs, you very frequently have the need to run "a bare Emacs
> >> -Q" frequently from a shell, devoid of any third-party packages that may
> >> be interfering.
> >
> > That's only ever is true when reporting a bug to the emacs project
> > itself.
>
> No, no and no. When answering bug reports for a package that is _not_
> in Emacs it's imperative that the reporter uses Emacs -Q + <package
> setup when explaining the problem.

You're right. I'm surprised I wrote that part.

--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

Re: Changes for emacs 28

[Boruch Baum]

On Tue, 08 Sep 2020 12:13:04 +0100, João Távora wrote:

> Richard Stallman <rms@gnu.org> writes:
> > I like the idea, but this should be something to set in .emacs,
> > not a command-line option.
>
> It must be a command-line option because when reproducing and fixing
> bugs on Emacs, you very frequently have the need to run "a bare Emacs
> -Q" frequently from a shell, devoid of any third-party packages that may
> be interfering.

That's only ever is true when reporting a bug to the emacs project
itself. Should your proposal be adopted as an add-on loaded via .emacs
as Richard Stallman suggests, it can be treated like any of the other
zillion emacs third-party packages that are competently and
professionally debugged by their own authors and maintainers, without
imposing extra burdens on the maintainers of the core emacs project.

I do think it would be great for emacs to include a curated collection
of sample init files descriptively labeled for use-case. I would go
further and suggest that the technique of using an org-mode file with
embedded code blocks as one's emacs init file be adopted as standard,
and be used for those collection of init files. That way each code block
can be explained and annotated to 'new' users.

--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

Re: Changes for emacs 28

[João Távora]

Boruch Baum <boruch_baum@gmx.com> writes:

> On Tue, 08 Sep 2020 12:13:04 +0100, João Távora wrote:
>> Richard Stallman <rms@gnu.org> writes:
>> > I like the idea, but this should be something to set in .emacs,
>> > not a command-line option.
>>
>> It must be a command-line option because when reproducing and fixing
>> bugs on Emacs, you very frequently have the need to run "a bare Emacs
>> -Q" frequently from a shell, devoid of any third-party packages that may
>> be interfering.
>
> That's only ever is true when reporting a bug to the emacs project
> itself.

No, no and no.  When answering bug reports for a package that is _not_
in Emacs it's imperative that the reporter uses Emacs -Q + <package
setup> when explaining the problem.

I really feel I must stress this, since I've come across so many bad
frustrating and time-consuming bug reports in this aspect in last 15
years (Yasnippet, SLY, Eglot, many others).  The frustration is not only
mine, it's also the reporter's, who frequently isn't even aware of the
underlying Emacs they they are using inside Doom, or even that there is
variation of it that is not souped up with a million packages.

Unless explicited otherwise, authors develop packages to work with
Emacs, not with other packages they are not aware of.  Personally, I
will go to some effort (but not an infinite amount) to help the user
track down the problem even in tandem with other packages not in Emacs.
But the initial report really must contain the perfectly reproducible
starting conditions.  Emacs -Q is an invaluable tool for that.  Every
user must never be made to forget it, no matter what Doom, Space, or
Cauliflower distribution they use.

João

RE: Changes for emacs 28

[Drew Adams]

> When answering bug reports for a package that is _not_
> in Emacs it's imperative that the reporter uses Emacs -Q + <package
> setup> when explaining the problem.

+1

(Helps, anyway.)

Re: Changes for emacs 28

[Robert Pluim]

>>>>> On Tue, 8 Sep 2020 07:52:02 -0400, Boruch Baum <boruch_baum@gmx.com> said:

    Boruch> I do think it would be great for emacs to include a curated collection
    Boruch> of sample init files descriptively labeled for use-case. I would go
    Boruch> further and suggest that the technique of using an org-mode file with
    Boruch> embedded code blocks as one's emacs init file be adopted as standard,
    Boruch> and be used for those collection of init files. That way each code block
    Boruch> can be explained and annotated to 'new' users.

Now youʼre just trying to get me to start rummaging through the garage
for a pitchfork and some torches. There are experienced emacs users
who manage to shoot themselves in the foot with such a setup, any
sample init files should just be emacs lisp forms, with
comments. Thatʼs the only setup thatʼs almost guaranteed to work out
of the box.

Robert

Re: Changes for emacs 28

[Boruch Baum]

My suggestion does skew to 'people willing to make the extra effort to
perform internet searches or downloads', so it will miss populations
such as 'people who download emacs, try it for a minutes, and reject it
on that basis'.

OTOH emacs has had sufficient time to establish a reputation for itself,
so anyone taking the first step to download vanilla emacs can be
expected to already have an expectation of a 'learning curve' ahead and
a future of constant tinkering.

--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

Re: Changes for emacs 28

[Boruch Baum]

On  Mon, 07 Sep 2020 22:57:34 -0400, Richard Stallman wrote:

> > If you don't want these features yourself and nobody else in the project
> > wants them either, the only way I can think of making a compelling
> > argument for people to develop those feature is to ask real people and
> > get real responses. I am fairly confident that if you had a testimony or
> > user-test from actual people stating that a feature is missing, then
> > people here would help develop that feature.
>
> I agree.  Before we put time into developing a feature, we should verify
> that many people would like it.
>
> Speaking of which, it would be useful to sit down with a new user just
> trying Emacs and see what perse actually complains about or requests.
> If several people do this, it could give us useful ideas of what changes
> would actually make Emacs more appealing to new users.

How about using existing download statistics from some source like
MELPA? That would be more empirical / less anecdotal, and would cast a
wider net. Other data sources might be link-click-quantity from github
or google analytics or stackexchange.

--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

Re: Changes for emacs 28

[Boruch Baum]

 On Mon, 7 Sep 2020 00:20:08 +0200, Ergus wrote:

> There will be never an agreement about changing defaults with long
> ...
> So what if:
> ...
> Does this makes sense?

Debian (and possibly other downstream projects) liberally change
defaults and add packages to their default version of emacs, so your
idea might meet a more enthusiastic reception somewhere in some
downstream project that caters more specifically to the user-base to
which your proposal is aimed.

In the case of Debian, that project may have already started moving in
the *opposite* direction; they culled many small debian-specific tweaks,
and removed packages from their 'vanilla' default version of emacs. On
the other hand, they've increased and somewhat standardized native
package-manager support for many third-party packages that most users
get MELPA or other third-parties.

Communicating with people at the following links might help advance your
proposal:

  https://github.com/bbatsov/prelude

  http://wikemacs.org/wiki/Starter_Kits


--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

Re: Changes for emacs 28

[Ergus]

Hi:

My point actually goes in the opposite direction. I don't want to add an
extra layer of abstraction, a fork, a new distribution (starter kit),
external dependencies to do things that vanilla emacs is totally capable
to do with probably less than 100 lines of configuration... but hidden
in our old syntax/names/bindings, unfamiliar lisp, and long and
sometimes too technical documentation.

The idea is to bring what we already have in vanilla but disabled, no
long starting times, extra hacks/functions or complex things to attract
new users coming from VSCode, Sublime or Atom.  



On Mon, Sep 07, 2020 at 05:31:48AM -0400, Boruch Baum wrote:
> On Mon, 7 Sep 2020 00:20:08 +0200, Ergus wrote:
>
>> There will be never an agreement about changing defaults with long
>> ...
>> So what if:
>> ...
>> Does this makes sense?
>
>Debian (and possibly other downstream projects) liberally change
>defaults and add packages to their default version of emacs, so your
>idea might meet a more enthusiastic reception somewhere in some
>downstream project that caters more specifically to the user-base to
>which your proposal is aimed.
>
I thing that we should a attract a little bit of everything; not only
lisp hacker. In my personal experience the Starter_Kits do too much and
increases the configuration complexity much more than the benefit they
bring. Specially because of the external dependencies and trick to group
them while supporting different emacs versions.

>In the case of Debian, that project may have already started moving in
>the *opposite* direction; they culled many small debian-specific tweaks,
>and removed packages from their 'vanilla' default version of emacs. On
>the other hand, they've increased and somewhat standardized native
>package-manager support for many third-party packages that most users
>get MELPA or other third-parties.
>
I actually never understood why Debian adds melpa-elpa packages to their
repos as their update sycle is veeeery slow... but this is another
discussion.

>Communicating with people at the following links might help advance your
>proposal:
>
>  https://github.com/bbatsov/prelude
>
>  http://wikemacs.org/wiki/Starter_Kits
>
Actually no, because they support (as I said) add too many complexities
layers, external dependencies and custom configuration sets with
personalized packages (like spacemacs layers) while modifying completely
the emacs bindings and sometimes breaking the integration with internal
emacs features like package-list. I want to bring the best we can with
what we have but with the simplest possible configuration and only with
internal features.

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.


>
>--
>hkp://keys.gnupg.net
>CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0
>

Changes for emacs 28

[Ergus]

Hi Emacs:

As 27 has just been released I think it is time to start considering
changes for the release 28. I will add some points I think we could
discuss (specially implying defaults) in order to hear opinions and have
enough time to discuss/implement them.

PLEASE: this are just proposals and every time we talk about defaults we
never get a conclusion or agreement. So I would appreciate if at the end,
one of the main developers (Eli, Stefan, etc) give a final opinion in
favor/opposing/reforming the change and that will close the discussion
(please).

Of course anyone can add extra points these are just the ones I remember
so far.

This are mainly "visible" changes that will benefit new users and first
impression because I don't understand why we hide the best
functionalities until the user learns how to configure them (and some
lisp).

1) Improve the default theme: Maybe set a default dark theme to make
emacs feel more modern. Experienced users usually already have a custom
theme, so they won't be affected. There is actually some statistics
about downloades themes here:

https://emacsthemes.com/popular/index.html

So we can use that to choose or design the theme.

2) Improve the completion buffer behavior: Actually I have a proposal
feature branch for this to make the experience more like zsh; but of
course that is just one option. Most experienced users use IDO, ivy or
helm, icompletes so they won't be affected.

3) Substitute list-buffers with ibuffer: This is actually in the TODO
but for interactive users ibuffer offers a bit more modern
experience. So the proposition is just to set ibuffer to the default
bindings as so far it already offers all the list-buffers'
functionalities.

4) Enable display-line-numbers-mode by default. Almost all editors
around have line numbers by default why we hide them?

5) Enable winmove and mouse-wheel-mode by default.

I think all these are very conservative changes (specially considering
that we have 2-3 years before enabling them)

WDYT??

Re: Changes for emacs 28

[Alfred M. Szmidt]

   1) Improve the default theme: Maybe set a default dark theme to make
   emacs feel more modern. Experienced users usually already have a custom
   theme, so they won't be affected. There is actually some statistics
   about downloades themes here:

This would be an utterly disastrous change.  As an experienced user, I
do not have a custom theme, and prefer to use the defaults of Emacs.

   4) Enable display-line-numbers-mode by default. Almost all editors
   around have line numbers by default why we hide them?

Just no.  Just because everyone does it, doesn't mean that it is a
good default.  In the majority of cases, there is no need to see the
line number -- for example, like when writting an email.

   5) Enable winmove and mouse-wheel-mode by default.

What is winmove?  

   I think all these are very conservative changes (specially considering
   that we have 2-3 years before enabling them)

They are absolutley not conservative changes. 

Re: Changes for emacs 28

[Elias Mårtenson]

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

On Sun, 6 Sep 2020 at 22:45, Alfred M. Szmidt <ams@gnu.org> wrote:

>    1) Improve the default theme: Maybe set a default dark theme to make
>    emacs feel more modern. Experienced users usually already have a custom
>    theme, so they won't be affected. There is actually some statistics
>    about downloades themes here:
>
> This would be an utterly disastrous change.  As an experienced user, I
> do not have a custom theme, and prefer to use the defaults of Emacs.
>

Same for me, and I'm pretty sure we're not alone.

Also, while dark background is popular right now, it's not necessarily
better. Apart from the fact that there is actual science showing that dark
backgrounds are worse for one's eyes, I believe the current trend is merely
the pendulum is swinging back.

Recall that backgrounds used to be dark back in the terminal era. Then
monitors became better and white background was finally usable. Now, people
who only ever have experienced white backgrounds wants to change things for
the sake of change, so that is now popular, even though it's actually
quantifiably worse.

This Wired article on the topic contains links to actual research on this:
https://www.wired.co.uk/article/dark-mode-chrome-android-ios-science

Regards,
Elias

[-- Attachment #2: Type: text/html, Size: 1773 bytes --]

Re: Changes for emacs 28

[Óscar Fuentes]

Elias Mårtenson <lokedhs@gmail.com> writes:

> This Wired article on the topic contains links to actual research on this:
> https://www.wired.co.uk/article/dark-mode-chrome-android-ios-science

Actually, the article links just one study about the specific topic of
dark/light modes. And it is behind a paywall.

The rest of the article is fluff, starting with assuming that "dark
mode" means "white text on black background", following with the
mentions of eye dryness, blink frequency and other issues unrelated to
dark mode and, the cake, hinting that dark modes might be bad because
people are more confortable with them and thus spend more time on front
of the screen.

Re: Changes for emacs 28

[Ergus]

Hi Elias:

Your link is basically a set of personal opinions with not concise
arguments at all against the "popular" keys that support dark mode use.

They refer to only 1 study; for the eye stress; they suggest to work
less in light screen mode while they present the comfortableness of dark
mode as an addiction problem.

So when you say "quantifiably worse" I hope you refer to something
else. OTOH there are also other "studies" blaming emacs for carpal
tunnel syndrome and even some posts of special keyboards only for
emacs... so not all "studies" are serious.

There actually are serious market studies, company studies, application
studies, ergonomic studies supporting dark mode. But also in the link I
shared there are the statistics of downloaded emacs themes; the
popularity experience of spacemacs or doom-emacs and also other editors
(atom, sublime, VSCode, Android Studio, the new Arduino IDE). Is
everybody wrong? 

I won't insist on this because in my experience this doesn't go
anywhere. But when I talked about theme I made in the general way
(font-lock, terminal, bars); because even vim has "better" default
colors. Dark thing was just one part of this.
  

On Sun, Sep 06, 2020 at 11:00:39PM +0800, Elias M?rtenson wrote:
>On Sun, 6 Sep 2020 at 22:45, Alfred M. Szmidt <ams@gnu.org> wrote:
>
>>    1) Improve the default theme: Maybe set a default dark theme to make
>>    emacs feel more modern. Experienced users usually already have a custom
>>    theme, so they won't be affected. There is actually some statistics
>>    about downloades themes here:
>>
>> This would be an utterly disastrous change.  As an experienced user, I
>> do not have a custom theme, and prefer to use the defaults of Emacs.
>>
>
>Same for me, and I'm pretty sure we're not alone.
>
>Also, while dark background is popular right now, it's not necessarily
>better. Apart from the fact that there is actual science showing that dark
>backgrounds are worse for one's eyes, I believe the current trend is merely
>the pendulum is swinging back.
>
>Recall that backgrounds used to be dark back in the terminal era. Then
>monitors became better and white background was finally usable. Now, people
>who only ever have experienced white backgrounds wants to change things for
>the sake of change, so that is now popular, even though it's actually
>quantifiably worse.
>
>This Wired article on the topic contains links to actual research on this:
>https://www.wired.co.uk/article/dark-mode-chrome-android-ios-science
>
>Regards,
>Elias

Re: Changes for emacs 28

[Alfred M. Szmidt]

   There actually are serious market studies, company studies, application
   studies, ergonomic studies supporting dark mode. But also in the link I
   shared there are the statistics of downloaded emacs themes; 

Those are statistics for how many times something was downloaded --
not the preference over one or the other...

   the popularity experience of spacemacs or doom-emacs and also other
   editors (atom, sublime, VSCode, Android Studio, the new Arduino
   IDE). Is everybody wrong?

Both sides can have a good reason to pick one default over the other.
There are plenty of editors that have a preference of a black-on-white
background too. 

Re: Changes for emacs 28

[Dmitry Gutov]

On 06.09.2020 20:07, Ergus wrote:
> Your link is basically a set of personal opinions with not concise
> arguments at all against the "popular" keys that support dark mode use.

Here's a more serious overview of related research: 
https://ux.stackexchange.com/a/53268/136203

Spoiler alert: light mode wins.

Re: Changes for emacs 28

[chad]

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

On Sun, Sep 6, 2020 at 11:33 AM Dmitry Gutov <dgutov@yandex.ru> wrote:

> On 06.09.2020 20:07, Ergus wrote:
> > Your link is basically a set of personal opinions with not concise
> > arguments at all against the "popular" keys that support dark mode use.
>
> Here's a more serious overview of related research:
> https://ux.stackexchange.com/a/53268/136203
>
> Spoiler alert: light mode wins.
>


It's been a while since I dove into the research around this, but from this
thread it seems to still be the case that context makes a large, in many
cases overriding difference. From that link:

For applications which provide long-form reading (books, articles, even
> news sites), dark mode options are recommended.


Many of those studies are concerned about visual acuity in very short-term
tasks -- correctly reading text that appears and disappears quickly, such
as alerts or notifications. It also notes that matching the background to
the environment (light in bright rooms, etc.) is key for sustained reading.

There's more research these days on glancing at small, very-hi-res screens,
which is nice (and unsurprising), but probably isn't all that helpful for
typical Emacs use (if there is such a thing as "typical" Emacs use). This
doesn't seem to be the sort of issue that's going to be resolved with a
clear "objectively better in most cases" argument, and Emacs has very
clearly declared (for decades) its conservatism towards UI changes, so
we're probably better off not painting this particular bikeshed.

That's my opinion, at least. I do think Emacs' new user experience could be
improved by adding some options/actions on display-splash-screen, though,
and I'd be happy to help with that.

Hope that helps,
~Chad

[-- Attachment #2: Type: text/html, Size: 2658 bytes --]

Re: Changes for emacs 28

[Dmitry Gutov]

On 07.09.2020 05:17, chad wrote:

> It's been a while since I dove into the research around this, but from 
> this thread it seems to still be the case that context makes a large, in 
> many cases overriding difference. From that link:
> 
>     For applications which provide long-form reading (books, articles,
>     even news sites), dark mode options are recommended. 

Maybe. But it's a quote from just one of the references articles.

> It also notes that matching 
> the background to the environment (light in bright rooms, etc.) is key 
> for sustained reading.

This is key. And you won't find many offices which match dark-background 
color themes, would you?

I'm not exactly against dark themes, and I use them on the phone for 
certain apps, but it's so much better when on my laptop the editor 
matches the rest of the programs, and the room around it as well.

> That's my opinion, at least. I do think Emacs' new user experience could 
> be improved by adding some options/actions on display-splash-screen, 
> though, and I'd be happy to help with that.

Sure. I'm all for that.

And it's not too long ago that we've had a similar, much longer thread 
on the same topic where a lot of us expressed the same sentiment.

Re: Changes for emacs 28

[Tim Van den Langenbergh]

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

Personal preference for a theme should have little if any impact on
Emacs defaults, as (at least on my OpenSUSE KDE desktop) Emacs
is a proper citizen and follows my global theme.
The only thing that doesn't follow and which I like to use a custom
theme for is the modeline.

On Sunday, 6 September 2020 17:00:39 CEST Elias Mårtenson wrote:
> On Sun, 6 Sep 2020 at 22:45, Alfred M. Szmidt <ams@gnu.org> wrote:
> 
> >    1) Improve the default theme: Maybe set a default dark theme to make
> >    emacs feel more modern. Experienced users usually already have a custom
> >    theme, so they won't be affected. There is actually some statistics
> >    about downloades themes here:
> >
> > This would be an utterly disastrous change.  As an experienced user, I
> > do not have a custom theme, and prefer to use the defaults of Emacs.
> >
> 
> Same for me, and I'm pretty sure we're not alone.
> 
> Also, while dark background is popular right now, it's not necessarily
> better. Apart from the fact that there is actual science showing that dark
> backgrounds are worse for one's eyes, I believe the current trend is merely
> the pendulum is swinging back.
> 
> Recall that backgrounds used to be dark back in the terminal era. Then
> monitors became better and white background was finally usable. Now, people
> who only ever have experienced white backgrounds wants to change things for
> the sake of change, so that is now popular, even though it's actually
> quantifiably worse.
> 
> This Wired article on the topic contains links to actual research on this:
> https://www.wired.co.uk/article/dark-mode-chrome-android-ios-science
> 
> Regards,
> Elias
> 


[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Changes for emacs 28

[Ergus]

On September 9, 2020 8:35:18 PM GMT+02:00, Tim Van den Langenbergh <tmt_vdl@gmx.com> wrote:
>Personal preference for a theme should have little if any impact on
>Emacs defaults, as (at least on my OpenSUSE KDE desktop) Emacs
>is a proper citizen and follows my global theme.
>The only thing that doesn't follow and which I like to use a custom
>theme for is the modeline.
>
Yes, I actually didn't mention the mode line before because with the profile solution that could be also solved... And we can create several alternatives.

>On Sunday, 6 September 2020 17:00:39 CEST Elias Mårtenson wrote:
>> On Sun, 6 Sep 2020 at 22:45, Alfred M. Szmidt <ams@gnu.org> wrote:
>> 
>> >    1) Improve the default theme: Maybe set a default dark theme to
>make
>> >    emacs feel more modern. Experienced users usually already have a
>custom
>> >    theme, so they won't be affected. There is actually some
>statistics
>> >    about downloades themes here:
>> >
>> > This would be an utterly disastrous change.  As an experienced
>user, I
>> > do not have a custom theme, and prefer to use the defaults of
>Emacs.
>> >
>> 
>> Same for me, and I'm pretty sure we're not alone.
>> 
>> Also, while dark background is popular right now, it's not
>necessarily
>> better. Apart from the fact that there is actual science showing that
>dark
>> backgrounds are worse for one's eyes, I believe the current trend is
>merely
>> the pendulum is swinging back.
>> 
>> Recall that backgrounds used to be dark back in the terminal era.
>Then
>> monitors became better and white background was finally usable. Now,
>people
>> who only ever have experienced white backgrounds wants to change
>things for
>> the sake of change, so that is now popular, even though it's actually
>> quantifiably worse.
>> 
>> This Wired article on the topic contains links to actual research on
>this:
>> https://www.wired.co.uk/article/dark-mode-chrome-android-ios-science
>> 
>> Regards,
>> Elias
>> 

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

Re: Changes for emacs 28

[Andrea Corallo via Emacs development discussions.]

IMO our ultimate goal should be bringing more people into Emacs, GNU, and
Free Software.  As many as we can I'd say.

I fear pleasing ourselves with a nostalgic toy may not be most effective
strategy there.

Thanks Ergus, FWIW I support your points.

  Andrea

Re: Changes for emacs 28

[Ergus]

There will be never an agreement about changing defaults with long
standing users. (I can't understand the strong feeling about that
because some/most of the choices we have today were actually determined
by historic/technological conditions more than user preferences)

So what if:

Could we provide a simple command line option like "emacs -m" (or any
letter not in use) which automatically loads a set of extra
"experimental" defaults not suitable for older users?? (the same as
emacs -l modern.el but shorter) Like a different theme, line numbers,
show-paren mode, and any other "modern" feature a newbie expects in a
2020 editor?

We can also provide a .desktop only for it and equivalents to make it
easier to find for new users. And recommend the users to add an alias if
they like to set it as default? and add a note in the welcome screen.

Is this also too crazy?

Probably this features will be trivial for us, but not for anyone
opening emacs for the first time. I am just talking about enabling some
features we already have in vanilla, but they are "hidden"; this is not
doing a complex configs or so.

Alternatively the user will have a copy of this file ready to copy in
his home and personalize as he prefers. So he will have something
"official" to start with; instead of coping random potentially
outdated/problematic configs from internet.

Does this makes sense?

On Sun, Sep 06, 2020 at 08:49:25PM +0000, Andrea Corallo via Emacs development discussions. wrote:
>IMO our ultimate goal should be bringing more people into Emacs, GNU, and
>Free Software.  As many as we can I'd say.
>
>I fear pleasing ourselves with a nostalgic toy may not be most effective
>strategy there.
>
>Thanks Ergus, FWIW I support your points.
>
>  Andrea
>

Re: Changes for emacs 28

[Eli Zaretskii]

> Date: Mon, 7 Sep 2020 00:20:08 +0200
> From: Ergus <spacibba@aol.com>
> Cc: "Alfred M. Szmidt" <ams@gnu.org>, emacs-devel@gnu.org
> 
> So what if:
> 
> Could we provide a simple command line option like "emacs -m" (or any
> letter not in use) which automatically loads a set of extra
> "experimental" defaults not suitable for older users?? (the same as
> emacs -l modern.el but shorter) Like a different theme, line numbers,
> show-paren mode, and any other "modern" feature a newbie expects in a
> 2020 editor?
> 
> We can also provide a .desktop only for it and equivalents to make it
> easier to find for new users. And recommend the users to add an alias if
> they like to set it as default? and add a note in the welcome screen.
> 
> Is this also too crazy?
> 
> Probably this features will be trivial for us, but not for anyone
> opening emacs for the first time. I am just talking about enabling some
> features we already have in vanilla, but they are "hidden"; this is not
> doing a complex configs or so.
> 
> Alternatively the user will have a copy of this file ready to copy in
> his home and personalize as he prefers. So he will have something
> "official" to start with; instead of coping random potentially
> outdated/problematic configs from internet.
> 
> Does this makes sense?

Yes.

This was proposed in the past.   Someone will have to figure out what
features should this turn on.  AFAIR, no one has come with a coherent
suggestion yet.

Re: Changes for emacs 28

[Alfred M. Szmidt]

   There will be never an agreement about changing defaults with long
   standing users. (I can't understand the strong feeling about that
   because some/most of the choices we have today were actually determined
   by historic/technological conditions more than user preferences)

You are mixing up several different changes, which makes it difficult
to explain why sometimes.  Please take it one default at a time.

   Could we provide a simple command line option like "emacs -m" (or any
   letter not in use) which automatically loads a set of extra
   "experimental" defaults not suitable for older users??

If that mode is significantly different (e.g, CUA mode) from
"standard" emacs then it will be difficult to point users to the
documentation, or that the documentation will have to have many
caveats.

   (the same as emacs -l modern.el but shorter) Like a different
   theme, line numbers, show-paren mode, and any other "modern"
   feature a newbie expects in a 2020 editor?

Why are the things you suggest not suitable for experienced users, but
suitable for new users?  You do not explain why, and you come up with
more suggestions in each new message.  Before enabling, or disabling a
feature one should have a reason to do so.

I do not think that new users expect any of those things you have
listed (show-paren-mode, display-line-numbers-mode or a different
theme); from my experience when teaching new users they want just get
stuff done.  The first thing they tend to miss in my experience is
getting navigation setup, or auto-completion since many editors come
with that out of the box.

Re: Changes for emacs 28

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

Would people please split this discussion into a separate
thread for each proposal?  That would make it easier for each
person to focus on the issues that interest per.

-- 
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: Changes for emacs 28

[Andrea Corallo via Emacs development discussions.]

Ergus <spacibba@aol.com> writes:

[...]
> So what if:
>
> Could we provide a simple command line option like "emacs -m" (or any
> letter not in use) which automatically loads a set of extra
> "experimental" defaults not suitable for older users?? (the same as
> emacs -l modern.el but shorter) Like a different theme, line numbers,
> show-paren mode, and any other "modern" feature a newbie expects in a
> 2020 editor?
>
> We can also provide a .desktop only for it and equivalents to make it
> easier to find for new users. And recommend the users to add an alias if
> they like to set it as default? and add a note in the welcome screen.
>
> Is this also too crazy?

It is probably the only viable option, even if sub-optimal will be
certainly better than nothing.

Unfortunately many people evaluate this default changes in terms of how
many lines their .emacs is going to be afterwards.  This is a totally
broken metric as the only goal should be easing new users to get
onboard.

  Andrea

Re: Changes for emacs 28

[tomas]

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

On Mon, Sep 07, 2020 at 12:20:08AM +0200, Ergus wrote:
> There will be never an agreement about changing defaults with long
> standing users.

So we use your preferences?

>(I can't understand the strong feeling about that
> because some/most of the choices we have today were actually determined
> by historic/technological conditions more than user preferences)

And yours are better than other's ;-P

Sorry for being a bit sarcastic. It's not with the intention to hurt:
I know you're well-intentioned, but if you think about it, discussions
about defaults are bound to end like this, at least in a community as
diverse as Emacs's is (show me another piece of software which is (a)
user-oriented and (b) alive for over 30 years).

There are several reactions to this (recurring) "Hey, let's change the
world, because, you know, Emacs is Old (TM)". You now have seen a couple
of them. Most old folks who are happy with how things work now just
sigh and say "well, as long as I can disable it -- go ahead". This,
of course, ignores that there's a price to pay: fragmented experience.
Of course, with a highly customizable thing as Emacs is, there'll
always be some of that, but it costs something (like asking for help
on copy-paste and getting blank stares, or being told to do C-v (is
this on Apple/Microsoft-themed Ergus-Emacs, where it means "paste",
or in "Classic", where it means "scroll down"?.

It's clear that one has to pay part of that price. But how much? That
can only be found by trying to find a consensus, since it is a collective
price to pay.

So please: as important as those ideas are, consider those points:

1. there are people perfectly happy with the current defaults.
  And they are happy for a reason -- sometimes for a *good*
  reason. Just assumeng that they are "resistant to change"
  can feel insulting.

2. "anyone can coustomize its own Platonic cave" is a solution
  just up to a certain point. Finding this equilibrium (which
  tends to shift over time) is something a long-lived project
  has to do (and is doing) anyway all of the time.

So your best way forward is, as someone else (I think it was Eli)
proposed in this thread is to discuss each potential default change
separately.

Alternatively, you could offer your new "world vision" as an ELPA
package for people to try out: no need to wait for the next version.

Then, as a more radical approach, you might try to fork Emacs.
This sounds harsh, but a friendly fork can be enriching, too.

Cheers
-- t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Changes for emacs 28

[Elias Mårtenson]

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

On Mon, 7 Sep 2020, 15:38 , <tomas@tuxteam.de> wrote:

>
> I know you're well-intentioned, but if you think about it, discussions
> about defaults are bound to end like this, at least in a community as
> diverse as Emacs's is (show me another piece of software which is (a)
> user-oriented and (b) alive for over 30 years).
>

Maxima. Over 50 years at this point, and counting.

And yes, it has the same concerns as Emacs in many areas. Remarkably
similar in fact.

Regards,
Elias

>

[-- Attachment #2: Type: text/html, Size: 1105 bytes --]

Re: Changes for emacs 28

[tomas]

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

On Tue, Sep 08, 2020 at 08:50:25AM +0800, Elias Mårtenson wrote:
> On Mon, 7 Sep 2020, 15:38 , <tomas@tuxteam.de> wrote:
> 
> >
> > I know you're well-intentioned, but if you think about it, discussions
> > about defaults are bound to end like this, at least in a community as
> > diverse as Emacs's is (show me another piece of software which is (a)
> > user-oriented and (b) alive for over 30 years).
> >
> 
> Maxima. Over 50 years at this point, and counting.

Yes. Thanks for that :-)

> And yes, it has the same concerns as Emacs in many areas. Remarkably
> similar in fact.

I see. I'd like there to be a way to have such discussions in a
fashion that is constructive: on the one side, the enthusiasm of
people arriving and saying "hey, let's change the world!" is very
valuable, and it's always sad to see it chilled, on the other side
the experience lurking in the old and seasoned corpus (an more
than that: the community) is as valuable.

I'd like to see such exchanges with no hurt feelings. On the contrary,
they should be enjoyable for all parties alike.

Is that the philosopher's stone? Or am I becoming senile?

Cheers
 - t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Changes for emacs 28

[Bastien]

Hi Andrea,

Andrea Corallo via "Emacs development discussions."
<emacs-devel@gnu.org> writes:

> IMO our ultimate goal should be bringing more people into Emacs, GNU, and
> Free Software.  As many as we can I'd say.

You also need to keep a good balance between maintainers, contributors
and users--one that allows users to exert their famous freedom through
software that is both free and well maintained.

> I fear pleasing ourselves with a nostalgic toy may not be most effective
> strategy there.

As Eli said, nobody here is paid for working on Emacs, so if there is
a good idea out there (and Stefan's concept of profiles looks good to
me) then you need to work on it or to convince someone else to do so.

2 cents,

-- 
 Bastien

Re: Changes for emacs 28

[Eli Zaretskii]

> Date: Sun, 6 Sep 2020 15:37:19 +0200
> From: Ergus <spacibba@aol.com>
> 
> As 27 has just been released I think it is time to start considering
> changes for the release 28.

We don't normally "consider changes for the next release", we just
wait until there're enough new features and/or enough time since the
previous major release, and go with what we have at that point.  Since
we are not a company with hierarchy and management, we have no real
way of telling someone what to do and when.

So I suggest a separate discussion for each feature/change you'd like
to see happening.  Then whatever decision we will make about each one,
will be in Emacs 28.

Thanks.

Re: Changes for emacs 28

[Ergus]

On Sun, Sep 06, 2020 at 05:44:40PM +0300, Eli Zaretskii wrote:
>> Date: Sun, 6 Sep 2020 15:37:19 +0200
>> From: Ergus <spacibba@aol.com>
>>
>> As 27 has just been released I think it is time to start considering
>> changes for the release 28.
>
>We don't normally "consider changes for the next release", we just
>wait until there're enough new features and/or enough time since the
>previous major release, and go with what we have at that point.  Since
>we are not a company with hierarchy and management, we have no real
>way of telling someone what to do and when.
>
>So I suggest a separate discussion for each feature/change you'd like
>to see happening.  Then whatever decision we will make about each one,
>will be in Emacs 28.
>
>Thanks.

Hi Eli:

I just mentioned some default changes that will not require almost any
extra implementation and functionalities that have already been there
for many years. I am just thinking in the first impression for new
users...

The reaction has been as expected but I needed to mention them just to
see which ones could or couldn't be at least considered. So I don't
waste time with the others.

Sorry but I can't understand why "old" users, that can write lisp lines
easily to their configs, can't understand that for new users (and
younger ones) those lines sometimes takes hours or days (mainly because
they don't know what/where/how to look for, and lisp is not so
popular or familiar these days). And that the first impression when they
open emacs is like going back to 1998. 

I know that ideally the users should read the documentation, learn lisp,
pass the tutorial and so on... but in real live if the first impression
is not good we just scare away them before they discover the power of
emacs. Mainly because there are many alternatives easier to start with.

It is just my opinion.
I won't insist on this anymore.

Best,
Ergus.

Re: Changes for emacs 28

[Yuan Fu]

> 
> I just mentioned some default changes that will not require almost any
> extra implementation and functionalities that have already been there
> for many years. I am just thinking in the first impression for new
> users...
> 
> The reaction has been as expected but I needed to mention them just to
> see which ones could or couldn't be at least considered. So I don't
> waste time with the others.
> 
> Sorry but I can't understand why "old" users, that can write lisp lines
> easily to their configs, can't understand that for new users (and
> younger ones) those lines sometimes takes hours or days (mainly because
> they don't know what/where/how to look for, and lisp is not so
> popular or familiar these days). And that the first impression when they
> open emacs is like going back to 1998. 
> I know that ideally the users should read the documentation, learn lisp,
> pass the tutorial and so on... but in real live if the first impression
> is not good we just scare away them before they discover the power of
> emacs. Mainly because there are many alternatives easier to start with.
> 
> It is just my opinion.
> I won't insist on this anymore.
> 
> Best,
> Ergus.
> 

AFAICT, those changes wouldn’t have enough support (if any) here. Instead, what about compiling a separate Emacs that has all these “good modern features/options” enabled? We can even go further and compile a shiny and truly out-of-the-box Emacs. The problem is, of course, people with the skill don’t care about this, and people need/want this don’t have the skill.

Yuan

Re: Changes for emacs 28

[Alfred M. Szmidt]

   Sorry but I can't understand why "old" users, that can write lisp lines
   easily to their configs, can't understand that for new users (and
   younger ones) those lines sometimes takes hours or days (mainly because
   they don't know what/where/how to look for, and lisp is not so
   popular or familiar these days). And that the first impression when they
   open emacs is like going back to 1998. 

I think you need to make a stronger case as to why a user would spend,
from day one, several hours or days to configure Emacs to be able to
use it -- such an story would be very interesting to read to learn and
understand what could be improved.  The list you suggested would
barley have any impact on the experience of new users, but would have
a large impact on people who have been using emacs for a long time.

We can turn the argument around as well, as users become more
experienced they will add more of the "experienced" defaults to their
configuration files -- making it a general waste of time trying to
find those good defaults for experienced users, having to possibly
reinvent the wheel over and over again.

What new users will want is more or less from my experience the same
as what experienced users expect to see, to open and edit files, have
navigation or auto-popup-completion -- both which I think would be
nice to see as standard for common modes (not just programming, and
working as well as emacs-lisp-mode and eldoc-mode).  They will
probobly want to have some sort of WYSIWYG feature for writting notes.

Re: Changes for emacs 28

[Ergus]

On Sun, Sep 06, 2020 at 03:32:02PM -0400, Alfred M. Szmidt wrote:
>   Sorry but I can't understand why "old" users, that can write lisp lines
>   easily to their configs, can't understand that for new users (and
>   younger ones) those lines sometimes takes hours or days (mainly because
>   they don't know what/where/how to look for, and lisp is not so
>   popular or familiar these days). And that the first impression when they
>   open emacs is like going back to 1998.
>
>I think you need to make a stronger case as to why a user would spend,
>from day one, several hours or days to configure Emacs to be able to
>use it -- such an story would be very interesting to read to learn and
>understand what could be improved.  The list you suggested would
>barley have any impact on the experience of new users, but would have
>a large impact on people who have been using emacs for a long time.
>
Suppose that you come from a world more or less standard where you copy
with C-c paste with C-v cut with C-x undo with C-z and redo with C-S-z
or C-r; you also save with C-s and search with C-f.

In this same world you get that tabs insert tabs, complete with C-RET,
you search for all the documentation in internet not in the same
application and if you don't like the colors, the indentation, the
bindings or want to add line numbers or use a different font you go to
Preferences and it is done with 2 clicks.

In this same world there is an application's store you find in the bar
"install extension" or even a panel comes suggesting you what to
install. If you don't know how to do common operations you right click
on text and you get a panel with plenty of common options like copy
paste highlight all like this, replace, compile and so on.

I am NOT telling we should do all this, but this is what a young user
expects because all these is more or less standard everywhere else. To
anyone coming from that world it takes learning time to understand or
get used to ALL the changes, the Lisp parenthesis, the M-x, the new
names, get a smarter completion for it's use case, learn the common
bindings, debugging his config usually a copy-paste from somewhere
random on internet..

>We can turn the argument around as well, as users become more
>experienced they will add more of the "experienced" defaults to their
>configuration files -- making it a general waste of time trying to
>find those good defaults for experienced users, having to possibly
>reinvent the wheel over and over again.
>
They don't become experienced if they don't enter long enough and go for
any other alternative because is simpler, prettier, or just works out of
the box. 

>What new users will want is more or less from my experience the same
>as what experienced users expect to see, to open and edit files, have
>navigation or auto-popup-completion -- both which I think would be
>nice to see as standard for common modes (not just programming, and
>working as well as emacs-lisp-mode and eldoc-mode).  They will
>probobly want to have some sort of WYSIWYG feature for writting notes.
>
Go for Atom, VSCode, Sublime Text and see what the users wants
there. There are very active forums and plenty of packages because these
editors has 10 times more users than emacs with just 2 or 3 years of
existence.

Re: Changes for emacs 28

[Gregory Heytings via Emacs development discussions.]

Ergus:
>
> There actually are serious market studies, company studies, application 
> studies, ergonomic studies supporting dark mode.
>

I'd like to see some of these studies.  "Dark mode" goes against what so 
many people have been doing for centuries (think of books for example) 
that I'm really curious to see why they were wrong.

>
> They don't become experienced if they don't enter long enough and go for 
> any other alternative because is simpler, prettier, or just works out of 
> the box.
>

Each software has its audience.  Some are targeted at advanced users, 
others at a more general audience.  Word processors work out of the box 
with all the nice features you describe, yet LaTeX is still there (and was 
already there before all of them existed).  Visual Basic and <name your 
favorite next-generation programming language here> each have some of the 
features you describe, yet C is still there (and was there before they 
existed).  And so forth.

>
> Go for Atom, VSCode, Sublime Text and see what the users wants there. 
> There are very active forums and plenty of packages because these 
> editors has 10 times more users than emacs with just 2 or 3 years of 
> existence.
>

Yet Emacs is one of the oldest computer programs still in use.  And not 
all its users are 60-year old people.

Re: Changes for emacs 28

[Ricardo Wurmus]

Gregory Heytings via Emacs development discussions. <emacs-devel@gnu.org> writes:

> Ergus:
>>
>> There actually are serious market studies, company studies,
>> application studies, ergonomic studies supporting dark mode.
>>
>
> I'd like to see some of these studies.  "Dark mode" goes against what
> so many people have been doing for centuries (think of books for
> example) that I'm really curious to see why they were wrong.

https://www.nature.com/articles/s41598-018-28904-x

  “We found that reading dark text on bright background reduces
choroidal thickness in one hour, while reading bright text on dark
background increases the thickness of the choroid. Since choroidal
thickness changes are precursors for future changes in eye growth, we
expect that there will be selective effects on subsequent myopia
development.”

-- 
Ricardo

Re: Changes for emacs 28

[Gregory Heytings via Emacs development discussions.]

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


>
>> I'd like to see some of these studies.  "Dark mode" goes against what 
>> so many people have been doing for centuries (think of books for 
>> example) that I'm really curious to see why they were wrong.
>
> https://www.nature.com/articles/s41598-018-28904-x
>
>  “We found that reading dark text on bright background reduces choroidal 
> thickness in one hour, while reading bright text on dark background 
> increases the thickness of the choroid. Since choroidal thickness 
> changes are precursors for future changes in eye growth, we expect that 
> there will be selective effects on subsequent myopia development.”
>

Okay, so according to these authors, in essence "light mode" might perhaps 
in the long term lead to more myopia.  There is no causal relation, they 
only "expect" something, and their expectation might very well be what is 
known as a "cum hoc ergo propter hoc" fallacy.  In short, that's already 
an interesting indication, but I'll wait to see (much) more studies like 
this before being convinced.

Re: Changes for emacs 28

[Ricardo Wurmus]

Gregory Heytings <ghe@sdf.org> writes:

>>> I'd like to see some of these studies.  "Dark mode" goes against
>>> what so many people have been doing for centuries (think of books
>>> for example) that I'm really curious to see why they were wrong.
>>
>> https://www.nature.com/articles/s41598-018-28904-x
>>
>>  “We found that reading dark text on bright background reduces
>> choroidal thickness in one hour, while reading bright text on dark
>> background increases the thickness of the choroid. Since choroidal
>> thickness changes are precursors for future changes in eye growth,
>> we expect that there will be selective effects on subsequent myopia
>> development.”
>>
>
> Okay, so according to these authors, in essence "light mode" might
> perhaps in the long term lead to more myopia.

No, the choroid became significantly thicker after *one* hour of reading
white text on black, and significantly thinner after *one* hour of
reading black text on white.  Choroid thickness is known to be a
significant factor in myopia.

The open questions include a description of the exact mechanism leading
to this observable effect and identification of whether it is (lack or
presence of) ON or OFF stimulation that has the effect.  The effect
itself is not in question.

> In short, that's already an interesting indication, but I'll wait to
> see (much) more studies like this before being convinced.

That’s fine.  I don’t think the topic is black and white (hah) anyway,
so I don’t aim to convince or be convinced myself.  There are simply
different metrics on which light and dark mode score differently well or
poorly, so I don’t expect there to be a clear winner either way.  It’s a
value judgement and finding a personal compromise, weighing eye strain,
readability, short-term and long-term changes to the eyes, etc.

We shouldn’t pretend that there’s one best way for everyone.  The most
eye-saving way forward is clearly not to read at all, but we don’t
recommend using emacspeak instead of displaying text — though in all
seriousness, perhaps there should be a simple accessibility menu to
enable or disable emacspeak, to select dark or light mode, to set the
text contrast (similar to how the solarized theme grades colours on an
adjustable contrast curve), etc.

-- 
Ricardo

Re: Changes for emacs 28

[Joost Kremers]

On Mon, Sep 07 2020, Ricardo Wurmus wrote:
> No, the choroid became significantly thicker after *one* hour of 
> reading
> white text on black, and significantly thinner after *one* hour 
> of
> reading black text on white.

Yes, but...

>  Choroid thickness is known to be a
> significant factor in myopia.

in the sense that a thicker choroid is correlated to worse cases 
of myopia? Or is it the other way around? (Perhaps it's me, but 
the formulation "choroid thickness is a factor in myopia" doesn't 
seem to answer that question.)

-- 
Joost Kremers
Life has its moments

Re: Changes for emacs 28

[Dmitry Gutov]

On 07.09.2020 11:38, Ricardo Wurmus wrote:
> https://www.nature.com/articles/s41598-018-28904-x
> 
>    “We found that reading dark text on bright background reduces
> choroidal thickness in one hour, while reading bright text on dark
> background increases the thickness of the choroid. Since choroidal
> thickness changes are precursors for future changes in eye growth, we
> expect that there will be selective effects on subsequent myopia
> development.”

I wouldn't take this at face value. First, the big "conclusion" in there 
is based on conjecture, we don't know the underlying choroid <-> myopia 
mechanism, and whether it's causation or correlation.

Second, the example dark-on-light color choice in the article (Figure 1) 
is obviously terrible and low-contrast. I wouldn't recommend anyone to 
use it.

Third, and this is of course anecdotal, I had an episode in my 
mid-twenties where I started having problems with vision (blurriness, 
low perception in the dark, etc), and it only got better when I made 
sure to use good, strong lighting everywhere, good contrast screens, 
etc, which is the predominant ergonomic advice these days. 10 years 
later, my vision is 20/20.

Another advice from the same category is that the brightness and 
contrast levels of your screen should match the rest of the room, and 
more specifically, the room (or wall) behind the screen. So dark themes 
have their uses, of course (for reading in the dark: on the phone in the 
evening outside; on the airplane; etc). But I'm quite sure defaulting to 
a light theme for general work is still better for most people.

Re: Changes for emacs 28

[Juri Linkov]

> Another advice from the same category is that the brightness and contrast
> levels of your screen should match the rest of the room, and more
> specifically, the room (or wall) behind the screen. So dark themes have
> their uses, of course (for reading in the dark: on the phone in the evening
> outside; on the airplane; etc). But I'm quite sure defaulting to a light
> theme for general work is still better for most people.

+1  Also it's recommended to use a blue light filter to avoid suppression of
Melatonin production.  For example, http://jonls.dk/redshift/ pre-installed
on Mint adjusts the color temperature depending on the time of the day.

Re: Changes for emacs 28

[Alfred M. Szmidt]

There is a fine line to walk between people who use emacs, and people
who might come to use emacs.  To change the defaults of Emacs to
something that would be entirely alien to the majority of Emacs users
would do more harm than good.  

Many settings can be set using Cutomize which is available via the
menu bar, maybe another page or some type of reorganisation with
commonly wanted settings could be done.  Emacs already has packages
that you can install using the Manage Emacs Packages option in the menu
bar as well.  Context dependant mouse menus based on the mode are
already provided in Emacs since a long time, Control and right click.

The missing features you are raising seem to be already provided by
emacs.  Even if learning Lisp should be considered something to
encourage all users, a new users can happily use Emacs without seeing
any lisp code, or never invoking M-x since Emacs works very well out
of the box.  This is not to say that each of the above couldn't use
improvements, but one can do so without breaking things for existing
users.

Re: Changes for emacs 28

[Lars Ingebrigtsen]

Instead of discussing new, radical defaults (which I don't think are
going to go anywhere, because annoying older users isn't nice), we could
just put a button on the opening splash page saying

     Current theme: Classic.  Click HERE to get the super-cool rad one.

And then the HERE could enable whatever the kids these days want, and it
could be ALL the mod cons.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Changes for emacs 28

[Caio Henrique]

I wouldn't mind radical new defaults if I could easily disable them with
some compilation flag like --with-old-defaults, or just adding a line like 
(setq use-new-radical-defaults nil) to my early-init.el.

Cordially,
Caio Henrique

Re: Changes for emacs 28

[Jose A. Ortega Ruiz]

On Sun, Sep 06 2020, Caio Henrique wrote:

> I wouldn't mind radical new defaults if I could easily disable them with
> some compilation flag like --with-old-defaults, or just adding a line like
> (setq use-new-radical-defaults nil) to my early-init.el.

FWIW, as someone who has been using emacs for more than 20 years and
spends 90% of his computer time in emacs, i wouldn't mind either.

IMHO, the odds that an experienced user of emacs would ditch it just
because of a (for her, easily overriden) default change are virtually
nil; with a new user, the situation is almost the opposite.

Just my old-timer 2 cents,
jao
-- 
More people would learn from their mistakes if they weren't so busy
denying them - Harlod J. Smith

Re: Changes for emacs 28

[Lars Ingebrigtsen]

"Jose A. Ortega Ruiz" <jao@gnu.org> writes:

> IMHO, the odds that an experienced user of emacs would ditch it just
> because of a (for her, easily overriden) default change are virtually
> nil; with a new user, the situation is almost the opposite.

I don't think we should underestimate how annoying user interface
changes can be.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Changes for emacs 28

[Jose A. Ortega Ruiz]

On Mon, Sep 07 2020, Lars Ingebrigtsen wrote:

> "Jose A. Ortega Ruiz" <jao@gnu.org> writes:
>
>> IMHO, the odds that an experienced user of emacs would ditch it just
>> because of a (for her, easily overriden) default change are virtually
>> nil; with a new user, the situation is almost the opposite.
>
> I don't think we should underestimate how annoying user interface
> changes can be.

Well, yes, but that cuts both ways: for new users with experience with
other editors or current environments, opening Emacs for the first time
amounts to a huge user interface change.

Cheers,
jao
-- 
Once you hear the details of victory, it is hard to distinguish it
from a defeat. -Jean-Paul Sartre, writer and philosopher (1905-1980)

Re: Changes for emacs 28

[Eric S Fraga]

On Monday,  7 Sep 2020 at 13:44, Jose A. Ortega Ruiz wrote:
> Well, yes, but that cuts both ways: for new users with experience with
> other editors or current environments, opening Emacs for the first time
> amounts to a huge user interface change.

Yes, but a decision consciously made by choosing to try a new tool
whereas a change to the interface made to an existing user is without
her conscious choice.

But I'm one of those crusty/fusty Emacs users whose .emacs file (none of
this new fangled .emacs.d or .config business ;-)) dates to the 1980s so
I won't mind what happens as I'm sure I will be able to fix things to my
satisfaction...

-- 
Eric S Fraga via Emacs 28.0.50 & org 9.3.7 on Debian bullseye/sid

Re: Changes for emacs 28

[Daniel Martín]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Instead of discussing new, radical defaults (which I don't think are
> going to go anywhere, because annoying older users isn't nice), we could
> just put a button on the opening splash page saying
>
>      Current theme: Classic.  Click HERE to get the super-cool rad one.
>
> And then the HERE could enable whatever the kids these days want, and it
> could be ALL the mod cons.

I very much agree with this point. For these discussions to be
productive, we should try to reach a compromise, if possible, and work
in small steps. The idea of offering a light/dark alternative theme
prominently from the splash screen is worth considering.

Recently, modus-operandi-theme[1] and modus-vivendi-theme[2] have been
included in core Emacs. They are two light/dark themes that offer good
accessibility and broad face coverage for internal and external
packages. I'm not suggesting we should offer those exact themes, that
was just an example; maybe we can poll users/developers about what's
their favorite FSF-copyrighted theme.

[1]: https://elpa.gnu.org/packages/modus-operandi-theme.html
[2]: https://elpa.gnu.org/packages/modus-vivendi-theme.html

--
Daniel Martín

Re: Changes for emacs 28

[Eduardo Ochs]

So we all want this modern-ish "layer" for Emacs. If I haven't missed
anything, the main ideas on how to activate it are:

  1) it will be the new default, or

  2) it will be toggled by a command-line option like "-m" (btw, is
     this viable on M$ Windows?), or

  3) there will be a button in the splash screen that toggles it,

  4) it can be toggled via Customize,

  5) it can be turned on by a built-in command like M-x
     use-the-new-super-cool-rad-layer.

In my not-so-humble-at-all opinion the recommended way to install this
new layer should START as a progn. The developers' page should say
something like: at this moment the modern-ish layer is still
experimental; to try it copy the 5-line "(progn ...)" below to an
Emacs buffer, put the cursor after the close-parenthesis in the last
line, and type C-x C-e - this will execute the whole (progn ...), and
this will install the super-cool-rad-layer and make it the default:

  (progn (Lorem ipsum dolor sit amet consectetuer adipiscing elit)
     (Ut purus elit vestibulum ut placerat ac adipiscing vitae felis)
     (Curabitur dictum gravida mauris)
     (Nam arcu libero nonummy eget consectetuer id vulputate a magna)
     )

This reminds me of a discussion that happened in February in the Lua
mailing list, about "we need a super-user-friendly distribution of Lua
that comes with all batteries included". In one of my messages to that
discussion - at http://lua-users.org/lists/lua-l/2020-02/msg00036.html
- I said:

  "In my way of seeing things, making a package manager that makes
  developers super-happy [1] is a pre-requisite for [2] having a
  distribution for all OSs including Windows that beginners find easy
  to use. And [1] can be done in 100 or 200 programmer-hours with
  expertise that we already have, while [2] needs 10000000000 hours at
  least, plus black-belt social skills, lots of money to hire external
  people, and luck."

I am very passionate about the idea that in environments like Emacs
"developer-friendly" should come before "user-friendly". If there are
people who insist that even in the development stage we should NEVER
offer the progn-ish way of installing the super-cool-rad-layer I would
be overjoyed to hit them several times with my ten-feet pole.

  Just my 2c, sorry for not being more active here, cheers, etc =),
    Eduardo Ochs
    http://angg.twu.net/emacsconf2019.html

On Sun, 6 Sep 2020 at 19:01, Lars Ingebrigtsen <larsi@gnus.org> wrote:
>
> Instead of discussing new, radical defaults (which I don't think are
> going to go anywhere, because annoying older users isn't nice), we could
> just put a button on the opening splash page saying
>
>      Current theme: Classic.  Click HERE to get the super-cool rad one.
>
> And then the HERE could enable whatever the kids these days want, and it
> could be ALL the mod cons.
>
> --
> (domestic pets only, the antidote for overdose, milk.)
>    bloggy blog: http://lars.ingebrigtsen.no
>
>

Re: Changes for emacs 28

[Stefan Kangas]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Instead of discussing new, radical defaults (which I don't think are
> going to go anywhere, because annoying older users isn't nice), we could
> just put a button on the opening splash page saying
>
>      Current theme: Classic.  Click HERE to get the super-cool rad one.
>
> And then the HERE could enable whatever the kids these days want, and it
> could be ALL the mod cons.

I agree.  I've proposed before to introduce a concept called "profiles"
much like the existing theme support:

    https://lists.gnu.org/archive/html/emacs-devel/2020-04/msg02032.html
    https://lists.gnu.org/archive/html/emacs-devel/2020-05/msg01168.html

I haven't yet had the time/energy to work on this, but I think it could
be useful here.

Re: Changes for emacs 28

[Lars Ingebrigtsen]

Stefan Kangas <stefankangas@gmail.com> writes:

> I agree.  I've proposed before to introduce a concept called "profiles"
> much like the existing theme support:
>
>     https://lists.gnu.org/archive/html/emacs-devel/2020-04/msg02032.html
>     https://lists.gnu.org/archive/html/emacs-devel/2020-05/msg01168.html
>
> I haven't yet had the time/energy to work on this, but I think it could
> be useful here.

Yes, I think it's exactly what we need, and it seems like almost
everybody is pretty much in agreement?  But somebody has to, like,
implement it.  :-)

A splash page with a selection for different
profiles/distribution/flavour/curated version or whatever we're calling
it would be cool: A vi-flavoured one, and a Doom-flavoured one, etc.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Changes for emacs 28

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Ergus <spacibba@aol.com>,  eliz@gnu.org,  emacs-devel@gnu.org
> Date: Mon, 07 Sep 2020 00:01:05 +0200
> 
> Instead of discussing new, radical defaults (which I don't think are
> going to go anywhere, because annoying older users isn't nice), we could
> just put a button on the opening splash page saying
> 
>      Current theme: Classic.  Click HERE to get the super-cool rad one.
> 
> And then the HERE could enable whatever the kids these days want, and it
> could be ALL the mod cons.

This was suggested long ago, but no one seems to be willing to pick up
the gauntlet and make this happen.

Re: Changes for emacs 28

[Lars Ingebrigtsen]

This just showed up in my feed:

   https://phaazon.net/blog/editors-in-2020

It's kinda interesting -- they go through a bunch of editors and list
what works/doesn't work for them.  Key quote:

* The defaults of emacs are really, really bad. And making the whole thing like
 what you get with DOOM Emacs is going to cost you lots of hours reading
 documentation and experimenting with your configuration. I enjoyed doing it but
 in the end… why simply not ship emacs with those defaults? Is it due to
 historical reasons that no one cares about anymore nowadays? /stares at vim

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Changes for emacs 28

[tomas]

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

On Mon, Sep 07, 2020 at 02:31:36PM +0200, Lars Ingebrigtsen wrote:
> This just showed up in my feed:
> 
>    https://phaazon.net/blog/editors-in-2020
> 
> It's kinda interesting -- they go through a bunch of editors and list
> what works/doesn't work for them.  Key quote:
> 
> * The defaults of emacs are really, really bad. And making the whole thing like
>  what you get with DOOM Emacs is going to cost you lots of hours reading
>  documentation and experimenting with your configuration. I enjoyed doing it but
>  in the end… why simply not ship emacs with those defaults? Is it due to
>  historical reasons that no one cares about anymore nowadays? /stares at vim

This is, of course, Dimitri Sabadie's take on it. It's an interesting
read, and one can learn a lot about it.

Still I spot this horrible anti-pattern ("my opinion matters, others
don't exist", cf the above: "Is it due to historical reasons that no
one cares about anymore nowadays?" -- has Dimitri ever talked to someone
who might "care nowadays" or does he postulate his POV to be the only one?).

Same goes for those terms subtly transporting a judgment like "modern".
They don't go well with those people implicitly being relegated to 
"not existent" or "old".

I'd like to see some integrative efforts on part of those proposing
changes -- more akin to "what can be done to cater to all?" instead
of "let's change the defaults to look more like VSCode!".

Discussing the defaults one by one (as proposed by Eli) might be one
good step in that direction.

After all, we don't gain anything by attracting two VSCoders and
kicking out five old-timers here.

Cheers
 - t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Changes for emacs 28

[Gregory Heytings via Emacs development discussions.]

>
> The defaults of emacs are really, really bad. And making the whole thing 
> like what you get with DOOM Emacs is going to cost you lots of hours 
> reading documentation and experimenting with your configuration.
>

That's just wrong.  If you want Doom Emacs, you just have to type two 
commands:

git clone --depth 1 https://github.com/hlissner/doom-emacs ~/.emacs.d

~/.emacs.d/bin/doom install

The first commands takes two seconds to complete, the second one about 
five minutes (it downloads and compiles about 200 MB of code, fonts, 
icons, ...).  Then you start Emacs, and you're done.  That's clearly not 
"lots of hours".

Re: Changes for emacs 28

[Ergus]

On Mon, Sep 07, 2020 at 01:05:20PM +0000, Gregory Heytings via Emacs development discussions. wrote:
>
>>
>>The defaults of emacs are really, really bad. And making the whole 
>>thing like what you get with DOOM Emacs is going to cost you lots of 
>>hours reading documentation and experimenting with your 
>>configuration.
>>
>
>That's just wrong.  If you want Doom Emacs, you just have to type two 
>commands:
>
>git clone --depth 1 https://github.com/hlissner/doom-emacs ~/.emacs.d
>
>~/.emacs.d/bin/doom install
>
>The first commands takes two seconds to complete, the second one about 
>five minutes (it downloads and compiles about 200 MB of code, fonts, 
>icons, ...).  Then you start Emacs, and you're done.  That's clearly 
>not "lots of hours".
>

I think it refers to convert vanilla emacs in a "doomed like"
experience.

Any way the doom experience is (in my opinion) like the spacemacs
experience. A signal that

1) There are enough people interested enough in emacs (the community)
and we (as developers) are not interacting enough with them or hearing
their concerns and needs.

2) Part of that community are also so annoyed with the defaults (and
have the needed skills) that they tried to create their own "emacs
distro" like a "GNU/Linux distro".

3) They are reinventing the wheel again and again because we don't
attract some of them on board to contribute part of their code into
vanilla.

The existence of larger sub-communities like spacemacs or doom or forks
like remacs is a bad symptom and a waste of manpower we really need.

My last 2 cents on this.

Re: Changes for emacs 28

[Eli Zaretskii]

> Date: Mon, 7 Sep 2020 16:03:32 +0200
> From: Ergus <spacibba@aol.com>
> Cc: emacs-devel@gnu.org
> 
> The existence of larger sub-communities like spacemacs or doom or forks
> like remacs is a bad symptom and a waste of manpower we really need.

I don't think I agree that those communities are a waste of effort:
someone needed to invest those efforts anyway.

The waste of effort is that those who invested them don't come back to
us and don't suggest to integrate those features upstream.  Granted,
such integration would need some additional shims and infrastructure,
to adapt the extra features to less monolith audience.  But those
adaptations should not be very hard to come up with, so the lack of
communications is unfortunate.

Re: Changes for emacs 28

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

  > The waste of effort is that those who invested them don't come back to
  > us and don't suggest to integrate those features upstream.  Granted,
  > such integration would need some additional shims and infrastructure,
  > to adapt the extra features to less monolith audience.  But those
  > adaptations should not be very hard to come up with, so the lack of
  > communications is unfortunate.

You may be right.  I think it depends on what sort of changes they make,
and I have no idea what sort they are.

It might be that some of their changes are features we'd like to
merge in as optional features, or new options, while others are not.
Maybe they would be willing to contribute certain code that we would like
since it could reduce the continuing maintenance work they do.

-- 
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: Changes for emacs 28

[Gregory Heytings via Emacs development discussions.]

>>> The defaults of emacs are really, really bad. And making the whole 
>>> thing like what you get with DOOM Emacs is going to cost you lots of 
>>> hours reading documentation and experimenting with your configuration.
>> 
>> That's just wrong.  If you want Doom Emacs, you just have to type two 
>> commands:
>> 
>> git clone --depth 1 https://github.com/hlissner/doom-emacs ~/.emacs.d
>> 
>> ~/.emacs.d/bin/doom install
>> 
>> The first commands takes two seconds to complete, the second one about 
>> five minutes (it downloads and compiles about 200 MB of code, fonts, 
>> icons, ...).  Then you start Emacs, and you're done.  That's clearly 
>> not "lots of hours".
>
> I think it refers to convert vanilla emacs in a "doomed like" 
> experience.
>

I don't understand.  The two commands above do exactly that.

Or does "convert vanilla emacs in a "doomed like" experience" means 
"without using Doom Emacs, by doing everything by oneself"?  In that case 
it's not wrong, it is ridiculous.  Almost as ridiculous as if he had 
written "it would have taken me more time to develop Emacs by myself than 
to develop Visual Studio by myself".

BTW, I find that many of the defaults of Visual Studio are really bad, and 
I'm pretty sure that making the whole thing like what you get with vanilla 
Emacs would cost me lots of hours.  Can I conclude something from this? 
Clearly not.

Re: Changes for emacs 28

[Ergus]

On Mon, Sep 07, 2020 at 03:37:58PM +0000, Gregory Heytings wrote:
>
>>>>The defaults of emacs are really, really bad. And making the 
>>>>whole thing like what you get with DOOM Emacs is going to cost 
>>>>you lots of hours reading documentation and experimenting with 
>>>>your configuration.
>>>
>>>That's just wrong.  If you want Doom Emacs, you just have to type 
>>>two commands:
>>>
>>>git clone --depth 1 https://github.com/hlissner/doom-emacs ~/.emacs.d
>>>
>>>~/.emacs.d/bin/doom install
>>>
>>>The first commands takes two seconds to complete, the second one 
>>>about five minutes (it downloads and compiles about 200 MB of 
>>>code, fonts, icons, ...).  Then you start Emacs, and you're done.  
>>>That's clearly not "lots of hours".
>>
>>I think it refers to convert vanilla emacs in a "doomed like" 
>>experience.
>>

Sorry, you don't get the point and I don't waste more time on this.

>
>I don't understand.  The two commands above do exactly that.
>
>Or does "convert vanilla emacs in a "doomed like" experience" means 
>"without using Doom Emacs, by doing everything by oneself"?  In that 
>case it's not wrong, it is ridiculous.  Almost as ridiculous as if he 
>had written "it would have taken me more time to develop Emacs by 
>myself than to develop Visual Studio by myself".
>
If a software we develop require a complex layer like doom (which could
be seen as a big set of patches) to be "attractive" for many users. But
also if there are many layer many of them doing the similar changes
again and again. Yes our software is missing something.

>BTW, I find that many of the defaults of Visual Studio are really bad, 
>and I'm pretty sure that making the whole thing like what you get with 
>vanilla Emacs would cost me lots of hours.  Can I conclude something 
>from this? Clearly not.

There is not such a thing like the "perfect" default. But we can learn
some things from similar newer software around. Sometimes the feeling is
that we don't change things not because they are fine, but because we
are used to how they are and we reject anything that other editors are
doing just because they are not us (the opposite is also an error;
trying to do everything the others are doing).

Any way there is a sort of consensus about the profiles No more
discussion is needed.

Re: Changes for emacs 28

[Alfred M. Szmidt]

   >Or does "convert vanilla emacs in a "doomed like" experience" means 
   >"without using Doom Emacs, by doing everything by oneself"?  In that 
   >case it's not wrong, it is ridiculous.  Almost as ridiculous as if he 
   >had written "it would have taken me more time to develop Emacs by 
   >myself than to develop Visual Studio by myself".

   If a software we develop require a complex layer like doom (which could
   be seen as a big set of patches) to be "attractive" for many users. 

Emacs definitely doesn't require a complex layer like doom /
spaceemacs.

Re: Changes for emacs 28

[Eduardo Ochs]

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

Is there a way to have both standard Emacs and Doom Emacs available at the
same time? Is there a way to run the standard Emacs and then make it load
the Doom code? Where can we find instructions for that? Is Doom Emacs
user-friendly to long-time Emacs users that would want to turn the Doom
layer on for only a few minutes each week?

  Cheers & thanks in advance,
    Eduardo Ochs

On Mon, 7 Sep 2020, 10:06 Gregory Heytings via Emacs development
discussions., <emacs-devel@gnu.org> wrote:

>
> >
> > The defaults of emacs are really, really bad. And making the whole thing
> > like what you get with DOOM Emacs is going to cost you lots of hours
> > reading documentation and experimenting with your configuration.
> >
>
> That's just wrong.  If you want Doom Emacs, you just have to type two
> commands:
>
> git clone --depth 1 https://github.com/hlissner/doom-emacs ~/.emacs.d
>
> ~/.emacs.d/bin/doom install
>
> The first commands takes two seconds to complete, the second one about
> five minutes (it downloads and compiles about 200 MB of code, fonts,
> icons, ...).  Then you start Emacs, and you're done.  That's clearly not
> "lots of hours".
>
>

[-- Attachment #2: Type: text/html, Size: 1723 bytes --]

Re: Changes for emacs 28

[Gregory Heytings via Emacs development discussions.]

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


>
> Is there a way to have both standard Emacs and Doom Emacs available at 
> the same time? Is there a way to run the standard Emacs and then make it 
> load the Doom code? Where can we find instructions for that?
>

"Doom Emacs" is, in essence, a set of Emacs Lisp files bundled together, 
configured so that they interact nicely and coherently.  For example, 
smartparens, which-key and magit are part of Doom Emacs, but can be used 
(and were developed) independently of Doom Emacs.  The same holds for all 
Emacs "distributions", for example Spacemacs or Emacs Prelude.

The Emacs Lisp files contained in these distributions are loaded by Emacs 
when it starts and change its look and feel.  What you run is "standard 
Emacs", but with a number of non-standard (that is, not distributed with 
Emacs) Emacs Lisp files.

>
> Is Doom Emacs user-friendly to long-time Emacs users that would want to 
> turn the Doom layer on for only a few minutes each week?
>

That's of course possible.  It suffices to replace one's ~/.emacs.d 
directory with the ~/.emacs.d directory of an Emacs distribution (and to 
move the ~/.emacs file, if it exists, to another place).  Switching 
between several Emacs distributions can probably be achieved with symbolic 
links.

Re: Changes for emacs 28

[Robert Pluim]

>>>>> On Mon, 07 Sep 2020 22:07:39 +0000, Gregory Heytings via "Emacs development discussions." <emacs-devel@gnu.org> said:

    >> Is Doom Emacs user-friendly to long-time Emacs users that would want
    >> to turn the Doom layer on for only a few minutes each week?
    >> 

    Gregory> That's of course possible.  It suffices to replace one's ~/.emacs.d
    Gregory> directory with the ~/.emacs.d directory of an Emacs distribution (and
    Gregory> to move the ~/.emacs file, if it exists, to another place).  Switching
    Gregory> between several Emacs distributions can probably be achieved with
    Gregory> symbolic links.

Anything is possible with symbolic links, but with emacs >= 27.1 itʼs
probably easier to use XDG_CONFIG_HOME

Robert

Re: Changes for emacs 28

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

  > It's kinda interesting -- they go through a bunch of editors and list
  > what works/doesn't work for them.  Key quote:

  > * The defaults of emacs are really, really bad.

Alas, that feedback is too vague to be of any use.

-- 
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: Changes for emacs 28

[Gregory Heytings via Emacs development discussions.]

>
> Instead of discussing new, radical defaults (which I don't think are 
> going to go anywhere, because annoying older users isn't nice), we could 
> just put a button on the opening splash page saying
>
>     Current theme: Classic.  Click HERE to get the super-cool rad one.
>
> And then the HERE could enable whatever the kids these days want, and it 
> could be ALL the mod cons.
>

I could perhaps agree with this (except perhaps that I would rephrase "to 
get the super-cool..." as "to activate the super-cool...").  But as Eli 
noted nobody has done this so far.  And in fact I'm not sure it would 
really improve the "adoption rate".  There are plenty of example 
configurations available (for example Spacemacs), and someone who would 
not want to make the effort of trying to find a configuration that suits 
their needs would quickly switch to another trendy editor anyway.

FWIW, my own experience with this kind of tools is that those who do not 
have initially a good non-technical reason to use it (for example "I want 
to be a guru", "Someone I admire uses that tool", "It is one of the freest 
free software", "It is based on Lisp and I love Lisp", "I want to have the 
freedom to change everything to make it work exactly as I want", "I like 
minimal user interfaces", "I want to do as much as possible without using 
a mouse", ...) will not use it in the long term.  This external motivation 
is necessary to "climb the learning curve", so to speak, and "better" 
defaults will have no influence on it.

Re: Changes for emacs 28

[Gregory Heytings via Emacs development discussions.]

>
> Instead of discussing new, radical defaults (which I don't think are 
> going to go anywhere, because annoying older users isn't nice), we could 
> just put a button on the opening splash page saying
>
>     Current theme: Classic.  Click HERE to get the super-cool rad one.
>
> And then the HERE could enable whatever the kids these days want, and it 
> could be ALL the mod cons.
>

Would it not be better to have a "guided tour" (something like C-h t, but 
shorter and more "modern") for first-time users (those without a .emacs / 
.emacs.d)?  This is quite common in "modern" software, so it would not 
surprise anyone.

During that "guided tour" the user could select a number of options, e.g. 
cua-mode, evil-mode, which-key, hl-line, show-paren-mode, a theme 
(customize-themes is there since Emacs 24, with a number builtin themes, 
currently sixteen), and these options would be written in their .emacs 
file.

(In fact, it would perhaps make sense to create a few guided tours, with 
an initial question "Are you a programmer? a scientist? a teacher? a 
writer?" with which the set of options could be narrowed.)

With this it would be unnecessary to change any of the defaults, yet 
newcomers would quickly be able to tailor some aspects of Emacs to their 
needs.

A side-effect is that the discussions here would perhaps be less 
passionated.  "Should feature X be offered as an option to first-time 
users?" may lead to more serene discussions than "Should feature X become 
a default in future Emacs versions?"

Re: Changes for emacs 28

[Göktuğ Kayaalp]

On 2020-09-09 14:22 +03, Gregory Heytings via Emacs development discussions. <emacs-devel@gnu.org> wrote:
> Would it not be better to have a "guided tour" (something like C-h t,
> but shorter and more "modern") for first-time users (those without a
> .emacs / .emacs.d)?  This is quite common in "modern" software, so it
> would not surprise anyone.
[...]
> (In fact, it would perhaps make sense to create a few guided tours,
> with an initial question "Are you a programmer? a scientist? a
> teacher? a writer?" with which the set of options could be narrowed.)

Why not instead just have nicer introductory material? E.g. videos that
walk through initial customisation for different setups, that discuss
and explain things, talk about tangents.

This actually is produced by the community, but it’s scattered around
YouTube.  We could ask prolific producers to prepare 20-30min videos for
some particular setup, showing how to get going with Emacs in that
particular niche.

The wizard idea from another thread is nice, but I’m not a fan of a
whole guided tour.  Most probably people would want to skip it.  A
blocker just as your first boot a program is not nice.


--
İ. Göktuğ Kayaalp / @cadadr / <https://www.gkayaalp.com/>
pgp:   024C 30DD 597D 142B 49AC 40EB 465C D949 B101 2427

Re: Changes for emacs 28

[Gregory Heytings via Emacs development discussions.]

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


>
>> Would it not be better to have a "guided tour" (something like C-h t, 
>> but shorter and more "modern") for first-time users (those without a 
>> .emacs / .emacs.d)?  This is quite common in "modern" software, so it 
>> would not surprise anyone.
> [...]
>> (In fact, it would perhaps make sense to create a few guided tours, 
>> with an initial question "Are you a programmer? a scientist? a teacher? 
>> a writer?" with which the set of options could be narrowed.)
>
> Why not instead just have nicer introductory material? E.g. videos that 
> walk through initial customisation for different setups, that discuss 
> and explain things, talk about tangents.
>

That's too complex IMO.  I at least would never have the patience to watch 
N videos to discover such things.  If the target is users who just give 
Emacs a try, as we all do from time to time for programs we don't know, 
expecting that they would first watch videos (or to read introductory 
material) sets the bar way too high.

>
> The wizard idea from another thread is nice, but I’m not a fan of a 
> whole guided tour.  Most probably people would want to skip it.  A 
> blocker just as your first boot a program is not nice.
>

I was thinking of something very simple, with say five screens.  There are 
at least two examples I have in mind and which I find rather pleasing to 
go through: the Debian installer and the macOS installer.

A rough draft:

Screen 1: Welcome! Please tell us something about you: are you (a) a 
programmer, (b) a teacher, (c) ...

Screen 2: Choose a theme (font + colors).

Screen 3: A few (at most twenty) common options to turn on or off, with a 
short explanation for each option.  "cua-mode" is a good candidate for 
this screen.  A button "Other options" could open another similar screen 
with a few other less common options to turn on or off.

Screen 4: Some basic explanations: what "C-" and "M-" mean, what is the 
minibuffer, ...

Screen 5: Thank you and welcome on board!  You'll find a list of 
extensions that you may find useful in the menu "Extensions".

The menu "Extensions" would be populated depending on the user kind 
selected in screen 1.

Re: Changes for emacs 28

[Stefan Monnier]

> Emacs a try, as we all do from time to time for programs we don't know,
> expecting that they would first watch videos (or to read introductory
> material) sets the bar way too high.

Yes and no: many (young) people seem to spend most of their time
watching videos (as in, watching videos is their equivalent to my being
idle).  But admittedly, those videos usually last 10s or so (and if not,
they switch to the next video anyway), so we'd have to use *very* short
videos, ideally funny and sexy, maybe with a cat?


        Stefan

Re: Changes for emacs 28

[Ergus]

On Wed, Sep 09, 2020 at 12:19:10PM -0400, Stefan Monnier wrote:
>> Emacs a try, as we all do from time to time for programs we don't know,
>> expecting that they would first watch videos (or to read introductory
>> material) sets the bar way too high.
>
>Yes and no: many (young) people seem to spend most of their time
>watching videos (as in, watching videos is their equivalent to my being
>idle).  But admittedly, those videos usually last 10s or so (and if not,
>they switch to the next video anyway), so we'd have to use *very* short
>videos, ideally funny and sexy, maybe with a cat?
>
>
>        Stefan

To start lets see what video series are around and it seems to be some
material already (and the most important, people willing to do emacs
videos):

https://www.youtube.com/watch?v=rBcw42ZGJDo&list=PLstWlvURJNxQknxEfkIktiPDfUrAUC8s6
https://www.youtube.com/watch?v=49kBWM3RQQ8&list=PL9KxKa8NpFxIcNQa9js7dQQIHc81b0-Xg
https://www.youtube.com/watch?v=V27zOhfN8Ys&list=PLGP2UnPoZ7HzLGU2cyK1MXSZwXy5niFkk

So far (as I have seen most of those) they have just 3 issues:

1) Put most of the attention in the external packages and not in the
vanilla functionalities.

2) They are not connected or referenced in the emacs web site. But also
they make little or no reference to the manual at all.

3) I saw a series of vim tutorials and the videos were sealing vim much
better. Even the vim terrible modes they found a way to sale them as
features..

4*) There are very few videos about elisp language and programming or
the emacs infrastructure.

Re: Changes for emacs 28

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

  > https://www.youtube.com/watch?v=rBcw42ZGJDo&list=PLstWlvURJNxQknxEfkIktiPDfUrAUC8s6
  > https://www.youtube.com/watch?v=49kBWM3RQQ8&list=PL9KxKa8NpFxIcNQa9js7dQQIHc81b0-Xg
  > https://www.youtube.com/watch?v=V27zOhfN8Ys&list=PLGP2UnPoZ7HzLGU2cyK1MXSZwXy5niFkk

If these videos carry free licenses, and they are worth referring to,
we can do so.  Not on youtube, though: it sends nonfree JS code to the
browser.

If we could count on the "invidious" sites to function stably, we could
refer to the videos via them.  But we can't assume Google will allow
them to continue functioning.

So we would have to copy the videos to a place we can count on to
function without demanding you run nonfree software.

  > 3) I saw a series of vim tutorials and the videos were sealing vim much
  > better. Even the vim terrible modes they found a way to sale them as
  > features..

To address that, we need people who can MAKE good videos.

-- 
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: Changes for emacs 28

[Dmitry Gutov]

On 11.09.2020 07:13, Richard Stallman wrote:
> If we could count on the "invidious" sites to function stably, we could
> refer to the videos via them.  But we can't assume Google will allow
> them to continue functioning.
> 
> So we would have to copy the videos to a place we can count on to
> function without demanding you run nonfree software.
> 
>    > 3) I saw a series of vim tutorials and the videos were sealing vim much
>    > better. Even the vim terrible modes they found a way to sale them as
>    > features..
> 
> To address that, we need people who can MAKE good videos.

I'd like to remind everybody that we do have a few videos on 
https://www.gnu.org/software/emacs/ already.

Alas, Magnar has not been making any new videos for a few years now, so 
we probably can't ask him to make a specific video.

Re: Changes for emacs 28

[Pankaj Jangid]

Gregory Heytings via "Emacs development discussions."
<emacs-devel@gnu.org> writes:

> That's too complex IMO.  I at least would never have the patience to
> watch N videos to discover such things.  If the target is users who
> just give Emacs a try, as we all do from time to time for programs we
> don't know, expecting that they would first watch videos (or to read
> introductory material) sets the bar way too high.

I assumed the same thing when I was training a new joinee in my
company. Probably we are getting old. :-) This new person tells me after
going through software manuals for 2-3 days, "do we have video
tutorials?"

So my opinion is that we need impressive community videos that talk
about vanilla emacs.

Re: Changes for emacs 28

[Ergus]

On September 9, 2020 5:04:57 PM GMT+02:00, "Göktuğ Kayaalp" <self@gkayaalp.com> wrote:
>On 2020-09-09 14:22 +03, Gregory Heytings via Emacs development
>discussions. <emacs-devel@gnu.org> wrote:
>> Would it not be better to have a "guided tour" (something like C-h t,
>> but shorter and more "modern") for first-time users (those without a
>> .emacs / .emacs.d)?  This is quite common in "modern" software, so it
>> would not surprise anyone.
>[...]
>> (In fact, it would perhaps make sense to create a few guided tours,
>> with an initial question "Are you a programmer? a scientist? a
>> teacher? a writer?" with which the set of options could be narrowed.)
>
>Why not instead just have nicer introductory material? E.g. videos that
>walk through initial customisation for different setups, that discuss
>and explain things, talk about tangents.
>
>This actually is produced by the community, but it’s scattered around
>YouTube.  We could ask prolific producers to prepare 20-30min videos
>for
>some particular setup, showing how to get going with Emacs in that
>particular niche.
>
>The wizard idea from another thread is nice, but I’m not a fan of a
>whole guided tour.  Most probably people would want to skip it.  A
>blocker just as your first boot a program is not nice.
>

Yes I think that more, better and organized set of videos could be much easier to produce. There are actually some emacs video series already. We just need to organize the links and refer them in the site. 

Actually shorter videos maybe 10 mins is enough. Specially if they add links to the manual sections related to the topic and how to access it either from emacs and on the web.


>
>--
>İ. Göktuğ Kayaalp / @cadadr / <https://www.gkayaalp.com/>
>pgp:   024C 30DD 597D 142B 49AC 40EB 465C D949 B101 2427

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

Re: Changes for emacs 28

[Ihor Radchenko]

> Actually shorter videos maybe 10 mins is enough. Specially if they add links to the manual sections related to the topic and how to access it either from emacs and on the web.

Would it also make sense to add links to the videos (or relevant wiki
page) from manual itself?

Best,
Ihor

Ergus <spacibba@aol.com> writes:

> On September 9, 2020 5:04:57 PM GMT+02:00, "Göktuğ Kayaalp" <self@gkayaalp.com> wrote:
>>On 2020-09-09 14:22 +03, Gregory Heytings via Emacs development
>>discussions. <emacs-devel@gnu.org> wrote:
>>> Would it not be better to have a "guided tour" (something like C-h t,
>>> but shorter and more "modern") for first-time users (those without a
>>> .emacs / .emacs.d)?  This is quite common in "modern" software, so it
>>> would not surprise anyone.
>>[...]
>>> (In fact, it would perhaps make sense to create a few guided tours,
>>> with an initial question "Are you a programmer? a scientist? a
>>> teacher? a writer?" with which the set of options could be narrowed.)
>>
>>Why not instead just have nicer introductory material? E.g. videos that
>>walk through initial customisation for different setups, that discuss
>>and explain things, talk about tangents.
>>
>>This actually is produced by the community, but it’s scattered around
>>YouTube.  We could ask prolific producers to prepare 20-30min videos
>>for
>>some particular setup, showing how to get going with Emacs in that
>>particular niche.
>>
>>The wizard idea from another thread is nice, but I’m not a fan of a
>>whole guided tour.  Most probably people would want to skip it.  A
>>blocker just as your first boot a program is not nice.
>>
>
> Yes I think that more, better and organized set of videos could be much easier to produce. There are actually some emacs video series already. We just need to organize the links and refer them in the site. 
>
> Actually shorter videos maybe 10 mins is enough. Specially if they add links to the manual sections related to the topic and how to access it either from emacs and on the web.
>
>
>>
>>--
>>İ. Göktuğ Kayaalp / @cadadr / <https://www.gkayaalp.com/>
>>pgp:   024C 30DD 597D 142B 49AC 40EB 465C D949 B101 2427
>
> -- 
> Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: Changes for emacs 28

[Philip K.]

Göktuğ Kayaalp <self@gkayaalp.com> writes:

> On 2020-09-09 14:22 +03, Gregory Heytings via Emacs development discussions. <emacs-devel@gnu.org> wrote:
>> Would it not be better to have a "guided tour" (something like C-h t,
>> but shorter and more "modern") for first-time users (those without a
>> .emacs / .emacs.d)?  This is quite common in "modern" software, so it
>> would not surprise anyone.
> [...]
>> (In fact, it would perhaps make sense to create a few guided tours,
>> with an initial question "Are you a programmer? a scientist? a
>> teacher? a writer?" with which the set of options could be narrowed.)
>
> Why not instead just have nicer introductory material? E.g. videos that
> walk through initial customisation for different setups, that discuss
> and explain things, talk about tangents.
>
> This actually is produced by the community, but it’s scattered around
> YouTube.  We could ask prolific producers to prepare 20-30min videos for
> some particular setup, showing how to get going with Emacs in that
> particular niche.

Why 20-30 minutes? I think limiting it to 2-3 minutes for specific
problems would be more helpful. After all, a video that demonstrates
one thing well (search, buffer or window management, etc.) is better
than mentioning a few topics over the timespan of half an hour. I hope
I'm not the only one who tends to forget most of the points made in a
longer video, and often gives up half-way through if it gets too
boring.

> The wizard idea from another thread is nice, but I’m not a fan of a
> whole guided tour.  Most probably people would want to skip it.  A
> blocker just as your first boot a program is not nice.

I think I've suggested this before, but a manually invoked wizard could
be interesting. Typing "M-x intro" and getting a selection of
"interactive tutorials" -- again short and with a progress indicator --
would probably help a lot of people learn the basics quicker than
reading the manual or C-h t.

-- 
	Philip K.

Re: Changes for emacs 28

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

Does anyone want to _make_ videos for Emacs?

It is no use discussing what sort of videos we
would like if nobody wants to make them.
Let's stick to ideas we can implement.

-- 
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: Changes for emacs 28

[Ihor Radchenko]

> Does anyone want to _make_ videos for Emacs?
>
> It is no use discussing what sort of videos we
> would like if nobody wants to make them.
> Let's stick to ideas we can implement.

I can try to contact Mike Zamansky [1] - he already has very good
introductory series about Emacs and might (hopefully) be interested to
help. Also, he is a teacher himself and may be a good person to suggest
on the best format/timing of such videos.

Best,
Ihor

[1] https://www.youtube.com/channel/UCxkMDXQ5qzYOgXPRnOBrp1w

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. ]]]
>
> Does anyone want to _make_ videos for Emacs?
>
> It is no use discussing what sort of videos we
> would like if nobody wants to make them.
> Let's stick to ideas we can implement.
>
> -- 
> 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: Changes for emacs 28

[Ergus]

On Fri, Sep 11, 2020 at 12:16:13AM -0400, Richard Stallman wrote:
>[[[ 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. ]]]
>
>Does anyone want to _make_ videos for Emacs?
>
>It is no use discussing what sort of videos we
>would like if nobody wants to make them.
>Let's stick to ideas we can implement.
>
Actually there are series of videos in youtube about emacs. Some of them
very long with more than 40 episodes. So their producers could be
contacted and they could help making things on demand. (not centered in
external packages but in included features or elpa packages only)

The real problem is: If we cannot refer to youtube then: Where these
videos can be offloaded that we could link to?

>-- 
>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: Changes for emacs 28

[Philip K.]

Ergus <spacibba@aol.com> writes:

> On Fri, Sep 11, 2020 at 12:16:13AM -0400, Richard Stallman wrote:
>>[[[ 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. ]]]
>>
>>Does anyone want to _make_ videos for Emacs?
>>
>>It is no use discussing what sort of videos we
>>would like if nobody wants to make them.
>>Let's stick to ideas we can implement.
>
> Actually there are series of videos in youtube about emacs. Some of them
> very long with more than 40 episodes. So their producers could be
> contacted and they could help making things on demand. (not centered in
> external packages but in included features or elpa packages only)
>
> The real problem is: If we cannot refer to youtube then: Where these
> videos can be offloaded that we could link to?

I was thinking about using Peertube for something like that. It works
fairly well, the interface is clean enough, and it even has fediverse
integration.

-- 
	Philip K.

Re: Changes for emacs 28

[Ergus]

On Fri, Sep 11, 2020 at 12:55:41PM +0200, Philip K. wrote:
>Ergus <spacibba@aol.com> writes:
>
>> On Fri, Sep 11, 2020 at 12:16:13AM -0400, Richard Stallman wrote:
>>>[[[ 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. ]]]
>>>
>>>Does anyone want to _make_ videos for Emacs?
>>>
>>>It is no use discussing what sort of videos we
>>>would like if nobody wants to make them.
>>>Let's stick to ideas we can implement.
>>
>> Actually there are series of videos in youtube about emacs. Some of them
>> very long with more than 40 episodes. So their producers could be
>> contacted and they could help making things on demand. (not centered in
>> external packages but in included features or elpa packages only)
>>
>> The real problem is: If we cannot refer to youtube then: Where these
>> videos can be offloaded that we could link to?
>
>I was thinking about using Peertube for something like that. It works
>fairly well, the interface is clean enough, and it even has fediverse
>integration.
>
>-- 
>	Philip K.

Good: I didn't know about it.

In this case we could start trying to contact the authors of the videos
already existent in youtube asking to copy them to peertube so we can
link them.

In principle they can keep a copy in youtube but we won't refer to
them.

Is it possible to create channels in peertube? If so, then maybe we
could create an "official" emacs channel and then some playlists there
for the creators.

Re: Changes for emacs 28

[Philip K.]

Ergus <spacibba@aol.com> writes:

> Good: I didn't know about it.

In case anyone else is not familiar with the Project, here's the link:
https://joinpeertube.org/

> In this case we could start trying to contact the authors of the videos
> already existent in youtube asking to copy them to peertube so we can
> link them.
>
> In principle they can keep a copy in youtube but we won't refer to
> them.
>
> Is it possible to create channels in peertube? If so, then maybe we
> could create an "official" emacs channel and then some playlists there
> for the creators.

Yes, it's possible to create a channel
     
     https://docs.joinpeertube.org/#/use-create-upload-video

and playlists can be created too:

    https://docs.joinpeertube.org/#/use-library?id=playlist

-- 
	Philip K.

Re: Changes for emacs 28

[Ergus]

On Fri, Sep 11, 2020 at 02:12:24PM +0200, Philip K. wrote:
>Ergus <spacibba@aol.com> writes:
>
>> Good: I didn't know about it.
>
>In case anyone else is not familiar with the Project, here's the link:
>https://joinpeertube.org/
>
>> In this case we could start trying to contact the authors of the videos
>> already existent in youtube asking to copy them to peertube so we can
>> link them.
>>
>> In principle they can keep a copy in youtube but we won't refer to
>> them.
>>
>> Is it possible to create channels in peertube? If so, then maybe we
>> could create an "official" emacs channel and then some playlists there
>> for the creators.
>
>Yes, it's possible to create a channel
>
>     https://docs.joinpeertube.org/#/use-create-upload-video
>
>and playlists can be created too:
>
>    https://docs.joinpeertube.org/#/use-library?id=playlist
>
>-- 
>	Philip K.

I also think that Mike Zamansky is the right guy for this task because
he has a very long set of video. Hopefully he will reply positively to
do an extra set of short videos/screen only about embedded
features. That we could recommend as video-tutorials in peertube.

There is also Sacha Chua, Howard Abrams, Derek Banas. All of them with
good formatted (but usually long) videos about emacs.

I prefer screen only videos because are more useful but also because
after a first version it could be easier to create versions in different
languages with them.

BTW I just contacted a couple of Spanish emacs youtubers. I am waiting
for their reply if they are willing to migrate/port their videos to
peertube to start with something.

Maybe some others here could do the same to contact youtubers in their
languages?

Re: Changes for emacs 28

[Jose A. Ortega Ruiz]

On Fri, Sep 11 2020, Ergus wrote:

[...]

> There is also Sacha Chua, Howard Abrams, Derek Banas. All of them with
> good formatted (but usually long) videos about emacs.
>
> I prefer screen only videos because are more useful but also because
> after a first version it could be easier to create versions in different
> languages with them.

I would suggest taking a look also at Protesilaos Stavrou's screencasts
(https://protesilaos.com/codelog/): they're close to what you are
imagining, and he's already collaborating with Emacs as the author of
the recently added modus-operandi and modus-vivendi themes.

Cheers,
jao
-- 
What sane person could live in this world and not be crazy?
  -Ursula K. Le Guin, author

Re: Changes for emacs 28

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

I don't know whether we can link to peertube.org.  Please tell me a URL
and I will check it.

  > >Yes, it's possible to create a channel
  > >
  > >     https://docs.joinpeertube.org/#/use-create-upload-video

That URL leads me to worry that its handling depends on JS code!


-- 
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: Changes for emacs 28

[Göktuğ Kayaalp]

On 2020-09-12 06:21 +03, Richard Stallman <rms@gnu.org> wrote:
> That URL leads me to worry that its handling depends on JS code!

It does, but it’s free software (AGPL 3.0).

They also are based on FOSS tech like ActivityPub and WebTorrent, and
mpv handles video urls just fine (I have version 0.32.0 from Linux Mint
20 repos).

--
İ. Göktuğ Kayaalp / @cadadr / <https://www.gkayaalp.com/>
pgp:   024C 30DD 597D 142B 49AC 40EB 465C D949 B101 2427

Re: Changes for emacs 28

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

  > > That URL leads me to worry that its handling depends on JS code!

  > It does, but it’s free software (AGPL 3.0).

In a moral sense, that changes things.  If you suggest that a person
use Peertube, explaining that its JS code actually is free (supposing
you've verified that every script is indeed licenses that way), you're
not doing anything bad.

But we can't take that approach that when we refer the pubilc to
sites, because that approach does not scale.  It is not practical to
tell people, "The following 156 sites send only free JS code, even
though you can't verify that because the code isn't labeled for
LibreJS."  Advice of that form is too hard for people to follow, since
they can't remember those sites.  Therefore, giving such advice is
self-defeating.

We must refer only to sites that clearly label their JS code with
licenses, so that LibreJS can verify it for the user.

-- 
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: Changes for emacs 28

[Arthur Miller]

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. ]]]
>
> Does anyone want to _make_ videos for Emacs?
>
> It is no use discussing what sort of videos we
> would like if nobody wants to make them.
> Let's stick to ideas we can implement.
I am not the one, but looking at Youtube/Vimeo there are people who like
to make those; some people have series of videos. Maybe if you raised
question/call in "social media platforms" and proposed the content for
"episodes" maybe some people would take a provided "scenario" and turn
it into a video? Another solution is maybe to raise community funding
and pay some pro to make the desired content? But I think the first one
is more realistic :-).

By the way, I don't think the video content has to be done as real video
with a person talking in microfon and all that. It is common in some
graphical and 3d packages to have short "feature videos" where they
highlight some specific, or new, feature which is essentially just
someone clicking in gui and doing something basic just to showe where
the feature is and how it works. I think those are usually just scripted
and recorded as gif/png images and turned into some flv/mpg video or
similar. This kind of video can be done by anyone who knows how to use a
feature and if I am not wrong there is a screencast recorder for Emacs
already (requires external software).

Maybe video is not important at all since Emacs can be scripted; maybe
it is possible to script (macro) a "video" in Elisp; so when a demo is
called it would replay the gui/lisp actions like a macro?

Re: Changes for emacs 28

[Ricardo Wurmus]

Arthur Miller <arthur.miller@live.com> writes:

> Maybe video is not important at all since Emacs can be scripted; maybe
> it is possible to script (macro) a "video" in Elisp; so when a demo is
> called it would replay the gui/lisp actions like a macro?

The Guix videos at https://guix.gnu.org/videos/ were made with a
pipeline that assembles slides and scripted text:

    https://git.savannah.gnu.org/cgit/guix/videos.git

The core is a little Guile thing that interprets a scripted session
(like this: [1]) and produces a bunch of frames that are then assembled
with ffmpeg.

We built this pipeline to allow for easy translation of these videos.
To manage expectations: the intended effect is that of a narrated
slideshow presentation with little shell demos here and there.

Maybe parts of this workflow could be useful to those that would like to
build videos for Emacs.

[1]: https://git.savannah.gnu.org/cgit/guix/videos.git/tree/04-packaging1/en_US/sessions/firstCli

-- 
Ricardo

Re: Changes for emacs 28

[Arthur Miller]

Ricardo Wurmus <rekado@elephly.net> writes:

> Arthur Miller <arthur.miller@live.com> writes:
>
>> Maybe video is not important at all since Emacs can be scripted; maybe
>> it is possible to script (macro) a "video" in Elisp; so when a demo is
>> called it would replay the gui/lisp actions like a macro?
>
> The Guix videos at https://guix.gnu.org/videos/ were made with a
> pipeline that assembles slides and scripted text:
>
>     https://git.savannah.gnu.org/cgit/guix/videos.git
>
> The core is a little Guile thing that interprets a scripted session
> (like this: [1]) and produces a bunch of frames that are then assembled
> with ffmpeg.
>
> We built this pipeline to allow for easy translation of these videos.
> To manage expectations: the intended effect is that of a narrated
> slideshow presentation with little shell demos here and there.
>
> Maybe parts of this workflow could be useful to those that would like to
> build videos for Emacs.
>
> [1]: https://git.savannah.gnu.org/cgit/guix/videos.git/tree/04-packaging1/en_US/sessions/firstCli

I don't know how they look like, but probably. Can you record one of
those with a screen recorder and upload it somewhere as a demo how it
look like when in "action"?

Re: Changes for emacs 28

[Ricardo Wurmus]

Arthur Miller <arthur.miller@live.com> writes:

> Ricardo Wurmus <rekado@elephly.net> writes:
>
>> Arthur Miller <arthur.miller@live.com> writes:
>>
>>> Maybe video is not important at all since Emacs can be scripted; maybe
>>> it is possible to script (macro) a "video" in Elisp; so when a demo is
>>> called it would replay the gui/lisp actions like a macro?
>>
>> The Guix videos at https://guix.gnu.org/videos/ were made with a
>> pipeline that assembles slides and scripted text:
>>
>>     https://git.savannah.gnu.org/cgit/guix/videos.git
>>
>> The core is a little Guile thing that interprets a scripted session
>> (like this: [1]) and produces a bunch of frames that are then assembled
>> with ffmpeg.
>>
>> We built this pipeline to allow for easy translation of these videos.
>> To manage expectations: the intended effect is that of a narrated
>> slideshow presentation with little shell demos here and there.
>>
>> Maybe parts of this workflow could be useful to those that would like to
>> build videos for Emacs.
>>
>> [1]: https://git.savannah.gnu.org/cgit/guix/videos.git/tree/04-packaging1/en_US/sessions/firstCli
>
> I don't know how they look like, but probably. Can you record one of
> those with a screen recorder and upload it somewhere as a demo how it
> look like when in "action"?

I linked to them above:

   https://guix.gnu.org/videos/

All of these videos were made with this pipeline.

-- 
Ricardo

Re: Changes for emacs 28

[Arthur Miller]

Ricardo Wurmus <rekado@elephly.net> writes:

> Arthur Miller <arthur.miller@live.com> writes:
>
>> Ricardo Wurmus <rekado@elephly.net> writes:
>>
>>> Arthur Miller <arthur.miller@live.com> writes:
>>>
>>>> Maybe video is not important at all since Emacs can be scripted; maybe
>>>> it is possible to script (macro) a "video" in Elisp; so when a demo is
>>>> called it would replay the gui/lisp actions like a macro?
>>>
>>> The Guix videos at https://guix.gnu.org/videos/ were made with a
>>> pipeline that assembles slides and scripted text:
>>>
>>>     https://git.savannah.gnu.org/cgit/guix/videos.git
>>>
>>> The core is a little Guile thing that interprets a scripted session
>>> (like this: [1]) and produces a bunch of frames that are then assembled
>>> with ffmpeg.
>>>
>>> We built this pipeline to allow for easy translation of these videos.
>>> To manage expectations: the intended effect is that of a narrated
>>> slideshow presentation with little shell demos here and there.
>>>
>>> Maybe parts of this workflow could be useful to those that would like to
>>> build videos for Emacs.
>>>
>>> [1]: https://git.savannah.gnu.org/cgit/guix/videos.git/tree/04-packaging1/en_US/sessions/firstCli
>>
>> I don't know how they look like, but probably. Can you record one of
>> those with a screen recorder and upload it somewhere as a demo how it
>> look like when in "action"?
>
> I linked to them above:
I am sorry my bed; I actually saw them but didn't realized they were
what you wrote about :-). Yes, it looks good, I think something similar
would be be great for Emacs. 

RE: Changes for emacs 28

[Drew Adams]

> and these options would be written in their .emacs file.

Just a nit about this part.

I really think we should get away from having Emacs
fiddle with users' init files.

For Customize, we should encourage use of `custom-file'.

For other, similar things (such as what you suggest),
we should similarly provide for Emacs to record
<whatever> in a file other than the init file.

An init file should be pretty much reserved for users.
Emacs and its libraries should try to stay away from it.
___


[For some reason, when I do `Reply All' for your
messages emacs-devel is not in the To or CC list.
Had to send this again, adding emacs-devel explicitly.]

Re: Changes for emacs 28

[Robert Pluim]

>>>>> On Wed, 9 Sep 2020 09:15:58 -0700 (PDT), Drew Adams <drew.adams@oracle.com> said:

    Drew> [For some reason, when I do `Reply All' for your
    Drew> messages emacs-devel is not in the To or CC list.
    Drew> Had to send this again, adding emacs-devel explicitly.]

Gregory has a 'Reply-To' header which points at ghe@sdf.org. I guess
your Outlook client honours it a bit too much

Robert

Re: Changes for emacs 28

[Gregory Heytings via Emacs development discussions.]

>
> Gregory has a 'Reply-To' header which points at ghe@sdf.org. I guess 
> your Outlook client honours it a bit too much
>

Indeed.  I know this, but I don't know why this is the case (*).  I used 
to explicitly set Reply-To to emacs-devel@gnu.org in my MUA, but Eli asked 
me to stop to do this.

(*) I guess, but I'm not 100% sure, that Mailman honors the strict DMARC 
policy ("quarantine") of the the sdf.org domain.  So mails sent from that 
domain are forwared to the list with a "From: emacs-devel@gnu.org 
Reply-To: <original sender>" while those sent from other domains are 
forwared to the list with a "From: <original sender>".

Re: Changes for emacs 28

[Robert Pluim]

>>>>> On Thu, 10 Sep 2020 12:26:15 +0000, Gregory Heytings <ghe@sdf.org> said:

    >> 
    >> Gregory has a 'Reply-To' header which points at ghe@sdf.org. I guess
    >> your Outlook client honours it a bit too much
    >> 

    Gregory> Indeed.  I know this, but I don't know why this is the case (*).  I
    Gregory> used to explicitly set Reply-To to emacs-devel@gnu.org in my MUA, but
    Gregory> Eli asked me to stop to do this.

I think in that case rmail replies only to emacs-devel@, which means
Eli has to add back the other recipients. Eli, do we need a "reply to
'From+To+CC+Reply-To'" feature in rmail? ("wide reply" in Gnus parlance).

    Gregory> (*) I guess, but I'm not 100% sure, that Mailman honors the strict
    Gregory> DMARC policy ("quarantine") of the the sdf.org domain.  So mails sent
    Gregory> from that domain are forwared to the list with a "From:
    Gregory> emacs-devel@gnu.org Reply-To: <original sender>" while those sent from
    Gregory> other domains are forwared to the list with a "From: <original
    sender> ".

Yes, that matches the Mailman documentation. Iʼm not sure what a good
solution is; Mailman adding a Reply-To with both the sender and
emacs-devel would no doubt also break either Outlook or rmail or
both. Not adding a Reply-To at all means the sender would get dropped
<sigh>.

Robert

Re: Changes for emacs 28

[Gregory Heytings via Emacs development discussions.]

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


>
> Yes, that matches the Mailman documentation. Iʼm not sure what a good 
> solution is; Mailman adding a Reply-To with both the sender and 
> emacs-devel would no doubt also break either Outlook or rmail or both. 
> Not adding a Reply-To at all means the sender would get dropped <sigh>.
>

In fact not adding a Reply-To would be perfect, at least for me. 
Presumably someone who sends a message to a list has subscribed to the 
list, of if they are not, it's common to mention explicitly that they are 
not.

Re: Changes for emacs 28

[Robert Pluim]

>>>>> On Thu, 10 Sep 2020 13:04:47 +0000, Gregory Heytings <ghe@sdf.org> said:

    >> 
    >> Yes, that matches the Mailman documentation. Iʼm not sure what a
    >> good solution is; Mailman adding a Reply-To with both the sender and
    >> emacs-devel would no doubt also break either Outlook or rmail or
    >> both. Not adding a Reply-To at all means the sender would get
    >> dropped <sigh>.
    >> 

    Gregory> In fact not adding a Reply-To would be perfect, at least for
    Gregory> me. Presumably someone who sends a message to a list has subscribed to
    Gregory> the list, of if they are not, it's common to mention explicitly that
    Gregory> they are not.

That works if their email address is mentioned in one of the headers
of the message, but in this case yours wouldnʼt be (unless you CC
yourself explicitly, which is an imposition on the sender)

DMARC/DKIM/SPF, what hath ye wrought?

Robert

Re: Changes for emacs 28

[Gregory Heytings via Emacs development discussions.]

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


>
>> In fact not adding a Reply-To would be perfect, at least for me. 
>> Presumably someone who sends a message to a list has subscribed to the 
>> list, of if they are not, it's common to mention explicitly that they 
>> are not.
>
> That works if their email address is mentioned in one of the headers of 
> the message, but in this case yours wouldnʼt be
>

Hmmm... Why should my address be mentioned in one of the headers of the 
message?  A "From emacs-devel@gnu.org To emacs-devel@gnu.org" or a "From 
emacs-devel@gnu.org To <someone> Cc emacs-devel@gnu.org" would be 
perfectly fine.  There is no need (in my case at least) to add a 
"Reply-To".

Re: Changes for emacs 28

[Robert Pluim]

>>>>> On Thu, 10 Sep 2020 14:16:45 +0000, Gregory Heytings <ghe@sdf.org> said:

    >> 
    >>> In fact not adding a Reply-To would be perfect, at least for
    >>> me. Presumably someone who sends a message to a list has subscribed
    >>> to the list, of if they are not, it's common to mention explicitly
    >>> that they are not.
    >> 
    >> That works if their email address is mentioned in one of the headers
    >> of the message, but in this case yours wouldnʼt be
    >> 

    Gregory> Hmmm... Why should my address be mentioned in one of the headers of
    Gregory> the message?  A "From emacs-devel@gnu.org To emacs-devel@gnu.org" or a
    Gregory> "From emacs-devel@gnu.org To <someone> Cc emacs-devel@gnu.org" would
    Gregory> be perfectly fine.  There is no need (in my case at least) to add a
    Gregory> "Reply-To".

Yes, but you get mail sent to emacs-devel. Not everyone who sends to
emacs-devel is subscribed to it, nor do they all read it via gmane.io
like I do (or some other method of getting it). The polite assumption
is to CC the originator of the message, just in case, which is what
Drew did.

Robert

Re: Changes for emacs 28

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Date: Thu, 10 Sep 2020 14:52:49 +0200
> Cc: Lars Ingebrigtsen <larsi@gnus.org>, Drew Adams <drew.adams@oracle.com>,
>  Emacs developers <emacs-devel@gnu.org>
> 
>     Gregory> Indeed.  I know this, but I don't know why this is the case (*).  I
>     Gregory> used to explicitly set Reply-To to emacs-devel@gnu.org in my MUA, but
>     Gregory> Eli asked me to stop to do this.
> 
> I think in that case rmail replies only to emacs-devel@, which means
> Eli has to add back the other recipients. Eli, do we need a "reply to
> 'From+To+CC+Reply-To'" feature in rmail? ("wide reply" in Gnus parlance).

I don't think I understand what that means (never used Gnus, sorry),
and don't remember the details of the issue.  But in general, why
would someone need to set Reply-To to the list address when replying
to a message from the list?  It should be automatic in any sensible
MUA, no?

Re: Changes for emacs 28

[Robert Pluim]

>>>>> On Thu, 10 Sep 2020 17:32:35 +0300, Eli Zaretskii <eliz@gnu.org> said:

    >> From: Robert Pluim <rpluim@gmail.com>
    >> Date: Thu, 10 Sep 2020 14:52:49 +0200
    >> Cc: Lars Ingebrigtsen <larsi@gnus.org>, Drew Adams <drew.adams@oracle.com>,
    >> Emacs developers <emacs-devel@gnu.org>
    >> 
    Gregory> Indeed.  I know this, but I don't know why this is the case (*).  I
    Gregory> used to explicitly set Reply-To to emacs-devel@gnu.org in my MUA, but
    Gregory> Eli asked me to stop to do this.
    >> 
    >> I think in that case rmail replies only to emacs-devel@, which means
    >> Eli has to add back the other recipients. Eli, do we need a "reply to
    >> 'From+To+CC+Reply-To'" feature in rmail? ("wide reply" in Gnus parlance).

    Eli> I don't think I understand what that means (never used Gnus, sorry),
    Eli> and don't remember the details of the issue.  But in general, why
    Eli> would someone need to set Reply-To to the list address when replying
    Eli> to a message from the list?  It should be automatic in any sensible
    Eli> MUA, no?

They wouldnʼt, but apparently Mailman sets 'Reply-To: ghe@sdf.org' on
Gregory's behalf, which then causes Outlook to respond only to him.

In Gnus, when I say 'wide reply', it hoovers up 'From,To,CC,Reply-To',
so that doesnʼt bother me. I donʼt know what rmail does, hence my
question.

Maybe Drew needs a different MUA? :-)

Robert

Re: Changes for emacs 28

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: ghe@sdf.org,  larsi@gnus.org,  drew.adams@oracle.com,  emacs-devel@gnu.org
> Date: Thu, 10 Sep 2020 16:56:07 +0200
> 
>     Eli> I don't think I understand what that means (never used Gnus, sorry),
>     Eli> and don't remember the details of the issue.  But in general, why
>     Eli> would someone need to set Reply-To to the list address when replying
>     Eli> to a message from the list?  It should be automatic in any sensible
>     Eli> MUA, no?
> 
> They wouldnʼt, but apparently Mailman sets 'Reply-To: ghe@sdf.org' on
> Gregory's behalf, which then causes Outlook to respond only to him.

Then maybe Gregory should take this up with GNU folks who oversee the
mailing lists?

Or maybe how should do something to stop Mailman from mangling his
From address?

> In Gnus, when I say 'wide reply', it hoovers up 'From,To,CC,Reply-To',
> so that doesnʼt bother me. I donʼt know what rmail does, hence my
> question.

Rmail does the same, in general.

> Maybe Drew needs a different MUA? :-)

Definitely, but that's out of our control.

Re: Changes for emacs 28

[Robert Pluim]

>>>>> On Thu, 10 Sep 2020 18:03:20 +0300, Eli Zaretskii <eliz@gnu.org> said:

    >> From: Robert Pluim <rpluim@gmail.com>
    >> Cc: ghe@sdf.org,  larsi@gnus.org,  drew.adams@oracle.com,  emacs-devel@gnu.org
    >> Date: Thu, 10 Sep 2020 16:56:07 +0200
    >> 
    Eli> I don't think I understand what that means (never used Gnus, sorry),
    Eli> and don't remember the details of the issue.  But in general, why
    Eli> would someone need to set Reply-To to the list address when replying
    Eli> to a message from the list?  It should be automatic in any sensible
    Eli> MUA, no?
    >> 
    >> They wouldnʼt, but apparently Mailman sets 'Reply-To: ghe@sdf.org' on
    >> Gregory's behalf, which then causes Outlook to respond only to him.

    Eli> Then maybe Gregory should take this up with GNU folks who oversee the
    Eli> mailing lists?

Itʼs not (directly) under their control.

    Eli> Or maybe how should do something to stop Mailman from mangling his
    Eli> From address?

I donʼt think he can: thatʼs under the control of whoever looks after
the sdf.org domain setup.

Anyway, this is not really relevant to Emacs development anymore.

Robert

RE: Changes for emacs 28

[Drew Adams]

> Maybe Drew needs a different MUA? :-)

Maybe that ain't gonna happen. ;-)

RE: Changes for emacs 28

[Drew Adams]

>     Drew> [For some reason, when I do `Reply All' for your
>     Drew> messages emacs-devel is not in the To or CC list.
>     Drew> Had to send this again, adding emacs-devel explicitly.]
> 
> Gregory has a 'Reply-To' header which points at ghe@sdf.org. I guess
> your Outlook client honours it a bit too much

Thanks for the reply.

Maybe so.  I know nothing about such things, and
I don't really want to start fiddling with them.

Outlook "just works" for me, with lots of mailing
lists and lots of interlocutors.  I've seen this
problem only a few times, with a few correspondents.

IOW, "not my problem", at least not enough that
I'd care to try to fix it on my end.

Re: Changes for emacs 28

[Lars Ingebrigtsen]

Drew Adams <drew.adams@oracle.com> writes:

> Maybe so.  I know nothing about such things, and
> I don't really want to start fiddling with them.
>
> Outlook "just works" for me, with lots of mailing
> lists and lots of interlocutors.  I've seen this
> problem only a few times, with a few correspondents.

You're going to see it more and more with mailing lists.  A person with
a strict SPF/DMARC policy (and that's getting more and more common) has
to have their From addresses rewritten by the mailing list software so
that the mail isn't tagged as spam, which is why (for instance)
Gregory's From header looks like:

From: Gregory Heytings via "Emacs development discussions." <emacs-devel@gnu.org>

The mailing list software puts the original From in the Reply-To header
after doing this rewrite, and if you have software that (on a "wide
reply") just sends the response to the Reply-To header, you end up in
this mess.

We all have to deal with the fallout of this debacle called "modern
email".  Fortunately, all the Emacs mail user agents all do the right
thing here, so it's normally not a problem, but if Outlook does
something insane (and when doesn't it?), you're going to have to adjust.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

RE: Changes for emacs 28

[Drew Adams]

> >> and these options would be written in their .emacs file.
> >
> > Just a nit about this part.
> >
> > I really think we should get away from having Emacs fiddle with users'
> > init files.
> >
> > For Customize, we should encourage use of `custom-file'.
> 
> I agree with you that in general Emacs should better not fiddle with
> users' init files, but not in this particular case.  This would happen
> only for first-time users who, as I said, do not yet have a .emacs file /
> .emacs.d directory.  Populating that file / directory with the result of
> their choices during the initial "guided tour" makes perfect sense.  IOW,
> this would happen only the first time they start Emacs.

Even so.  It doesn't matter how or when or why Emacs
writes to a user's init file.  The effect is the same:
mixing automatic, programmatic edits with user edits
(even if there not yet any user edits).

It's fine, IMO, for Emacs to prompt for where to record
something.

It could even be OK (but not as nice) for Emacs to
automatically put something in a file in ~/.emacs.d, as
the default directory for something.

What I think is not OK is for Emacs to put stuff in a
user's init file, whether that be the default location
and name of an init file or an init file with some other
location and name.

`custom-file' is the right place for Customize to put
and edit stuff.  For what you propose, some other file
can be chosen.  It just shouldn't be a file that is
intended for user editing - in particular, the user's
init file.

Re: Changes for emacs 28

[Juri Linkov]

> During that "guided tour" the user could select a number of options,
> e.g. cua-mode, evil-mode, which-key, hl-line, show-paren-mode, a theme

+1  For each profile (a combination of the most popular features)
show a screenshot, short description and checkbox "Enable".

Re: Changes for emacs 28

[Juri Linkov]

>> During that "guided tour" the user could select a number of options,
>> e.g. cua-mode, evil-mode, which-key, hl-line, show-paren-mode, a theme
>
> +1  For each profile (a combination of the most popular features)
> show a screenshot, short description and checkbox "Enable".

That means that like Custom-save adds the saved variable/value to the
init/custom file, enabling this checkbox should add 'use-package' to the
init file (and evaluate it immediately).

Re: Changes for emacs 28

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

  > Would it not be better to have a "guided tour" (something like C-h t, but 
  > shorter and more "modern") for first-time users (those without a .emacs / 
  > .emacs.d)?  This is quite common in "modern" software, so it would not 
  > surprise anyone.

We discussed this a few months ago and it turned out someone had made
such a tour.  I can't recall whether we could, or could not, make use of 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: Changes for emacs 28

[Yoni Rabkin]

Ergus <spacibba@aol.com> writes:

> I am NOT telling we should do all this, but this is what a young user
> expects because all these is more or less standard everywhere else.

I appreciate you enthusiasm for making Emacs popular. Thank you for
that.

However, it is always jarring to me to see free software developers
arguing over features none of them like or want, and instead trying to
"prove" to the other that a hypothetical third person would really like
those features. This supposed "young user" is a pretend person; they
don't exist. People ascribe whatever properties they want to the poor
hypothetical "young user" and then argue that those properties require a
change in Emacs. I disagree with this approach because I think that real
people and their preferences are more complicated and subtle than any
person we can make up as a tool to back an argument.

If you want these features yourself then you should add them (I don't
mean that in a sarcastic way at all). Your enthusiasm for creating and
maintaining these features will appeal to others who want similar
features. We all know and love this way of development in the free
software development world. This way assures that at least one real
person's needs are being met.

If you don't want these features yourself and nobody else in the project
wants them either, the only way I can think of making a compelling
argument for people to develop those feature is to ask real people and
get real responses. I am fairly confident that if you had a testimony or
user-test from actual people stating that a feature is missing, then
people here would help develop that feature.

I develop Emacs extensions (Emms, rt-liberation in GNU ELPA, and others
outside of it). I never try to guess what a hypothetical person wants
from Emms, but I do actively solicit requests and suggestions from
anyone I can, and when someone cares enough to ask for a feature, I do
everything I can to add it. Indeed, Emms has several extensions and
modes that I never use and can't even wrap my head around why people
like. But real people asked for them, so they are there.

-- 
   "Cut your own wood and it will warm you twice"

Re: Changes for emacs 28

[Ergus]

On Mon, Sep 07, 2020 at 09:58:32AM -0400, Yoni Rabkin wrote:
>
>Ergus <spacibba@aol.com> writes:
>
>> I am NOT telling we should do all this, but this is what a young user
>> expects because all these is more or less standard everywhere else.
>
>I appreciate you enthusiasm for making Emacs popular. Thank you for
>that.
>
>However, it is always jarring to me to see free software developers
>arguing over features none of them like or want, and instead trying to
>"prove" to the other that a hypothetical third person would really like
>those features. This supposed "young user" is a pretend person; they
>don't exist. People ascribe whatever properties they want to the poor
>hypothetical "young user" and then argue that those properties require a
>change in Emacs. I disagree with this approach because I think that real
>people and their preferences are more complicated and subtle than any
>person we can make up as a tool to back an argument.
>
The post actually started not for adding new features, but just to
change some of our defaults. Actually one thing I don't like about doom
or spacemacs is the excessive complexity they add and long configuration
sets.

When I recommend Emacs to any of my students; after a week trying it
they finally go for VSCode or sublime and they get the work done in an
hour.

Actually I have this config I share with them with only vanilla features:

https://github.com/Ergus/mini_dotemacs

And so far I could convince at least some of them this year.

>If you want these features yourself then you should add them (I don't
>mean that in a sarcastic way at all). Your enthusiasm for creating and
>maintaining these features will appeal to others who want similar
>features. We all know and love this way of development in the free
>software development world. This way assures that at least one real
>person's needs are being met.
>
Again, are not features the "issue", but some "bad" defaults. If there
come out specific features I will try (as I am doing actually with
vertical-icomplete or highlight-completions).

The question to the developers was about defaults we would be willing to
change and which are whiten in stone.

>If you don't want these features yourself and nobody else in the project
>wants them either, the only way I can think of making a compelling
>argument for people to develop those feature is to ask real people and
>get real responses. I am fairly confident that if you had a testimony or
>user-test from actual people stating that a feature is missing, then
>people here would help develop that feature.
>
Actually as mentioned before, the existence of doom emacs, spacemacs and
all the other configs (some of them more popular than vanilla these
days) is a proof.

>I develop Emacs extensions (Emms, rt-liberation in GNU ELPA, and others
>outside of it). I never try to guess what a hypothetical person wants
>from Emms, but I do actively solicit requests and suggestions from
>anyone I can, and when someone cares enough to ask for a feature, I do
>everything I can to add it. Indeed, Emms has several extensions and
>modes that I never use and can't even wrap my head around why people
>like. But real people asked for them, so they are there.
>
I am adding changes to completions and icomplete while I use ivy.

>-- 
>   "Cut your own wood and it will warm you twice"

Re: Changes for emacs 28

[Yoni Rabkin]

Ergus <spacibba@aol.com> writes:

> On Mon, Sep 07, 2020 at 09:58:32AM -0400, Yoni Rabkin wrote:
>>
>>Ergus <spacibba@aol.com> writes:
>>
>>> I am NOT telling we should do all this, but this is what a young user
>>> expects because all these is more or less standard everywhere else.
>>
>>I appreciate you enthusiasm for making Emacs popular. Thank you for
>>that.
>>
>>However, it is always jarring to me to see free software developers
>>arguing over features none of them like or want, and instead trying to
>>"prove" to the other that a hypothetical third person would really like
>>those features. This supposed "young user" is a pretend person; they
>>don't exist. People ascribe whatever properties they want to the poor
>>hypothetical "young user" and then argue that those properties require a
>>change in Emacs. I disagree with this approach because I think that real
>>people and their preferences are more complicated and subtle than any
>>person we can make up as a tool to back an argument.
>>
> The post actually started not for adding new features, but just to
> change some of our defaults. Actually one thing I don't like about doom
> or spacemacs is the excessive complexity they add and long configuration
> sets.

Configuration defaults, configurability, and features are
interchangeable in this discussion.

> When I recommend Emacs to any of my students; after a week trying it
> they finally go for VSCode or sublime and they get the work done in an
> hour.

That's an interesting initial point, but I don't follow the leap you
made since there are no details. You are trying to make a strong point
in comparing a week of failure to an hour of success. But unfortunately
that doesn't explain what needs to be changed.

> Actually I have this config I share with them with only vanilla features:
>
> https://github.com/Ergus/mini_dotemacs
>
> And so far I could convince at least some of them this year.

Convince to do what? Have they been convinced to move to Emacs as a
development platform going forward? To use Emacs just for the course? To
value software freedom?

Conversely, if they used "sublime" (which I assume is an editor) for
that university course, does that mean that they have rejected software
freedom in some way? Does that mean they are now life-long sublime
users? Do they also read their email, browse the web, listen to music,
watch videos, and interface with task-management systems via sublime?

I hope those questions don't come across as badgering. Instead, I'm
trying to point out that the conclusions you've come to aren't implied
by the information you've provided.

If you've found a way to provide a popular configuration for Emacs for
your university environment, it may make sense to package that and make
it easy to install. After all, the power of Emacs is in what it can
become, as opposed to what it is when you load it.


>>If you want these features yourself then you should add them (I don't
>>mean that in a sarcastic way at all). Your enthusiasm for creating and
>>maintaining these features will appeal to others who want similar
>>features. We all know and love this way of development in the free
>>software development world. This way assures that at least one real
>>person's needs are being met.
>>
> Again, are not features the "issue", but some "bad" defaults. If there
> come out specific features I will try (as I am doing actually with
> vertical-icomplete or highlight-completions).
>
> The question to the developers was about defaults we would be willing
> to change and which are whiten in stone.

The loud introduction screen to Emacs is what made me aware of the
existence of the free software movement about 20 years ago. It would not
be hyperbole to say that particular default changed the course of my
life.

If there is such a thing as an ideal default for Emacs, it would be
being presented with a screen that succinctly explains the free software
movement and the endless possibilities of Emacs as a platform.

I would try to argue for a robust and easy way for you to be able to
provide people with the kind of setup for Emacs that you are obviously
enthusiastic about, regardless of how Emacs loads. If you can't do that,
then to my mind Emacs is indeed missing something.


>>If you don't want these features yourself and nobody else in the project
>>wants them either, the only way I can think of making a compelling
>>argument for people to develop those feature is to ask real people and
>>get real responses. I am fairly confident that if you had a testimony or
>>user-test from actual people stating that a feature is missing, then
>>people here would help develop that feature.
>>
> Actually as mentioned before, the existence of doom emacs, spacemacs and
> all the other configs (some of them more popular than vanilla these
> days) is a proof.

I'm unsure of what you mean by that. If those have features that GNU
Emacs doesn't and that you want, then you should port them
over. Unfortunately, I have a feeling we may be talking past each other
on this point.

-- 
   "Cut your own wood and it will warm you twice"

Re: Changes for emacs 28

[Ergus]

On Mon, Sep 07, 2020 at 11:19:44AM -0400, Yoni Rabkin wrote:
>Ergus <spacibba@aol.com> writes:
>
>
>Configuration defaults, configurability, and features are
>interchangeable in this discussion.
>
No, they aren't. New features need to be implemented new defaults is
actually something that comes out of the box.

>
>That's an interesting initial point, but I don't follow the leap you
>made since there are no details. You are trying to make a strong point
>in comparing a week of failure to an hour of success. But unfortunately
>that doesn't explain what needs to be changed.
>
This was just an example and a personal anecdote to show that some
better defaults are possible without too much effort to "attract" fresh
blood to emacs.

>
>Convince to do what? Have they been convinced to move to Emacs as a
>development platform going forward? To use Emacs just for the course? To
>value software freedom?
>
As of today people start appreciating free software if they see it is
useful. If they go for geany or vim it is also free software, but as
emacs developers we should be concerned why if this becomes frequent
pattern (that people try and not stay enough to discover the rest).

>Conversely, if they used "sublime" (which I assume is an editor) for
>that university course, does that mean that they have rejected software
>freedom in some way? Does that mean they are now life-long sublime
>users? Do they also read their email, browse the web, listen to music,
>watch videos, and interface with task-management systems via sublime?
>
FWIS people come to emacs looking for the basic feature: an editor (with
steroids).

If that is no as satisfying as they expect (or has disadvantages over
gedit, sublime or any other, or require 300 lines of configurations for
the basics) then they don't stay enough to discover the rest.

>I hope those questions don't come across as badgering. Instead, I'm
>trying to point out that the conclusions you've come to aren't implied
>by the information you've provided.
>
>If you've found a way to provide a popular configuration for Emacs for
>your university environment, it may make sense to package that and make
>it easy to install. After all, the power of Emacs is in what it can
>become, as opposed to what it is when you load it.
>
>
Yes, but it doesn't mean that we have to provide the worst possible
defaults.
>
>I would try to argue for a robust and easy way for you to be able to
>provide people with the kind of setup for Emacs that you are obviously
>enthusiastic about, regardless of how Emacs loads. If you can't do that,
>then to my mind Emacs is indeed missing something.
>
That's the point. Emacs can do so (and much more) but users need to stay
enough to discover that, learn the environment and so on. I was just
talking about THAT first impression to keep them more than 10 minute and
think it worth cross the barrier if the new bindings, no right click for
everything and so on.

>
>I'm unsure of what you mean by that. If those have features that GNU
>Emacs doesn't and that you want, then you should port them
>over. Unfortunately, I have a feeling we may be talking past each other
>on this point.
>
>-- 
>   "Cut your own wood and it will warm you twice"

Re: Changes for emacs 28

[Mario Lang]

Ergus <spacibba@aol.com> writes:

> Actually as mentioned before, the existence of doom emacs, spacemacs and
> all the other configs (some of them more popular than vanilla these
> days) is a proof.

Actually, popularity is not the only measure of quality, if at all.
If popularity were all that counts, we would all be listening to Lady
Gaga and there would be no need for any other music.

-- 
CYa,
  ⡍⠁⠗⠊⠕

Re: Changes for emacs 28

[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 you don't want these features yourself and nobody else in the project
  > wants them either, the only way I can think of making a compelling
  > argument for people to develop those feature is to ask real people and
  > get real responses. I am fairly confident that if you had a testimony or
  > user-test from actual people stating that a feature is missing, then
  > people here would help develop that feature.

I agree.  Before we put time into developing a feature, we should verify
that many people would like it.

Speaking of which, it would be useful to sit down with a new user just
trying Emacs and see what perse actually complains about or requests.
If several people do this, it could give us useful ideas of what changes
would actually make Emacs more appealing to new users.

-- 
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: Changes for emacs 28

[Ihor Radchenko]

> Speaking of which, it would be useful to sit down with a new user just
> trying Emacs and see what perse actually complains about or requests.
> If several people do this, it could give us useful ideas of what changes
> would actually make Emacs more appealing to new users.

There are three main things I spotted when guiding a new
(non-programmer) user getting started with Emacs (for org-mode):

1. The welcome screen has too much information and new user simply
ignores it

2. CUA mode is not offered by default and it is not easy for a new user
to know about its existence (because of previous point)

3. File opening dialogue is completely throwing the new user off -
people are too used to pop-up file opening dialogue listing all the
files. The message area is even not noticed.

More details and my suggestion on what can be done in my earlier
messages:
https://lists.gnu.org/archive/html/emacs-devel/2020-07/msg00335.html
https://lists.gnu.org/archive/html/emacs-devel/2020-07/msg00359.html

I will also attach the message texts below for convenience:

Message 1:
----------

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

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

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

Message 2:
------------

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

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

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

Best,
Ihor


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. ]]]
>
>   > If you don't want these features yourself and nobody else in the project
>   > wants them either, the only way I can think of making a compelling
>   > argument for people to develop those feature is to ask real people and
>   > get real responses. I am fairly confident that if you had a testimony or
>   > user-test from actual people stating that a feature is missing, then
>   > people here would help develop that feature.
>
> I agree.  Before we put time into developing a feature, we should verify
> that many people would like it.
>
> Speaking of which, it would be useful to sit down with a new user just
> trying Emacs and see what perse actually complains about or requests.
> If several people do this, it could give us useful ideas of what changes
> would actually make Emacs more appealing to new users.
>
> -- 
> 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: Changes for emacs 28

[Drew Adams]

> 3. File opening dialogue is completely throwing the new user off -
> people are too used to pop-up file opening dialogue listing all the
> files. The message area is even not noticed.

> 6. Some new users might be confused by default file open dialogie
> involving mode-line. I believe that similarly to CUA-mode, Emacs can
> emulate more standard approach by offering dired as a way to open files
> (not enabled by default, but offered as a customisation together with
> CUA-mode).

Doesn't menu File > Open File do what you request,
by default?  Likewise, other file operations, such
as File > Insert File, File > Save As, and File >
Open Directory.

On MS Windows, for example, this just uses the usual
Windows file selection dialog box.

This depends on the value of option `use-file-dialog',
but that's `t' by default (as is `use-dialog-box').

 "Non-nil means mouse commands use a file dialog to ask for files.
  This applies to commands from menus and tool bar buttons even when
  they are initiated from the keyboard.  If 'use-dialog-box' is nil,
  that disables the use of a file dialog, regardless of the value of
  this variable."

https://www.gnu.org/software/emacs/manual/html_node/emacs/Dialog-Boxes.html

RE: Changes for emacs 28

[Ihor Radchenko]

> Doesn't menu File > Open File do what you request,
> by default?  Likewise, other file operations, such
> as File > Insert File, File > Save As, and File >
> Open Directory.

Hmm. You are right. I thought that the problem was with Emacs defaults,
but it seems to be a problem with helm, which I asked to install at the
very beginning - it appears to override the file dialogue.

Best,
Ihor


Drew Adams <drew.adams@oracle.com> writes:

>> 3. File opening dialogue is completely throwing the new user off -
>> people are too used to pop-up file opening dialogue listing all the
>> files. The message area is even not noticed.
>
>> 6. Some new users might be confused by default file open dialogie
>> involving mode-line. I believe that similarly to CUA-mode, Emacs can
>> emulate more standard approach by offering dired as a way to open files
>> (not enabled by default, but offered as a customisation together with
>> CUA-mode).
>
> Doesn't menu File > Open File do what you request,
> by default?  Likewise, other file operations, such
> as File > Insert File, File > Save As, and File >
> Open Directory.
>
> On MS Windows, for example, this just uses the usual
> Windows file selection dialog box.
>
> This depends on the value of option `use-file-dialog',
> but that's `t' by default (as is `use-dialog-box').
>
>  "Non-nil means mouse commands use a file dialog to ask for files.
>   This applies to commands from menus and tool bar buttons even when
>   they are initiated from the keyboard.  If 'use-dialog-box' is nil,
>   that disables the use of a file dialog, regardless of the value of
>   this variable."
>
> https://www.gnu.org/software/emacs/manual/html_node/emacs/Dialog-Boxes.html

Re: Changes for emacs 28

[tomas]

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

On Tue, Sep 08, 2020 at 01:33:24PM +0800, Ihor Radchenko wrote:
> > Doesn't menu File > Open File do what you request,
> > by default? [...]

> Hmm. You are right. I thought that the problem was with Emacs defaults,
> but it seems to be a problem with <package> [...]

I'm sure there are a couple of things to learn from this, although
I can't quite put my finger on it. A try:

 - versatility vs. user experience fragmentation?
 - ease/difficulty of moving between Emacs "subworlds"?
 - opinionated/authoritarian vs. permissive/loosey-goosey?

Does software have a pedagogical duty? If yes, which one?

I think those questions have some relationship with Gnu's core values,
somehow.

Sorry for being so fuzzy.

Cheers
 - t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

RE: Changes for emacs 28

[Drew Adams]

> > Doesn't menu File > Open File do what you request,
> > by default?  Likewise, other file operations, such
> > as File > Insert File, File > Save As, and File >
> > Open Directory.
> 
> Hmm. You are right. I thought that the problem was with Emacs defaults,
> but it seems to be a problem with helm, which I asked to install at the
> very beginning - it appears to override the file dialogue.

Thanks for confirming.

In several cases, though it may not be systematic,
Emacs default behavior tries to present, by way of
menus, something closer to what new users might be
used to.  Another example is Edit > Cut|Copy|Paste.

CUA-mode is about keyboard-key (not menu) behavior.
And in general Emacs default key bindings are
closer to what most Emacs users use, as opposed to
what new users might be used to.

There's always room for improvement.  And indeed,
the menus have improved in this way over time, to
be more accommodating to new users.

Menus are an important way to discover features
and, yes, key bindings.  They can be a gateway to
more "emacsy" behavior.
____

In terms of discovering with menus, and at the
same time seeing the power/utility of keyboard
key bindings (completion, in particular), there
is library La Carte.

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

And vanilla Emacs has `tmm-menubar' (M-`).

RE: Changes for emacs 28

[Ihor Radchenko]

> There's always room for improvement.  And indeed,
> the menus have improved in this way over time, to
> be more accommodating to new users.
>
> Menus are an important way to discover features
> and, yes, key bindings.  They can be a gateway to
> more "emacsy" behavior.

Would it make sense to re-evaluate Xah Lee's suggestions about menu?
http://ergoemacs.org/emacs/modernization_menu.html

Best,
Ihor

Drew Adams <drew.adams@oracle.com> writes:

>> > Doesn't menu File > Open File do what you request,
>> > by default?  Likewise, other file operations, such
>> > as File > Insert File, File > Save As, and File >
>> > Open Directory.
>> 
>> Hmm. You are right. I thought that the problem was with Emacs defaults,
>> but it seems to be a problem with helm, which I asked to install at the
>> very beginning - it appears to override the file dialogue.
>
> Thanks for confirming.
>
> In several cases, though it may not be systematic,
> Emacs default behavior tries to present, by way of
> menus, something closer to what new users might be
> used to.  Another example is Edit > Cut|Copy|Paste.
>
> CUA-mode is about keyboard-key (not menu) behavior.
> And in general Emacs default key bindings are
> closer to what most Emacs users use, as opposed to
> what new users might be used to.
>
> There's always room for improvement.  And indeed,
> the menus have improved in this way over time, to
> be more accommodating to new users.
>
> Menus are an important way to discover features
> and, yes, key bindings.  They can be a gateway to
> more "emacsy" behavior.
> ____
>
> In terms of discovering with menus, and at the
> same time seeing the power/utility of keyboard
> key bindings (completion, in particular), there
> is library La Carte.
>
> https://www.emacswiki.org/emacs/LaCarte
>
> And vanilla Emacs has `tmm-menubar' (M-`).

RE: Changes for emacs 28

[Stefan Kangas]

Ihor Radchenko <yantar92@gmail.com> writes:

> Would it make sense to re-evaluate Xah Lee's suggestions about menu?
> http://ergoemacs.org/emacs/modernization_menu.html

These proposals look relevant to me, I think we should examine them in
more detail.  Could you submit that as a new bug report?

Re: Changes for emacs 28

[Eli Zaretskii]

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Wed, 9 Sep 2020 07:35:37 -0700
> Cc: spacibba@aol.com, emacs-devel@gnu.org
> 
> Ihor Radchenko <yantar92@gmail.com> writes:
> 
> > Would it make sense to re-evaluate Xah Lee's suggestions about menu?
> > http://ergoemacs.org/emacs/modernization_menu.html
> 
> These proposals look relevant to me, I think we should examine them in
> more detail.

Beware: they are outdated (more than 10 years old, and many items in
our menus were changed since then).  More importantly, Xah is known
to be violently anti-FSF/GNU, and even anti-RMS, let alone full of NIH
tendencies.  His recommendations are rarely provided with any
rationale except "the current situation is silly/stupid", and should
therefore be taken with a grain of salt.

That said, it is of course okay to consider the ideas that make sense,
but not just "because Xah said so".

> Could you submit that as a new bug report?

Separate bug reports for each item or a group of related items,
please.  Let's not have one bug report about dozens of menu items
unrelated to each other.

Re: Changes for emacs 28

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

>> Could you submit that as a new bug report?
>
> Separate bug reports for each item or a group of related items,
> please.  Let's not have one bug report about dozens of menu items
> unrelated to each other.

Indeed, thanks for pointing that out!

> Beware: they are outdated (more than 10 years old, and many items in
> our menus were changed since then).  More importantly, Xah is known
> to be violently anti-FSF/GNU, and even anti-RMS, let alone full of NIH
> tendencies.  His recommendations are rarely provided with any
> rationale except "the current situation is silly/stupid", and should
> therefore be taken with a grain of salt.
>
> That said, it is of course okay to consider the ideas that make sense,
> but not just "because Xah said so".

Thanks for explaining the background.

If someone does look over that list, they should check to see which are
still relevant and provide some rationale for the change.

Re: Changes for emacs 28

[Ihor Radchenko]

>> Beware: they are outdated (more than 10 years old, and many items in
>> our menus were changed since then).  More importantly, Xah is known
>> to be violently anti-FSF/GNU, and even anti-RMS, let alone full of NIH
>> tendencies.  His recommendations are rarely provided with any
>> rationale except "the current situation is silly/stupid", and should
>> therefore be taken with a grain of salt.
>>
>> That said, it is of course okay to consider the ideas that make sense,
>> but not just "because Xah said so".
> Thanks for explaining the background.
>
> If someone does look over that list, they should check to see which are
> still relevant and provide some rationale for the change.

That article is mostly reasonable, except some rants about FSF
"advertisement". I will double check with latest Emacs menu and split
the relevant suggestions from the article into separate bug reports.

Best,
Ihor




Stefan Kangas <stefankangas@gmail.com> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> Could you submit that as a new bug report?
>>
>> Separate bug reports for each item or a group of related items,
>> please.  Let's not have one bug report about dozens of menu items
>> unrelated to each other.
>
> Indeed, thanks for pointing that out!
>
>> Beware: they are outdated (more than 10 years old, and many items in
>> our menus were changed since then).  More importantly, Xah is known
>> to be violently anti-FSF/GNU, and even anti-RMS, let alone full of NIH
>> tendencies.  His recommendations are rarely provided with any
>> rationale except "the current situation is silly/stupid", and should
>> therefore be taken with a grain of salt.
>>
>> That said, it is of course okay to consider the ideas that make sense,
>> but not just "because Xah said so".
>
> Thanks for explaining the background.
>
> If someone does look over that list, they should check to see which are
> still relevant and provide some rationale for the change.

Re: Changes for emacs 28

[Eric S Fraga]

On Wednesday,  9 Sep 2020 at 18:20, Eli Zaretskii wrote:
> His recommendations are rarely provided with any rationale except "the
> current situation is silly/stupid", and should therefore be taken with
> a grain of salt.

My experience entirely and he's rather quick to insult if you disagree.
-- 
Eric S Fraga via Emacs 28.0.50 & org 9.3.7 on Debian bullseye/sid

Re: Changes for emacs 28

[Ihor Radchenko]

>> His recommendations are rarely provided with any rationale except "the
>> current situation is silly/stupid", and should therefore be taken with
>> a grain of salt.
>
> My experience entirely and he's rather quick to insult if you disagree.

FYI, When sharing the link, I did not imply that suggestions should be
accepted "because Xah said so". I did imply that they are worth
reviewing, because I found many of the suggestions in that article
reasonable. Regardless of the author.

Instead of discussing the author of the article, it would be better to
discuss concrete suggestions proposed there (or better wait a little
until I split them into separate bug reports and discuss one-by-one).

Best,
Ihor

Eric S Fraga <e.fraga@ucl.ac.uk> writes:

> On Wednesday,  9 Sep 2020 at 18:20, Eli Zaretskii wrote:
>> His recommendations are rarely provided with any rationale except "the
>> current situation is silly/stupid", and should therefore be taken with
>> a grain of salt.
>
> My experience entirely and he's rather quick to insult if you disagree.
> -- 
> Eric S Fraga via Emacs 28.0.50 & org 9.3.7 on Debian bullseye/sid

Re: Changes for emacs 28

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

  > 1. The welcome screen has too much information and new user simply
  > ignores it

What Emacs version were you using?

  > 3. File opening dialogue is completely throwing the new user off -

Can you say concretely what you mean by "file opening dialogue"?  We
don't use the term "dialogue", and I can't see how it fits anything in
Emacs.

-- 
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: Changes for emacs 28

[Ihor Radchenko]

>   > 1. The welcome screen has too much information and new user simply
>   > ignores it
>
> What Emacs version were you using?

I am on master.

Strictly speaking, it is not too much information (just single page),
but rather that the information does not look important. The guided tour
is grouped together with warranty and redistribution - things people
largely ignore.

I believe that it is better to put more emphasis on the guided tour (and
change the tour as I suggested in my email and later replying to the
request about tramp defaults with even more details).

Probably something like the following:

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

    First time using Emacs? Check out how it is different from other
                             editors:
           <larger font> Emacs Guided Tour </larger font>
               (if you don't, you may be confused)
        
Emacs Tutorial	Learn basic keystroke commands
Emacs Guided Tour	Overview of Emacs features at gnu.org
<...>

>   > 3. File opening dialogue is completely throwing the new user off -
>
> Can you say concretely what you mean by "file opening dialogue"?  We
> don't use the term "dialogue", and I can't see how it fits anything in
> Emacs.

That point can be disregarded. Emacs uses graphical dialog (see
`use-file-dialog') when user tries to open file from menu or toolbar,
but I did not know it because helm overrides that behaviour. I filed bug
report in helm. The problem should be fixed now.

Best,
Ihor

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. ]]]
>
>   > 1. The welcome screen has too much information and new user simply
>   > ignores it
>
> What Emacs version were you using?
>
>   > 3. File opening dialogue is completely throwing the new user off -
>
> Can you say concretely what you mean by "file opening dialogue"?  We
> don't use the term "dialogue", and I can't see how it fits anything in
> Emacs.
>
> -- 
> 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: Changes for emacs 28

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

  > Probably something like the following:

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

  >     First time using Emacs? Check out how it is different from other
  >                              editors:
  >            <larger font> Emacs Guided Tour </larger font>
  >                (if you don't, you may be confused)
        
  > Emacs Tutorial	Learn basic keystroke commands
  > Emacs Guided Tour	Overview of Emacs features at gnu.org
  > <...>

That is a concrete suggestion.

Does anyone remember how the discusstion of that video tour ended?
Can we use it?


  > That point can be disregarded. Emacs uses graphical dialog (see
  > `use-file-dialog') when user tries to open file from menu or toolbar,
  > but I did not know it because helm overrides that behaviour. I filed bug
  > report in helm. The problem should be fixed now.

Thanks for that help.

-- 
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: Changes for emacs 28

[Lars Ingebrigtsen]

Richard Stallman <rms@gnu.org> writes:

> Speaking of which, it would be useful to sit down with a new user just
> trying Emacs and see what perse actually complains about or requests.
> If several people do this, it could give us useful ideas of what changes
> would actually make Emacs more appealing to new users.

I don't think that's likely to result in anything very interesting,
really.

Looking at the runaway success of DOOM Emacs (or Spacemacs), they're
distributions created by people with a specific point of view, and with
a specific user interface vision in mind.  That can't be achieved by
a committee, and the results will be totally unsuitable for some people.

But I think that's what Emacs should support: Just like emacs-devel
doesn't bikeshed themes -- we just let whoever make them make them the
way they like, and then distribute the result -- we should create a way
to specify "layers", and then invite people to create them, without
micromanaging them.  And then distribute the result in vanilla Emacs,
but with an easy, obvious way for users to switch these "layers" on and
off.

I.e., I want the enthusiasm of these people making these distributions
to infect mainline Emacs.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Changes for emacs 28

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

  > > Speaking of which, it would be useful to sit down with a new user just
  > > trying Emacs and see what perse actually complains about or requests.
  > > If several people do this, it could give us useful ideas of what changes
  > > would actually make Emacs more appealing to new users.

  > I don't think that's likely to result in anything very interesting,
  > really.

I learned useful things from it in the past.

  > Looking at the runaway success of DOOM Emacs (or Spacemacs), they're
  > distributions created by people with a specific point of view, and with
  > a specific user interface vision in mind.  That can't be achieved by
  > a committee,

I believe you, but I don't think that is a useful direction for us to go.

I'm thinking about improving specific aspects of the Emacs interface
to make incremental changes.

-- 
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: Changes for emacs 28

[João Távora]

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

On Sun, Sep 6, 2020 at 5:34 PM Ergus <spacibba@aol.com> wrote:

> Sorry but I can't understand why "old" users, that can write lisp lines
> easily to their configs, can't understand that for new users (and
> younger ones) those lines sometimes takes hours or days (mainly because
> they don't know what/where/how to look for, and lisp is not so
> popular or familiar these days). And that the first impression when they
> open emacs is like going back to 1998.

I think this is a very compelling argument.

I have to say that even as a "old" (oldish) user who has learned
to cherish the medieval Emacs defaults and would be slightly
annoyed at seeing some new defaults that I would have to configure
away.  But precisely like Ergus argues, that's kind of easy for me,
and not for newcomers.

This point comes up here so often that probably someone has
already suggested this silly idea:  Why not have a -1998
(or -1334 (; ) startup switch for the old timers?

João Távora

[-- Attachment #2: Type: text/html, Size: 1310 bytes --]

Re: Changes for emacs 28

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

  > This point comes up here so often that probably someone has
  > already suggested this silly idea:  Why not have a -1998
  > (or -1334 (; ) startup switch for the old timers?

I like the idea, but this should be something to set in .emacs,
not a command-line option.

Does the minus sign stand for BC?  I don't think Emacs existed in the
time of the Third Dynasty of Ur.  I developed the first Emacs
in Babylon in -1765.

-- 
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: Changes for emacs 28

[Stefan Monnier]

> I developed the first Emacs in Babylon in -1765.

And according to Moore's law, the typical density of chips back then was
a teeny tiny fraction of transistor.


        Stefan

Re: Changes for emacs 28

[João Távora]

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. ]]]
>
>   > This point comes up here so often that probably someone has
>   > already suggested this silly idea:  Why not have a -1998
>   > (or -1334 (; ) startup switch for the old timers?
>
> I like the idea, but this should be something to set in .emacs,
> not a command-line option.

It must be a command-line option because when reproducing and fixing
bugs on Emacs, you very frequently have the need to run "a bare Emacs
-Q" frequently from a shell, devoid of any third-party packages that may
be interfering.  Maintainers would have to additionally specify the
--medieval switch to feel minimally confortable in that setting. It's
not possible to do this in the .emacs because Emacs -Q jumps that, by
definition.

Come to think of it, this is a bit of a counter argument against my
proposal: if we accept new defaults we must be ready to run Emacs -Q's
that have them.  If the new defaults are to include, say, vim-like
keybindings (ugh!), then maintainers are going to have lots of pain.  

This was a bit of an extreme example, but I guess what I'm saying is
that we should still criteriously choose new defaults.

> Does the minus sign stand for BC?  I don't think Emacs existed in the
> time of the Third Dynasty of Ur.  I developed the first Emacs
> in Babylon in -1765.

1334 was my lame attempt of spelling "leet" in "leetspeak", but I put a
4 instead of 7, i.e. I meant 1337.  Guess I'm not so leet after
all. Both sound suitably medieval, tho.

João

Re: Changes for emacs 28

[Alfred M. Szmidt]

This just reminds me of the -u USER option in Emacs.  It is n some
sense quite similar to the idea of "profiles".

Re: Changes for emacs 28

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

  > Come to think of it, this is a bit of a counter argument against my
  > proposal: if we accept new defaults we must be ready to run Emacs -Q's
  > that have them.  If the new defaults are to include, say, vim-like
  > keybindings (ugh!), then maintainers are going to have lots of pain.  

  > This was a bit of an extreme example, but I guess what I'm saying is
  > that we should still criteriously choose new defaults.

I agree, the changes in defaults must not be drastic.
But we might still find it useful to be able to specify
the defaults from version N if we don't like the subsequent changes.

-- 
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: Changes for emacs 28

[Stefan Kangas]

Ergus <spacibba@aol.com> writes:

> 5) Enable winmove and mouse-wheel-mode by default.

mouse-wheel-mode is already enabled by default on most graphical
displays.

Re: Changes for emacs 28

[Ergus]

On Sun, Sep 06, 2020 at 03:06:18PM +0000, Stefan Kangas wrote:
>Ergus <spacibba@aol.com> writes:
>
>> 5) Enable winmove and mouse-wheel-mode by default.
>
>mouse-wheel-mode is already enabled by default on most graphical
>displays.
>
Right!... btw why not in the terminal?

Re: Changes for emacs 28

[Stefan Monnier]

>>> 5) Enable winmove and mouse-wheel-mode by default.
>> mouse-wheel-mode is already enabled by default on most graphical
>> displays.
> Right!... btw why not in the terminal?

I think it *is* enabled in the terminal as well.

But it only works if you ask to capture the terminal's mouse buttons
with `xterm-mouse-mode`.


        Stefan "who doesn't use a mouse any more"

Re: Changes for emacs 28

[Ergus]

On Sun, Sep 06, 2020 at 12:54:08PM -0400, Stefan Monnier wrote:
>>>> 5) Enable winmove and mouse-wheel-mode by default.
>>> mouse-wheel-mode is already enabled by default on most graphical
>>> displays.
>> Right!... btw why not in the terminal?
>
>I think it *is* enabled in the terminal as well.
>
>But it only works if you ask to capture the terminal's mouse buttons
>with `xterm-mouse-mode`.
>
>
>        Stefan "who doesn't use a mouse any more"
>
Hi Stefan:

Is there a reason why the user needs to enable this explicitly? The
wheel and mouse works for me when using man/less/vim, out of the
box. Couldn't we do the same?

Best,
Ergus

Re: Changes for emacs 28

[Alfred M. Szmidt]

   >I think it *is* enabled in the terminal as well.
   >
   >But it only works if you ask to capture the terminal's mouse buttons
   >with `xterm-mouse-mode`.

   Is there a reason why the user needs to enable this explicitly? The
   wheel and mouse works for me when using man/less/vim, out of the
   box. Couldn't we do the same?

Not everyone uses xterm as their terminal of choise.

Re: Changes for emacs 28

[Stefan Monnier]

>    Is there a reason why the user needs to enable this explicitly?

IIRC the issue is that it prevents *other* uses of the mouse in xterm.
But I'm not quite sure what these are nor how important they are.
Maybe it's time to make a formal request to enable it by default?

> Not everyone uses xterm as their terminal of choise.

Not sure how that's related.  `xterm-mouse-mode` should only have an
effect in the terminals in which it works.  Are you saying that it is
known to have undesirable side-effects in some terminals?


        Stefan

Re: Changes for emacs 28

[Alfred M. Szmidt]

   >    Is there a reason why the user needs to enable this explicitly?

   IIRC the issue is that it prevents *other* uses of the mouse in xterm.
   But I'm not quite sure what these are nor how important they are.
   Maybe it's time to make a formal request to enable it by default?

I tried it in xterm, it doesn't conflict with the standard
C-mouse-1/2/3 pop-up menus that are available there.

   > Not everyone uses xterm as their terminal of choise.

   Not sure how that's related.  `xterm-mouse-mode` should only have an
   effect in the terminals in which it works.  Are you saying that it is
   known to have undesirable side-effects in some terminals?

If it is only enabled when one uses a xterm compatible terminal, I
don't see any harm.  But it would be strange to have xterm features
enabled when ones terminal isn't xterm, and still support mousy stuff.

Re: Changes for emacs 28

[Mario Lang]

Ergus <spacibba@aol.com> writes:

> 3) Substitute list-buffers with ibuffer: This is actually in the TODO
> but for interactive users ibuffer offers a bit more modern
> experience. So the proposition is just to set ibuffer to the default
> bindings as so far it already offers all the list-buffers'
> functionalities.

+1

> 4) Enable display-line-numbers-mode by default. Almost all editors
> around have line numbers by default why we hide them?

No, please don't.  Maybe I am already too old, but I don't know what
these other editors you are talking about would be.  I never saw vim or
nano do that by default, and I am grateful for that.

-- 
CYa,
  ⡍⠁⠗⠊⠕

Re: Changes for emacs 28

[Eli Zaretskii]

> From: Mario Lang <mlang@blind.guru>
> Date: Tue, 08 Sep 2020 10:25:15 +0200
> Cc: emacs-devel@gnu.org
> 
> Ergus <spacibba@aol.com> writes:
> 
> > 3) Substitute list-buffers with ibuffer: This is actually in the TODO
> > but for interactive users ibuffer offers a bit more modern
> > experience. So the proposition is just to set ibuffer to the default
> > bindings as so far it already offers all the list-buffers'
> > functionalities.
> 
> +1
> 
> > 4) Enable display-line-numbers-mode by default. Almost all editors
> > around have line numbers by default why we hide them?
> 
> No, please don't.  Maybe I am already too old, but I don't know what
> these other editors you are talking about would be.  I never saw vim or
> nano do that by default, and I am grateful for that.

See, that's exactly the crux of the difficulty in these matters: ask N
people about changing defaults to M options, and you get the number of
different "please do this and this, but not that" opinions almost as
large as the number of permutations.

So either (1) we go for the lowest common denominator of features that
most people agree to (which can easily be an empty set); or (2) we
come up with groups of optional features which are turned on and off
together.  The latter needs someone who'd figure out such groups,
based on some principles, like experience or the kind of jobs that
people want to do, or something else.  It isn't easy, but unless
someone picks up the gauntlet, we will never move in that direction.

Re: Changes for emacs 28

[Stefan Monnier]

> So either (1) we go for the lowest common denominator of features that
> most people agree to (which can easily be an empty set);

That's what we've been doing so far.  I think we should keep doing it,
of course, because it's pretty much the only choice for the "default
defaults".

Beside this, we could create a kind of hierarchical configuration
system, where the hierarchy is not (like is the case in Custom) based
only on functionality, but rather on "popularity/importance/frequency".

We already have a bit of that with the few options which are placed
directly in the `Options` menu.  We could offer a menu entry "Settings"
which shows the "most commonly" requested settings (in a buffer rather
than in a submenu).  Not sure if we'd need "advanced settings" as an
intermediate point before getting to the "exhaustive" list of settings
available currently via Customize.

> or (2) we come up with groups of optional features which are turned on
> and off together.

These sound like Custom themes.  Currently we only use them for
aesthetics (faces, basically), but we should probably try to develop
them further to cover similar needs to the ones satisfied by
Doom/Spacemacs/StarterKit/...

> It isn't easy, but unless someone picks up the gauntlet, we will never
> move in that direction.

Agreed.  Maybe we should start small and try to create a few simple
custom-themes like `emacs24`, `emacs19`, `dark-background`, `Vim`, ...

And ideally someone should try and see what breaks down when we try and
create a theme that mimicks Prelude or Starter Kit, and then work
towards lifting those restrictions.


        Stefan

Re: Changes for emacs 28

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Mario Lang <mlang@blind.guru>,  spacibba@aol.com,  emacs-devel@gnu.org
> Date: Tue, 08 Sep 2020 10:51:14 -0400
> 
> > It isn't easy, but unless someone picks up the gauntlet, we will never
> > move in that direction.
> 
> Agreed.  Maybe we should start small and try to create a few simple
> custom-themes like `emacs24`, `emacs19`, `dark-background`, `Vim`, ...

That'd be fine, although I'd rather prefer themes that sound like
Python-programming and Ruby-programming, and Atom, Sublime and VSCode
instead of Vim...

Re: Changes for emacs 28

[Stefan Monnier]

> That'd be fine, although I'd rather prefer themes that sound like
> Python-programming and Ruby-programming,

I think these usually aren't "themes".  They're rather integration work
that make things work the way they should, regardless of preference.
We definitely should work on that, but I don't think it's fit for
a custom theme.

> and Atom, Sublime and VSCode instead of Vim...

;-)


        Stefan

Re: Changes for emacs 28

[Stefan Kangas]

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

> Beside this, we could create a kind of hierarchical configuration
> system, where the hierarchy is not (like is the case in Custom) based
> only on functionality, but rather on "popularity/importance/frequency".

It would also be good to be able to be able to present options in a
logical and predetermined order in custom instead of the current
alphabetical order.  Could custom be extended to handle that?  Maybe we
could add a :weight property to defcustom?

> We already have a bit of that with the few options which are placed
> directly in the `Options` menu.  We could offer a menu entry "Settings"
> which shows the "most commonly" requested settings (in a buffer rather
> than in a submenu).

Agreed, excellent idea.

> Agreed.  Maybe we should start small and try to create a few simple
> custom-themes like `emacs24`, `emacs19`, `dark-background`, `Vim`, ...
>
> And ideally someone should try and see what breaks down when we try and
> create a theme that mimicks Prelude or Starter Kit, and then work
> towards lifting those restrictions.

Agreed.  (Although I'm looking for the 'emacs29' theme myself.)

RE: Changes for emacs 28

[Drew Adams]

> > Beside this, we could create a kind of hierarchical configuration
> > system, where the hierarchy is not (like is the case in Custom) based
> > only on functionality, but rather on "popularity/importance/frequency".
> 
> It would also be good to be able to be able to present options in a
> logical and predetermined order in custom instead of the current
> alphabetical order.  Could custom be extended to handle that?  Maybe we
> could add a :weight property to defcustom?

Isn't that what :group is about?  An author can assign
any option or face to any number of :groups.

A :group is thus like a Delicious-style tag, in a way.

https://en.wikipedia.org/wiki/Delicious_(website)

Finder keywords, that is, keywords in a `Keywords'
file-header field, are also like tags in this way.

`customize-group' and `finder-by-keyword' are UI
entry points.  They could be improved.

Uses of finder keywords haven't been too systematic
so far.  And :group has been used sparingly so far.

But both seem to have this property that you can
assign multiple such "tags" to a thing (file/library
for finder keywords, option/face for :groups).

An advantage of organization by such tags is that
there can be any number of "logical and predetermined
orders".  Or rather, tags define sets, which are
unordered, but there can be hierarchies of sets.  And
the sets - their hierarchies and their elements - are
easily updated/redefined.

Re: Changes for emacs 28

[Dmitry Gutov]

On 08.09.2020 17:35, Eli Zaretskii wrote:
> See, that's exactly the crux of the difficulty in these matters: ask N
> people about changing defaults to M options, and you get the number of
> different "please do this and this, but not that" opinions almost as
> large as the number of permutations.

Honestly, I don't think that enabling (or not) display-line-numbers-mode 
is going to be a big deal either way: it's easy to enable or disable, 
and it has little far-reaching consequences otherwise.

Certainly fewer consequences that changing the default theme to dark, or 
enabling cua-mode by default, or even incorporating which-key.

Likewise for ibuffer vs list-buffers (though it'll be a bit harder to 
change back).

> So either (1) we go for the lowest common denominator of features that
> most people agree to (which can easily be an empty set); or (2) we
> come up with groups of optional features which are turned on and off
> together.

Orthogonally, we could decide on a method for changing defaults which 
doesn't involve the impossible task of making everybody happy but still 
makes some effort to change with the times.

Re: Changes for emacs 28

[Eli Zaretskii]

> Cc: spacibba@aol.com, emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Wed, 9 Sep 2020 01:06:31 +0300
> 
> On 08.09.2020 17:35, Eli Zaretskii wrote:
> > See, that's exactly the crux of the difficulty in these matters: ask N
> > people about changing defaults to M options, and you get the number of
> > different "please do this and this, but not that" opinions almost as
> > large as the number of permutations.
> 
> Honestly, I don't think that enabling (or not) display-line-numbers-mode 
> is going to be a big deal either way: it's easy to enable or disable, 
> and it has little far-reaching consequences otherwise.

That was only an example.

And anyway, isn't what you say above true for almost every optional
feature in Emacs?

> > So either (1) we go for the lowest common denominator of features that
> > most people agree to (which can easily be an empty set); or (2) we
> > come up with groups of optional features which are turned on and off
> > together.
> 
> Orthogonally, we could decide on a method for changing defaults which 
> doesn't involve the impossible task of making everybody happy but still 
> makes some effort to change with the times.

If this can be done, why not?  But based on past experience, I'm
skeptical, to tell the truth.

Re: Changes for emacs 28

[Dmitry Gutov]

On 09.09.2020 17:04, Eli Zaretskii wrote:

>> On 08.09.2020 17:35, Eli Zaretskii wrote:
>>> See, that's exactly the crux of the difficulty in these matters: ask N
>>> people about changing defaults to M options, and you get the number of
>>> different "please do this and this, but not that" opinions almost as
>>> large as the number of permutations.
>>
>> Honestly, I don't think that enabling (or not) display-line-numbers-mode
>> is going to be a big deal either way: it's easy to enable or disable,
>> and it has little far-reaching consequences otherwise.
> 
> That was only an example.
> 
> And anyway, isn't what you say above true for almost every optional
> feature in Emacs?

For a lot of them, yes. But of course there are also changes in behavior 
(that people also asked for) that can have farther-reaching consequences.

So I do believe we shouldn't worry too much about making some existing 
users moderately unhappy if we have convincing data that a given change 
will make Emacs more useful or more approachable (without making it less 
useful) for a lot of users, current or future ones. Especially if said 
optional feature is easy to toggle, and we can document how to negate 
the change in NEWS.

Repeat the same decision process M times.

Since this way there is no goal of making every user 100% happy, there 
is no stalemate.

>>> So either (1) we go for the lowest common denominator of features that
>>> most people agree to (which can easily be an empty set); or (2) we
>>> come up with groups of optional features which are turned on and off
>>> together.
>>
>> Orthogonally, we could decide on a method for changing defaults which
>> doesn't involve the impossible task of making everybody happy but still
>> makes some effort to change with the times.
> 
> If this can be done, why not?
> But based on past experience, I'm
> skeptical, to tell the truth.

 From my past experience, what was lacking is direction in leadership. 
Sorry to be blunt.

There were cases where we had evidence that a change will be welcome by 
the majority of users, existing and potential ones, and would be easily 
reverted locally by anybody who didn't like it, and it still wasn't 
made. E.g. the simple case of indent-tabs-mode=>nil.

Of course, not all cases are simple, and whether something is generally 
beneficial/user-friendly/etc is a matter of judgment. But at least we 
shouldn't be stopped by the sole concern that a given change can 
generate complaints because the option in question has held a certain 
value for a number of years. Or even decades.

Re: Changes for emacs 28

[Howard Melman]

Eli Zaretskii <eliz@gnu.org> writes:

> See, that's exactly the crux of the difficulty in these matters: ask N
> people about changing defaults to M options, and you get the number of
> different "please do this and this, but not that" opinions almost as
> large as the number of permutations.
>
> So either (1) we go for the lowest common denominator of features that
> most people agree to (which can easily be an empty set); or (2) we
> come up with groups of optional features which are turned on and off
> together.  The latter needs someone who'd figure out such groups,
> based on some principles, like experience or the kind of jobs that
> people want to do, or something else.  It isn't easy, but unless
> someone picks up the gauntlet, we will never move in that direction.

How about creating a new function that generates a report of
how a user has configured emacs.  Various options,
global-minor-modes, faces, etc, similar to what
report-emacs-bug generates.  Setup a separate email address
to receive reports and automatically tabulate what the
popular settings are.

Ship it with emacs 28.  Let it percolate into Doom,
Spacemacs and other distributions.  Then ask people far and
wide to run it.  This would generate actual data about
what's popular and what defaults people typically change and
could settle these recurring debates.

Like report-emacs-bug, it should display the info to the
user before sending so they can check that nothing personal
is revealed.

-- 

Howard

Re: Changes for emacs 28

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

  > > 4) Enable display-line-numbers-mode by default. Almost all editors
  > > around have line numbers by default why we hide them?

  > No, please don't.  Maybe I am already too old, but I don't know what
  > these other editors you are talking about would be.  I never saw vim or
  > nano do that by default, and I am grateful for that.

Maybe the default for this should depend on the width of the frame.

-- 
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: Changes for emacs 28

[Philip K.]

Ergus <spacibba@aol.com> writes:

> Hi Emacs:
>
> As 27 has just been released I think it is time to start considering
> changes for the release 28. I will add some points I think we could
> discuss (specially implying defaults) in order to hear opinions and have
> enough time to discuss/implement them.

Most of the discussions seems to have revolved around user-facing
changes, but I think it might also be time to clean-up some of the
internal code. There are vast discrepancies in style between newer
modules such as xref or project and older systems such as hippie-expand
and Rmail.

My hope would be that with easier interfaces to work with, that leverage
Elisp improvements, that more people would be interested in using,
supporting and extending OOTB packages/modules. My fear is that
backwards compatibility would be at risk.

---

And regarding modernizing defaults, how about bundling a few "themes"
that enable/disable a few settings. It might be confusing at first, as
most people associate themes with visual customisations, but since Emacs
interprets the term more generally, adding themes such as "Modern" that
enables more bells and whistles (I'm not too enthusiastic about the
name, some might have chosen "Hipster" instead :^)), "Minimal" that
reduces UI, etc. might be a compromise between the fractions that want
to make Emacs appealing to newcomers and those that don't want to break
Emacs' way-of-operating by default.

-- 
	Philip K.

Re: Changes for emacs 28

[Eli Zaretskii]

> From: "Philip K." <philipk@posteo.net>
> Gcc: nnfolder+archive:sent.2020-09
> Date: Wed, 09 Sep 2020 19:14:29 +0200
> 
> And regarding modernizing defaults, how about bundling a few "themes"
> that enable/disable a few settings. It might be confusing at first, as
> most people associate themes with visual customisations, but since Emacs
> interprets the term more generally, adding themes such as "Modern" that
> enables more bells and whistles (I'm not too enthusiastic about the
> name, some might have chosen "Hipster" instead :^)), "Minimal" that
> reduces UI, etc. might be a compromise between the fractions that want
> to make Emacs appealing to newcomers and those that don't want to break
> Emacs' way-of-operating by default.

We already have a couple of such themes, so the issue of us accepting
such themes doesn't exist.

P.S.  Please review your MUA settings, because they just caused Emacs
to exclude the mailing list from the recipients, something that is
unwanted.

Re: Changes for emacs 28

[Eli Zaretskii]

> Date: Thu, 10 Sep 2020 12:40:37 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: spacibba@aol.com, emacs-devel@gnu.org
> 
> P.S.  Please review your MUA settings, because they just caused Emacs
> to exclude the mailing list from the recipients, something that is
> unwanted.                            ^^^^^^^^^^

I meant the recipients of the response message, i.e. the addresses
automatically added to a response message by Emacs.

Re: Changes for emacs 28

[Philip K.]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: "Philip K." <philipk@posteo.net>
>> Gcc: nnfolder+archive:sent.2020-09
>> Date: Wed, 09 Sep 2020 19:14:29 +0200
>> 
>> And regarding modernizing defaults, how about bundling a few "themes"
>> that enable/disable a few settings. It might be confusing at first, as
>> most people associate themes with visual customisations, but since Emacs
>> interprets the term more generally, adding themes such as "Modern" that
>> enables more bells and whistles (I'm not too enthusiastic about the
>> name, some might have chosen "Hipster" instead :^)), "Minimal" that
>> reduces UI, etc. might be a compromise between the fractions that want
>> to make Emacs appealing to newcomers and those that don't want to break
>> Emacs' way-of-operating by default.
>
> We already have a couple of such themes, so the issue of us accepting
> such themes doesn't exist.

Oh, I didn't know that? Is this being done in a separate feature branch?

> P.S.  Please review your MUA settings, because they just caused Emacs
> to exclude the mailing list from the recipients, something that is
> unwanted.

My apologies, again, I use Gnus to follow the mailing list, but forget
that unlike Rmail, it doesn't reply to every when 'R' is pressed.

-- 
	Philip K.

Re: Changes for emacs 28

[Eli Zaretskii]

> From: "Philip K." <philipk@posteo.net>
> Cc: spacibba@aol.com, emacs-devel@gnu.org
> Date: Thu, 10 Sep 2020 17:08:25 +0200
> 
> >> And regarding modernizing defaults, how about bundling a few "themes"
> >> that enable/disable a few settings. It might be confusing at first, as
> >> most people associate themes with visual customisations, but since Emacs
> >> interprets the term more generally, adding themes such as "Modern" that
> >> enables more bells and whistles (I'm not too enthusiastic about the
> >> name, some might have chosen "Hipster" instead :^)), "Minimal" that
> >> reduces UI, etc. might be a compromise between the fractions that want
> >> to make Emacs appealing to newcomers and those that don't want to break
> >> Emacs' way-of-operating by default.
> >
> > We already have a couple of such themes, so the issue of us accepting
> > such themes doesn't exist.
> 
> Oh, I didn't know that? Is this being done in a separate feature branch?

No, those themes are on master.

Re: Changes for emacs 28

[Tassilo Horn]

Ergus <spacibba@aol.com> writes:

> 1) Improve the default theme: Maybe set a default dark theme to make
> emacs feel more modern.

If you just set your background to some dark color, the stock Emacs
default faces are actually very nice, see:

  https://functional.cafe/web/statuses/104411970368324669

So just a default face light/dark toggle which doesn't use a theme but
the standard faces seems like a good idea.

Bye,
Tassilo

Re: Changes for emacs 28

[Philip K.]

Tassilo Horn <tsdh@gnu.org> writes:

> Ergus <spacibba@aol.com> writes:
>
>> 1) Improve the default theme: Maybe set a default dark theme to make
>> emacs feel more modern.
>
> If you just set your background to some dark color, the stock Emacs
> default faces are actually very nice, see:
>
>   https://functional.cafe/web/statuses/104411970368324669
>
> So just a default face light/dark toggle which doesn't use a theme but
> the standard faces seems like a good idea.
>
> Bye,
> Tassilo

That actually looks fairly similar to my own "dark mode":

        (defun reverse-face (face &optional frame)
          "Set FACE (in FRAME) to RGB inverse."
          (interactive (list (read-face-name "Reverse face" (face-at-point t))))
          (require 'color)
          (ignore-errors
            (let ((fg (face-attribute face :foreground frame))
                  (bg (face-attribute face :background frame)))
              (set-face-attribute
               face frame
               :foreground (color-complement-hex fg)
               :background (color-complement-hex bg)))))

        (defun toggle-dark-mode ()
          "Toggle dark mode."
          (interactive)
          (dolist (face '(mode-line default))
            (reverse-face face)))

-- 
	Philip K.