Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Candidate for sanitize: Form Placement #600

Open
hecon5 opened this issue Feb 27, 2025 · 1 comment
Open

Candidate for sanitize: Form Placement #600

hecon5 opened this issue Feb 27, 2025 · 1 comment

Comments

@hecon5
Copy link
Contributor

hecon5 commented Feb 27, 2025

One thing that I have been plagued by is working from multiple machines and determining whether the form window information has "actually" changed or changed because I opened it on a new screen / machine and the monitor sizing and placement is different.

See below example of a nigh-constant change. The only change to the form is...I opened it on the same machine, but I was at a different dock location. Sometimes just opening the form in a different screen and then closing it is all that's needed for this to happen.

I tried deleting these and it didn't go well, but if I reset them, the forms import fine.

I don't know that we want to sanitize these out per se, but if someone has any ideas on how to reduce noise on this would be great. Either a pre/post export hook to do this, or something, because I'm stumped.

--    Left =4470
--    Top =2160
--    Right =31680
--    Bottom =19665
++    Left =-25575
++    Top =1230
++    Right =-255
++    Bottom =14865
@bclothier
Copy link
Contributor

IINM those are significant if you are using overlapping windows rather than document tabs, right?

If so, we should only reset if we are using document tabs and the form is not a popup.

I think this is a possible path; editing the patch file. According to copilot:

Editing the patch file programmatically involves manipulating the content of a diff/patch file, which is a plain text file that describes changes between versions of files. Here's how you can handle this:

1. Generate the Patch File
First, you'll need to create the patch file that represents the staged changes. Use the git diff --cached command and redirect the output to a file:

bash

git diff --cached > staged.patch

This creates a file (staged.patch) that contains the staged changes.

2. Process the Patch File
You can write a script to parse and modify the patch file to exclude specific hunks based on a > pattern like "Left =100". Here's how you can approach this in Python:

Example Script (Python)
python

import re

# The pattern to look for in the hunks
pattern = re.compile(r"Left\s*=\s*100")

# Read the patch file
with open("staged.patch", "r") as patch_file:
   lines = patch_file.readlines()

# Prepare to process the patch file
new_patch = []
skip_hunk = False

for line in lines:
    # Detect the start of a hunk
    if line.startswith("@@"):
        skip_hunk = False  # Reset the flag for each hunk

    # Check if the hunk contains the pattern
    if not skip_hunk and pattern.search(line):
        skip_hunk = True  # Skip this hunk

    # Add lines to the new patch unless we're skipping the current hunk
    if not skip_hunk:
        new_patch.append(line)

# Write the modified patch back to a new file
with open("filtered.patch", "w") as output_file:
    output_file.writelines(new_patch)

print("Filtered patch file created: filtered.patch")

3. Apply the Modified Patch
After editing the patch file to exclude the undesired hunks, you can apply the modified patch > back to unstage the changes using git apply --cached:

bash

git apply --cached filtered.patch

This re-applies only the remaining hunks from the modified patch to the staging area, effectively unstaging the hunks you removed.

Key Points
Patch File Structure: Patch files follow a specific format. Understanding the structure (e.g., > file headers, hunk delimiters like @@, and content lines with + or -) is essential for accurate processing.

Backup: Always back up the original patch file before applying changes in case something goes wrong.

Validation: Ensure that your modified patch file is valid by testing it with git apply before re-applying it to the staging area.

By programmatically editing the patch file, you gain fine-grained control over the staged changes and can automate the process of unstaging specific hunks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants