Using an External Editor has issues

Development Tools IDE 2.x
1

This appears to be part of a larger issue in that the 2.x IDE GUI is treating changes to sketches from library example sketches differently than non library sketches.
If the sketch is under a library example, it appears that the 2.x IDE GUI no longer pulls in changes made to the sketch when it has been modified using an external editor, nor will it save changes made to the sketch when verifying/building the sketch.

There should be no need to treat changes to the sketch files differently depending on where the sketch lives.
i.e. if the sketch file in the IDE GUI has been changed/modified, the IDE should pull in and use the updated file.
The current 2.x behavior is not the behavior of 1.x when selecting to use an external editor and the current 2.x behavior actually malfunctions and breaks certain work flows.
For example a developer developing an Arduino library can no longer use an external editor when developing the examples for a library as the 2.x IDE will silently not pull in the changes being made to the example sketch file when using an external editor and using the IDE GUI to build the example.

I guess I need to bug this on github.

Here is a bit more about behavior when using an external behavior

The 2.x IDE GUI has a different behavior depending on where the sketch lives and the IDE does not support using an external editor with the sketch involved if it is an example within a library.
i.e. Using an external editor with IDE 2.x GUI does not seem to work when the sketch involved is part of a library example.

For example, (a sketch that is not part of a library)
If the sketch lives at {sketchbook}/foo/foo.ino
and is pulled into the IDE GUI using:
[File]->Sketchbook->foo
When using an external editor on the file foo.ino any changes will show up in the 2.x IDE GUI which is as expected.

However, when the sketch is under a library as an example, the 2.x IDE is not pulling in changes being made using an external editor which is not as expected.
(1.x did not have this issue)

For Example (a sketch that is part of a library)
if the sketch lives at {sketchbook}/libraries/libnamedfoo->examples/foo/foo.ino
and is pulled into the 2.x IDE GUI using:
[File]->Examples->libnamedfoo->foo
When using an external editor on the file foo.ino the 2.x IDE GUI will not pull in the modified file. It will continue to use the original file.

This seems like it was intentionally coded this way vs a bug.
It doesn't make sense.
The 2.x IDE should work the same way with respect to sketch file changes from external editors regardless of where the sketch lives which is what the 1.x IDE did.

NOTE:
In case it matters, I'm using Linux Mint 21 Mate with an IDE installed from a zip file.

--- bill

2

That is correct.

When you open an example sketch via File > Examples menu, a new sketch is generated with the contents of the example. Please use File > Open or open the sketch via file association if you want to open the example sketch in place in the IDE.

3

When you open an example sketch via File > Examples menu, a new sketch is generated with the contents of the example.

IMO, this is not a desirable behavior.

It is not obvious that this under the hood copying has happened and has created some inconsistencies and regressions.
i.e. the name at the top of IDE window is still the original name.
There is no indication that the IDE has mucked with things and created a copy of the sketch file vs using the actual sketch file.
So one would assume that modifying the original sketch file with an external editor should work.
Just like it does with user sketch files and just like it does on example sketches under IDE 1.x

It also means that using an external editor is not consistent with how using an external editor worked on IDE 1.x
Why would anybody want it to work this way?
i.e. given full freedom of implementation why would this implementation and behavior ever be chosen vs making an external editor "just work" in all cases - like it does under IDE 1.x?

It seems like a bunch of work went into implementing & coding this behavior when it does not appear to be necessary.

In effect you are saying that resources were assigned to make this change which would knowingly create a regression in functionality.

Why? For what benefit?

I'm guessing some of what may have driven this decision is the, IMO, poor decision from years back of not doing any builds in place.
There were a couple of situations in specific academic environments where they made an argument for not doing it, but those were not common, and overall that decision has created so much additional work and created many other issues and bugs over the years.

It kind of reminds me of all the goofy unnecessary library directory and sketch file name checking that used to be done in IDE 1.x which caused the IDE to barf on certain names like those with underscore in them.

i.e. a solution looking for an actual problem.

And what about those users not using an external editor that may simply want to use the IDE to modify an example in a library?
They can't do that if they bring up the example using the "examples" way.

Why should bringing up the sketch using "open" work any differently than bringing it up using the "examples" way?
It didn't appear to matter under IDE 1.x
Why can't the "examples" way of opening a sketch just be a short cut for "open" way?
(I always thought it was)
Less code, lest testing, etc. (since it could share the same underlying code) and would make using an external editor compatible with the way it worked under IDE 1.x
where it worked on any sketch that was loaded in the IDE.

--- bill

1 Like
4

They couldn't do it simply with Arduino IDE 1.x either. The reason is that Arduino IDE 1.x treats the examples as read-only to prevent the very confusing situation that would occur when a beginner accidentally modifies what should be a "known good" sketch.

It was possible to overcome that by adding a .development flag file to the library, but I would argue that Arduino IDE 2.x behavior of allowing the example to be edited when it is opened directly via file association or File > Open is at least as convenient as what was required when using Arduino IDE 1.x.

I doubt it. The developers would have had to write code that applies read-only status specifically on examples, and code that allows users to save modified versions to the examples (including user friendly handling of "Auto Save"). That code would likely be significantly more complex than the code that opens the example as a new sketch, and definitely more work to test.

5

The reason is that Arduino IDE 1.x treats the examples as read-only to prevent the very confusing situation that would occur when a beginner accidentally modifies what should be a "known good" sketch.

But 1.x doesn't treat the examples as read only.
I can edit them using an external editor and the IDE will notice the updated file.
I have developed Arduino libraries and their examples for over 10 years and always have used an external editor for both the library code and the examples.
i.e. edit code in editor, build with IDE for testing. Repeat.
With 1.x that is possible.
Now with 2.x it is no longer possible.

Again Why? The read-only status stuff is based on a nanny / guardrail mindset.
It forcing a way of doing things and it is different in 2.x vs 1.x

What I meant by my previous comment is that continuing to put these massive guardrails around editing examples, is costly in terms of engineering time for coding and testing.
Why do it all? That was my point.
i.e. don't worry about all this read only and trying to protect people from themselves stuff.
Just treat all sketches in the IDE the same and have the "examples" way just be a short cut. So they both would fall into the same code.
I am sure if it were done that way it would make the coding and testing simpler and ensure a consistency of using an external editor between 1.x and 2.x

I'm all for helping people but I also think that people should be allowed to shoot themselves in the foot if they really want to.

As a much simpler alternative to what is being done today the IDE could have had a simple configuration setting that either allowed editing examples or not.
And if editing was disabled, then the IDE would not do any sort of copying, or any checking for the file being updated. Nothing.
If allowed, then it would use the same code as the "open".
MUCH simpler than the complexity that is there today.

But again, why not allow an external editor to edit the examples like it does on 1.x
This is a pretty big regression, that makes developing Arduino libraries and their examples a bit of PITA when using an external editor.

--- bill

6

image
image495×597 35.2 KB

No. It is based on the understanding that beginners are going to inadvertently make changes to the examples and be very confused later if you allow that.

7

You have quoted me out of context.
So this picture above is not related to my full comment about "read only".
Here is the full comment:

But 1.x doesn't treat the examples as read only.
I can edit them using an external editor and the IDE will notice the updated file.
I have developed Arduino libraries and their examples for over 10 years and always have used an external editor for both the library code and the examples.
i.e. edit code in editor, build with IDE for testing. Repeat.
With 1.x that is possible.
Now with 2.x it is no longer possible.

The most important thing being that with IDE 1.x a user can still edit library example sketches that were opened in the IDE GUI using the "examples" way using an external editor and the IDE will see those changes.
i.e. The example sketches in a library are not read only when using an external editor since the 1.x IDE supports using an external for library example sketches regardless of how the sketch is brought up in the IDE.

The behavior in 2.x is a regression from what can be done in 1.x with an external editor in that with IDE 2.x a user can no longer use an external editor to modify a library example that is currently being used in the IDE when it is brought up using the "examples" method.

You have perfectly described a nanny / guardrail mindset.
This is the mindset that it is necessary to create guardrails and limit functionality with the intent of trying to protect people from themselves.
I'll agree that a nanny / guardrail system can be useful particularly for novices and less technical users, but I also think that there should be a way to disable it for those that don't want or need it.

With IDE 1.x a user could select using an external editor and the IDE would not limit what you could edit when using this external editor. A user was free to edit and modify sketches regardless of where they lived, including if they were library examples.
This is an example of having guardrails that could be removed which is ideal.
By default a novice could and likely would use the IDE editor and would be protected from directly being able to modify a library example which the intent of attempting to protect the user from themselves.
But a more advanced user could turn on the ability to use and external editor with no limitations.

With 2.x it now auto detects a sketch being modified by an external editor so there is no "use and external editor" option.
But then 2.x goes to far.
It also changed/added code to prevent users from being able to modify library sketch example sketches files even when using an external editor.
(users should not have to bring up a library example file using "open" if they later want to modify it)

IMO, a reasonable solution would be bring back the ability for a external editor to be able modify any sketch including library example sketches.
That way novice users using the IDE for editing can still have guardrails and its nanny mode for them to try to protect them from mucking things up.
But advanced users could use an external editor and edit anything they want - which is how 1.x worked.

Consider this.
And advance user can already use his external editor to edit any sketch, including any example sketch under a library.
There is no way for the IDE to prevent this.

So the only thing all that new "read-only" code in the 2.x IDE that prevents the IDE from using a library example sketch that has been modified externally really does is inconvenience the more advanced user, particularly those developing libraries and their examples.

And THAT is why I think the 2.x IDE got it wrong by choosing to intentionally no longer support allowing an external editor to edit library example sketches that were brought up using the "examples" method.

--- bill

8

No. I quoted the only context that was relevant to my response. Arduino IDE 1.x absolutely does treat examples as read-only and my screenshot proves it.

I understand what you are referring to in the rest of the comment, but it has nothing to do with a "read-only" behavior.

I already explained how to do that.

The ability is there, so there is nothing to bring back.

There is no such code. The IDE isn't being prevented from using an example that is modified externally. All that is happening is that you have a different file open in Arduino IDE than the file you are modifying externally.

9

You attempted to alter and change the meaning of my comment by only quoting a fraction of it.
That is the very definition of "out of context".

My comment was stating that the IDE 1.x allows an external editor to modify a library example sketch and IDE 1.x will process the modified sketch file.
This means that from an overall external system behavior point of view, the sketch is not "read-only" since from an overall external system behavior point of view, the sketch is not read only since the IDE is monitoring for it to change and will use the updated/modified file if the file changes. If it were read-only then there would be no need to monitor the file for changes.
The fact that the IDE may have an internal mode called "read only" and choose to enforce some sort guardrail / nanny mechanism to not allow changes made using the IDE editor to overwrite the original sketch is irrelevant as neither of those by themselves mean that the sketch file is read only from an external system point of view.

IDE 2.x does not support processing an externally modified library example sketch when that sketch is pulled in using the "examples" way.
This is a change from IDE 1.x and breaks an IDE behavior that exists in IDE 1.x

No it doesn't, and your screen shot does not prove it.
The screenshot only shows that there is a nanny mode that prevents the user from using the IDE editor to directly overwrite the original library example sketch file.
As I wrote above, from an overall external system behavior point of view the original library example sketch file is not read only just because a nanny protection mode has been implemented.

But it does, particularly when looking at the IDE from an overall external system point of view
(which is what users see / feel, vs what the s/w developer may be thinking when he implemented the code)

The overall/full "read-only" behavior implementation and how it works when using an external editor in IDE 2.x is different than IDE 1.x
The way it is currently implemented in 2.x does not allow IDE 2.x to use and process a library example sketch that has been modified outside of the IDE when the sketch is pulled in using the "examples" way.
This is a behavior change from IDE 1.x and is 100% related to how the "read-only" nanny mode code has been implemented in the 2.x IDE code vs how it was implemented in IDE 1.x

Yeah, use "open", but that neglects the fact that it doesn't work when using the "examples" way which does work with IDE 1.x.

You keep ignoring that in IDE 1.x when you load a library example sketch using the "examples" way (which is the typical/normal way to load a library example) and you then modify that library example sketch with an external editor, the IDE will see the changes and use it.
IDE 2.x does not currently do this.
This is due to how IDE 2.x has implemented the "read-only" guardrail / nanny mode of restricting IDE editor updates to library example sketches.
The 2.x implementation appears to have done in way that currently won't see external sketch updates.

But the ability isn't there.
External editors work differently in IDE 2.x vs DE 1.x
IDE 2.x is missing an external editor capability/behavior that exists in IDE 1.x
The user cannot currently load a sketch using the "examples" under a library and then make changes to that sketch using an external editor and have the IDE use the update file.
This works with IDE 1.x

[/quote]

Uh, Yes there is.
There is code in the IDE that creates and handles a "read-only" nanny mode to add protection guardrails in an attempt to safeguard novice users from hurting themselves by clobbering library example sketches.
Obviously the code implementation of how that is done is different in IDE 1.x and IDE 2.x

The issue of not using/supporting externally modified library example sketches is all wound up in how this nanny read-only mode was implemented in IDE 1.x vs in IDE 2.x

So while there may not be code to explicitly prevent looking at and using a sketch file that is modified externally, it still implicitly happens.
This is because of the 2.x implementation choice of how "read-only" nanny mode was implemented.
If IDE 2.x decided to secretly under the hood create a copy of the library example sketch, that implementation choice, when not combined with also not looking at the original file for changes, breaks the previous behavior in IDE 1.x that has existed for well over 10 years,
This implementation choice in IDE 2.x means that a external editor can no longer edit the original sketch file and have those changes be seen by the IDE since the IDE is now secretly working with different file that is a copy of the original.

The fact is IDE 2.x does not work the same as IDE 1.x with respect to how it handles library example sketches when they are brought up using the "examples" way.
So yes there is an external editor behavior that is different and missing from 2.x that exists in 1.x and that is what I referring to when mentioned:

bring back the ability for a external editor to be able modify any sketch including library example sketches.

--- bill

10

Changes are to be expected from a major version bump in a piece of software.

11

Changes are to be expected from a major version bump in a piece of software.

Agreed, but to claim that this particular change and loss of functionality should be expected, is a total whitewash.

Be honest, this is a bug / oversight.

Why would anybody expect this change?

The 2.x IDE appears to sometimes silently make a copy of a sketch and the user has no indication that it has happened and therefore would not expect that using their external editor would sometimes fail to work since it has always worked in the past with IDE 1.x

i.e. with IDE 1.x an external editor always works on an open sketch, but with IDE 2.x it only works in certain cases.

How can that not be considered a bug?
IMO, if you don't consider that bug, you are way to close to the code and implementation to see the issue.

--- bill

12

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.