Undo screws up the code

Even up to 1.8.9 UNDO does not work,
screwing up the code.
Is there any solution?

No sketch attached so best answer is see HERE

Screwing up the code happens to any code, large or small,
so there is no reason to post a code (can't even do it since the IDE does not respond anymore after trying the "UNDO"). Now I am in trouble...

Just occasionally it works correct. Couldn't figure out what that occasion is.
So, UNDO cannot be used at present (at least for me). It's very bad if you don't remember what you had changed...

There had been similar "complaints" some years ago on this issue but not recently, and no post claiming "solved".
So there seems to be an inherent problem with respect to the IDE. Might be related to the graphics.
Using Win10 (prof) with any update, and SSDs.

What happens when you try it? While I can't think of a specific instance that I used undo in, I would be stunned if I'd never used it, and I'd definitely have noticed if it screwed up the code. I also haven't heard people complaining about this, which I would think would be a very common complaint if it happened to everyone.

Ideally, could you say... make a trivial change in blink, then undo it, and post the modified sketch (before the undo) and what the result after undo was.

Some time ago, there was a problem with undo when it was used with some of the code folded (File > Preference > Enable Code Folding). That bug was fixed long ago and I just tried to see if there was regression of that, but it seems to be fine.

Unlike DrAzzy, I use undo and redo all the time and have not had any problems. I'm also using Windows 10. It would be helpful if you could provide a specific and detailed set of steps we can follow to reproduce the problem.

The UNDO problem still hurts me a lot.
I have attached a screenshot showing kind of what happens.
Code folding had been activated.

So, I have keep my fingers from the UNDO (In any other program that works just fine).

Fortunateley, I have some kind of versioning tool (“Autover”) that helps me to recover the latest saved version. But that doesn’t help when the IDE is not saved on compiling like when starting coding from a library example…

Sometimes I wish I could go back to my favorite Basic editor that works, but the ESP32 isn’t supported by that, unfortunately.

OP’s pic.


This is a good reason we prefer text copied and pasted into CODE TAGS ( </> )

As it stands I don’t see the issue there as it looks to have left just a blank line which could have been there from a previous action before that line of code.

Edited for a little more clarity.

UNDO v2.jpg

Sometimes I wish I could go back to my favorite Basic editor that works

The Arduino IDE does support using an external editor to edit the code. If you check File > Preferences > Use External Editor then editing code via the Arduino IDE will be disabled and any changes you make to the sketch files externally will be recognized when you compile the sketch.

However, even if you are happy with using an external editor as a workaround, I'd really like to investigate this further to make sure it won't affect anyone else. Unfortunately, I have not been able to reproduce the issue. I'd appreciate it if you would provide some exact instructions I can use to reproduce the issue.

Per, look more closely - it looks like lines on both sides of the position= line were removed. Unless he was undoing a paste operation...

What would you have expected the after to look like.

I did look closely at the picture. It certainly looks odd. Maybe you're attributing ballscrewbob's reply to me?

I have absolutely no clue what I would have expected the after to look like because I don't know what was the edit that was undone. That's why I keep asking for a detailed set of instructions I can use to reproduce the bug.

Ergh, yeah I was, sorry.

Yea mee too soz...

Thats why I prefer the CP method and as Per said "steps to reproduce"
Its like drawing teeth on this topic.
Says a bug bit not providing much to go on apart from two tiny pics that had to be enlarged to see anything.

here is an older post on the same issue:

Thanks for your attention on the UNDO-problem issue. I would be happy if I could provide better information. Unfortunately, as I said in my first post, the problem occurs “occasionally”.
So, first of all, I did not remember what excatly I did when the UNDO screwed up the code as posted.
One reason was that I was careless assuming the problem had somehow been fixed (I had installed another 8GB ram assuming some kind of cache limit was causing the problem).

I think (but I am not sure if exactly) that I had cut or copied the lines

int  offset=position;

and then scrolled up towards the top of the IDE screen and pasted it there. Then I did the UNDO.
(Maybe scrolling up does the harm?)

Prior to starting my coding session in that case I had done a test on UNDO, and it worked…
I even had run in advance a 3D CAD program with a large design and did some editing on that (there the undo works). But then after some coding using the Arduino IDE the UNDO-bug caught me.

So, in conclusion, it is hard to give a procedure to reproduce the problem unless I spend some hours playing around with it…

Maybe somebody here knows and would explain how the UNDO is implemented. That might give a clue about the problem.
The complete code (the longer I think about it, I have the feeling it is related to the upwards scrolling):

#include "SPI.h"
// Stop button is attached to PIN 0 (IO0)
#define BTN_STOP_ALARM    0
uint8_t DAC_Channel_1 = 25;
const int CSB = 5; // chip select bit for Arduino Uno
int led = 27;
unsigned int data = 0;
volatile byte state = LOW;
int position;
unsigned int datafMSB = 0;
unsigned int datafLSB = 0;
unsigned int dataMSB = 0;
unsigned int dataLSB = 0;
unsigned int val = 0;
unsigned int zielwert;
unsigned int wert;
unsigned int anfangswert;
unsigned int port = 2;
unsigned int offset;
hw_timer_t * timer = NULL;
volatile SemaphoreHandle_t timerSemaphore;

volatile uint32_t isrCounter = 0;
volatile uint32_t lastIsrAt = 0;

void IRAM_ATTR onTimer() {
  digitalWrite(CSB, LOW);
  dataLSB = SPI.transfer(0x00);
  digitalWrite(CSB, HIGH);
  digitalWrite(CSB, LOW);
  dataMSB = SPI.transfer(0x00);
  digitalWrite(CSB, HIGH);
  position = (dataMSB << 8) | (dataLSB);
  position = (position >> 6)-90;
  dacWrite(DAC_Channel_1, position);
  // Give a semaphore that we can check in the loop
  //  xSemaphoreGiveFromISR(timerSemaphore, NULL);
  // It is safe to use digitalRead/Write here if you want to toggle an output

void setup() {
  pinMode(2, OUTPUT);
  pinMode(32, OUTPUT);
  pinMode(CSB, OUTPUT);
  SPI.setDataMode(SPI_MODE0); // CPOL = 0 and CPH = 0 mode 3 also works
  SPI.setClockDivider(SPI_CLOCK_DIV4); // set SCLK @ 4MHz, LDC1000 max is 4MHz DIV2 also works
  // set power mode to idle to configure stuff
  digitalWrite(CSB, LOW);
  digitalWrite(CSB, HIGH);
  // Set RpMax
  digitalWrite(CSB, LOW);
  digitalWrite(CSB, HIGH);
  // Set RpMin
  digitalWrite(CSB, LOW);
  digitalWrite(CSB, HIGH);
  // Set Sensor frequency
  digitalWrite(CSB, LOW);
  digitalWrite(CSB, HIGH);
  // Set LDC configurationn
  digitalWrite(CSB, LOW);
  digitalWrite(CSB, HIGH);
  // Set clock configuration
  digitalWrite(CSB, LOW);
  digitalWrite(CSB, HIGH);
  // disable all interrupt modes
  digitalWrite(CSB, LOW);
  digitalWrite(CSB, HIGH);
  // set thresh HiLSB value
  digitalWrite(CSB, LOW);
  digitalWrite(CSB, HIGH);
  // set thresh HiMSB value
  digitalWrite(CSB, LOW);
  digitalWrite(CSB, HIGH);
  // set thresh LoLSB value
  digitalWrite(CSB, LOW);
  digitalWrite(CSB, HIGH);
  // set thresh LoMSB value
  digitalWrite(CSB, LOW);
  digitalWrite(CSB, HIGH);
  // set power mode to active mode
  digitalWrite(CSB, LOW);
  digitalWrite(CSB, HIGH);
  // Read Rpmax
  digitalWrite(CSB, LOW);
  data = SPI.transfer(0x00);
  digitalWrite(CSB, HIGH);
  // Set BTN_STOP_ALARM to input mode

  // Create semaphore to inform us when the timer has fired
  //  timerSemaphore = xSemaphoreCreateBinary();
  // Use 1st timer of 4 (counted from zero).
  timer = timerBegin(0, 80, true);
  timerAttachInterrupt(timer, &onTimer, true);
  // Set alarm to call onTimer function every second (value in microseconds).
  // Repeat the alarm (third parameter)
  timerAlarmWrite(timer, 50, true);
  // Start an alarm

void loop() {
  //If Timer has fired
  //  if (xSemaphoreTake(timerSemaphore, 0) == pdTRUE) {
  //    portENTER_CRITICAL(&timerMux);
  //    wert = position;
  //    portEXIT_CRITICAL(&timerMux);
  //  }
  zielwert = 100;
  int verz = 800;
  Serial.print(" A= "); Serial.println(anfangswert);
  //  int wert=position;//anfangswert;
  digitalWrite(port, LOW);
//  position=map(offset, 100, position, 0, 255);
  wert = position;
  //  while (position >= wert) {
  while (position >= zielwert)
    if (wert > zielwert)
    { wert--;
      //        portENTER_CRITICAL(&timerMux);
      digitalWrite(port, LOW);
      digitalWrite(port, HIGH);
      Serial.println(position); Serial.print(" port= "); Serial.print(port); Serial.print(" "); Serial.print(digitalRead(port)); Serial.print(" W= "); Serial.print(wert); Serial.print(" A= "); Serial.println(anfangswert);
      digitalWrite(port, LOW);
  Serial.print("---------- ");   Serial.println(position);
  //  delay(3000);
  //   }      portEXIT_CRITICAL(&timerMux);
  // If button is pressed

If the problem occurs again, please try to immediately think back to what you did and then test whether you can repeat those exact steps to reproduce the issue, then come back here with the information. In the meantime, I'll definitely keep an eye out to see if I can catch it happening.

Some time ago, there was a problem with undo when it was used with some of the code folded (File > Preference > Enable Code Folding). That bug was fixed long ago and I just tried to see if there was regression of that, but it seems to be fine.

I misremembered, that bug was about the find and replace feature, not undo.

I did find an open issue report that may be the same issue:

I suspect it never got any attention because the Arduino developers couldn't reproduce it.

Please watch my previous modified post (not a good idea to have modified it).
Mentioned there that I have the feeling that this might related to having a longer code in a single IDE window, and scrolling up which might mess the UNDO function.

Copy a line from the near to the end, paste it near the top of my code, UNDO remains grayed.
UNDO isn't present.
Seems that part of the problem, when a code is longer than the IDE window (had stretched it vertically to full height).
In this case the code window remained intact.
Please check for reproducability.

Also with a small file:
File:New, cut a line, -->UNDO stays grayed

Copy a line from the near to the end, paste it near the top of my code, UNDO remains grayed.
UNDO isn't present.

I reported this issue some time ago:

File:New, cut a line, -->UNDO stays grayed

I've added that to my issue. Thanks for reporting it!

However, I not convinced those issues are related to the original issue you reported of undo corrupting the code.