bug#11445: 24.0.96; Customize buffer edit fields should have undo

bug#11445: 24.0.96; Customize buffer edit fields should have undo

[Drew Adams]

A text editing field in Customize is like text editing in general.  Why
shouldn't undo be available to users here?

In GNU Emacs 24.0.96.1 (i386-mingw-nt5.1.2600)
 of 2012-04-28 on MARVIN
Windowing system distributor `Microsoft Corp.', version 5.1.2600
Configured using:
 `configure --with-gcc (4.6) --no-opt --enable-checking --cflags
 -ID:/devel/emacs/libs/libXpm-3.5.8/include
 -ID:/devel/emacs/libs/libXpm-3.5.8/src
 -ID:/devel/emacs/libs/libpng-dev_1.4.3-1/include
 -ID:/devel/emacs/libs/zlib-dev_1.2.5-2/include
 -ID:/devel/emacs/libs/giflib-4.1.4-1/include
 -ID:/devel/emacs/libs/jpeg-6b-4/include
 -ID:/devel/emacs/libs/tiff-3.8.2-1/include
 -ID:/devel/emacs/libs/gnutls-3.0.9/include'
 

bug#11445: 24.0.96; Customize buffer edit fields should have undo

[Drew Adams]

ping

bug#11445: 24.0.96; Customize buffer edit fields should have undo

[Lars Ingebrigtsen]

"Drew Adams" <drew.adams@oracle.com> writes:

> A text editing field in Customize is like text editing in general.  Why
> shouldn't undo be available to users here?

As far as I can tell, `undo' works fine in text fields in Customize
buffers.  Are you still seeing this problem in recent Emacs versions?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#11445: 24.0.96; Customize buffer edit fields should have undo

[Mauro Aranda]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> "Drew Adams" <drew.adams@oracle.com> writes:
>
>> A text editing field in Customize is like text editing in general.  Why
>> shouldn't undo be available to users here?
>
> As far as I can tell, `undo' works fine in text fields in Customize
> buffers.  Are you still seeing this problem in recent Emacs versions?

It cannot work reliably: if a widget needs to be redrawn, the widget
code will clear the undo information with widget-clear-undo.

Try this:
emacs -Q
M-x customize-group RET mouse
TAB until point is at the arrow to expand the double-click-fuzz option
RET
TAB to move to the field
deletechar
4
C-x u shows the empty field, which is fine
C-x u again: "No further undo information".  But that's not expected; if
undo worked, the field value would be the default value.

bug#11445: 24.0.96; Customize buffer edit fields should have undo

[Lars Ingebrigtsen]

Mauro Aranda <maurooaranda@gmail.com> writes:

> C-x u again: "No further undo information".  But that's not expected; if
> undo worked, the field value would be the default value.

Ah, right -- I can reproduce that, too.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#11445: 24.0.96; Customize buffer edit fields should have undo

[Michael Heerdegen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> > C-x u again: "No further undo information".  But that's not expected; if
> > undo worked, the field value would be the default value.
>
> Ah, right -- I can reproduce that, too.

Question is whether it's even well defined to do this differently.

It's not that every text field has its own undo.  Undo stops at points
when widgets changed because undoing further would undo changes
involving widgets, which ones are there, how they look like, etc.  Since
using widgets has side effects (like setting variables or saving) just
undoing anything would potentially lead to an inconsistent state.

How would you address this problem?

Michael.

bug#11445: [External] : bug#11445: 24.0.96; Customize buffer edit fields should have undo

[Drew Adams]

> > > C-x u again: "No further undo information".  But that's not expected; if
> > > undo worked, the field value would be the default value.
> >
> > Ah, right -- I can reproduce that, too.
> 
> Question is whether it's even well defined to do this differently.
> 
> It's not that every text field has its own undo.  Undo stops at points
> when widgets changed because undoing further would undo changes
> involving widgets, which ones are there, how they look like, etc.  Since
> using widgets has side effects (like setting variables or saving) just
> undoing anything would potentially lead to an inconsistent state.
> 
> How would you address this problem?

I think I understand what you're saying.  But undo
should be about user actions, and their effects
(consequences).  Yes, the effects of user actions
here include (at least some) "changes involving widgets".

Looking at this from (only) a user point of view,
this seems broken (i.e., calling for improvement).

I have no idea how to address fixing it. 

bug#11445: 24.0.96; Customize buffer edit fields should have undo

[Lars Ingebrigtsen]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> Question is whether it's even well defined to do this differently.
>
> It's not that every text field has its own undo.  Undo stops at points
> when widgets changed because undoing further would undo changes
> involving widgets, which ones are there, how they look like, etc.  Since
> using widgets has side effects (like setting variables or saving) just
> undoing anything would potentially lead to an inconsistent state.
>
> How would you address this problem?

Not all actions in a custom buffer can be undone (with the normal Emacs
undo functionality), but it seems quiet unexpected that deleting a
character in the text field of the buffer with the normal editing
commands can't be undone.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#11445: [External] : Re: bug#11445: 24.0.96; Customize buffer edit fields should have undo

[Drew Adams]

> > A text editing field in Customize is like text
> > editing in general.  Why shouldn't undo be available
> > to users here?
> 
> As far as I can tell, `undo' works fine in text fields in Customize
> buffers.  Are you still seeing this problem in recent Emacs versions?

Good question.  Pulling up Emacs 23 now to check what
this was about...

Some editable fields, at least, do have undo.  But not
once you've chosen `Set for current session'.

Just as you can continue to edit a field after you've
chosen to set the value, so I think you should be able
to undo previous edits you made.

Why would we turn off undo, just because you chose set,
or even save?  As long as editing is available so should
undo be available. (We don't change fields to read-only
just because you chose set or save.)

In fact, the problem is worse.  Consider customizing
an option such as `Info-default-directory-list'.  Each
editable field has its own undo, and as soon as you
move to another editable field and edit it you lose
the ability to undo changes you made previously to
the first field.  You can then try to make other
changes to the already changed first field, but undo
then takes you back only as far as what was frozen
when you went on to edit the second field.  This
isn't helpful.  You should be able to undo globally,
throughout the Customize buffer.

Secondly, considering "editing" more broadly, why not
let undo apply even to other changes you make in the
buffer, from `Toggle' to a `Value Menu' choice.  The
point is to be able to undo changes you've made to
the option, regardless of whether you've chosen set
or save yet.

These non-edit-field kinds of changes are not in the
same ball-park, admittedly, so fixing this for them
might involve more work.  But this is something to aim
for, and it should be part of this bug fix (enhancement
request, if you prefer).

In particular, consider `customize-face' changes.
For the most part changes to attributes involve
using `Value Menu'.  It's important, I think, to be
able to undo a bunch of such changes, and not just
changes in an individual editable field.
___

There, that constitutes a needed supplement to my
admittedly terse bug report.  At least I'm thinking
that this is what I was thinking of.
___

That was all taking a look with Emacs 23.4.  Now
let me look at Emacs 27.2, to see if any of that
has already been fixed...  And I see no improvement
in any of that.  I'd ask that this bug remain open.
HTH.