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.