[RFC PATCH] Search for "modified" objects includes "new deleted" objects, which is distracting

[mattmccutchen]

I frequently review my work by searching for modified with the "all objects" box checked. I do want to review objects that exist on the server that I've deleted in my layer, but I've noticed that the search also includes objects that I created and then deleted locally without ever uploading them to the server. This is distracting because such "new deleted" objects don't represent a change that would be uploaded and thus don't need to be reviewed. (The upload dialog correctly filters them out.) In fact, I was surprised that "new deleted" objects are retained in the layer at all, since they have no significance to any workflow I can imagine.

I propose that the modified keyword shouldn't match "new deleted" objects. A workaround is to search for modified -(new deleted), and it's easy enough to save that as a toolbar button.

Note that the modified keyword correctly does not match objects that are deleted both on the server and in the layer (call them "already deleted" objects). For reference, I know of two ways to generate "already deleted" objects: download them from a changeset in the Changeset Manager, or use the undelete plugin to undelete an object and then delete it again. So I'm proposing that the modified keyword should handle "new deleted" objects consistently with "already deleted" objects.

What steps will reproduce the problem?

1. Ensure expert mode is on.
2. Create a new local layer.
3. Create a node and then delete it.
4. Search for modified with the "all objects" box checked.

What is the expected result?

The search has no results.

What happens instead?

The search matches the node from step 3.

Please provide any additional information below. Attach a screenshot if possible.

According to my analysis, the problem happens because the condition in SearchCompiler.Modified.match is osm.isModified() || osm.isNewOrUndeleted(), and both disjuncts are true for "new deleted" objects. FLAG_MODIFIED is true because AbstractPrimitive.setDeleted does setModified(deleted ^ !isVisible()), and new objects have FLAG_VISIBLE true (a questionable design in my view). And of course, osm.isNewOrUndeleted() is true for all new objects.

I can imagine a few levels at which the problem could be fixed:

1. Don't retain "new deleted" objects in the layer at all; purge them as soon as they are deleted.
2. Handle new objects more uniformly with objects deleted on the server by turning off FLAG_VISIBLE for new objects. Then "new deleted" objects will have FLAG_MODIFIED set to false according to the AbstractPrimitive.setDeleted logic above. Further, instead of having SearchCompiler.Modified.match call osm.isNewOrUndeleted, which expands to isNew() || ((flags & (FLAG_VISIBLE + FLAG_DELETED)) == 0), just test the second part of the condition, (flags & (FLAG_VISIBLE + FLAG_DELETED)) == 0 (which could be encapsulated in a new helper method of AbstractPrimitive). With these changes, SearchCompiler.Modified.match would no longer match new deleted objects.
3. Just change the condition in SearchCompiler.Modified.match somehow so that it doesn't match new deleted objects.

Of course, fixing the problem at a deeper level has the potential benefit of fixing other problems related to new deleted objects and enabling code simplifications, but it presents a much higher risk of breaking other code in JOSM. So my proposal would be to start with approach 3. That doesn't preclude implementing a deeper fix later if the benefit is found to outweigh the cost.

Relative:URL: ^/trunk
Repository:UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
Last:Changed Date: 2026-10-27 08:20:52 +0100 (Tue, 27 Oct 2026)
Revision:19668
Build-Date:2026-10-28 02:30:40
URL:https://josm.openstreetmap.de/svn/trunk

Identification: JOSM/1.5 (19668 en) Linux Fedora Linux 44 (Forty Four)
Memory Usage: 234 MB / 4072 MB (132 MB allocated, but free)
Java version: 25.0.4.1+1, Red Hat, Inc., OpenJDK 64-Bit Server VM
Look and Feel: javax.swing.plaf.metal.MetalLookAndFeel
Screen: :0.0 1920x1080x[Multi depth]@46Hz (scaling 1.00×1.00)
Maximum Screen Size: 1920×1080
Best cursor sizes: 16×16→16×16, 32×32→32×32
Environment variable LANG: en_US.utf8
System property file.encoding: UTF-8
System property sun.jnu.encoding: UTF-8
Locale info: en_US
Numbers with default locale: 1234567890 -> 1234567890
Desktop environment: X-QUBES
VM arguments: [--add-exports=java.base/sun.security.action=ALL-UNNAMED, --add-exports=java.desktop/com.sun.imageio.plugins.jpeg=ALL-UNNAMED, --add-exports=java.desktop/com.sun.imageio.spi=ALL-UNNAMED, -Djosm.home=<josm.pref>]
Dataset consistency test: No problems found

[mattmccutchen]

Here's a patch demonstrating one possible way of modifying SearchCompiler.Modified.match to fix the problem. There are a few plausible ways of writing the new condition, which may differ in performance and the handling of corner cases that may or may not ever occur in JOSM. If this approach would be acceptable, I can polish up the patch with comments and tests.