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

Treated as another character when pasted from Finder #220

Open
MakotoYamanaka opened this issue Dec 6, 2021 · 4 comments
Open

Treated as another character when pasted from Finder #220

MakotoYamanaka opened this issue Dec 6, 2021 · 4 comments

Comments

@MakotoYamanaka
Copy link

MakotoYamanaka commented Dec 6, 2021

Short Description

Some characters is treated as another one when pasted from Finder's filename.

Steps to Reproduce the Issue

  1. Make new "Default" document. And input "Exposé".
  2. On Finder, Make new folder and change its name to "Exposé". And copy(command-c) the folder.
  3. On SubEthaEdit, paste to document of step 1.
  4. Find "Exposé".

Expected Result

Find is match with both "Exposé" in steps 1 and 3.

Actual Result

When input "Exposé" to Find field, match only steps 1.
When paste "Exposé" from Finder to Find field, match only steps 3.

Environment

  • SubEthaEdit: Version 5.2.2 (9788)
  • System: Version 11.6.1 (Build 20G224)
  • Language: Japanese
Hardware:

    Hardware Overview:

      Model Name: MacBook Pro
      Model Identifier: MacBookPro16,1
      Processor Name: 8-Core Intel Core i9
      Processor Speed: 2.3 GHz
      Number of Processors: 1
      Total Number of Cores: 8
      L2 Cache (per Core): 256 KB
      L3 Cache: 16 MB
      Hyper-Threading Technology: Enabled
      Memory: 16 GB
      System Firmware Version: 1715.40.15.0.0 (iBridge: 19.16.10548.0.0,0)
@MakotoYamanaka
Copy link
Author

MakotoYamanaka commented Dec 6, 2021

In Japanese, this issue often occurs. and very inconvenience.
For example Japanese word "マジック".

I'm not familiar with this issue, but it seems that there is a problem with Unicode normalization in the Finder or File System.
But TextEdit does not occur this issue. So I want you to fix it if you possible please.

@m4p
Copy link

m4p commented Jan 26, 2022

This happens because APFS stores the character as its decomposed form (U+0065 U+0301) while normal text is usually composed (U+00E9). TextEdit does preserve these representations, but matches both while searching. Maybe oniguruma has an option that can be enabled to have this behaviour in SEE as well.

Alternatively both search input and document string can be decomposed to a canonical form via decomposedStringWithCanonicalMapping

@m4p
Copy link

m4p commented Jan 26, 2022

@MakotoYamanaka As a work-around you can drag the folder to the document. That will paste its full path in composed form.

@MakotoYamanaka
Copy link
Author

@m4p Thanks for the work-around.
However, input by drag and drop was the same as pasting from Finder, and was treated differently from "Exposé" by input.

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