Linux: This operation requires the ICU library

[zcobol]

• install edit on Linux
• open editor and select Find
• This operation requires the ICU library error is being shown

After this error the Edit menu won't show Find and Replace options anymore:

Before selecting Find:

After:

[Neo-vortex]

have you tried this installing it ?
apt-get install libicu-dev
@zcobol

[zcobol]

@Neo-vortex test was done on Fedora 42 (no WSL) and libicu was already installed. After adding libicu-devel it works. Thank for the info!

However, the expectation was that all dependencies to be satisfied by the release at https://github.com/microsoft/edit/releases/download/v1.0.0/edit-1.0.0-x86_64-linux-gnu.xz

[lhecker]

Adding a Unicode-aware regex engine (like the regex crate) to the project would increase the binary size from 200KB to over 700KB. Enabling its performance features would increase it to about 1100KB. Because of this, the editor depends on your OS to provide libicu. In the future it would be nice to have a fallback for the search that at least works with ASCII (and matches Unicode literally, byte-by-byte).

#52 reported the same issue but let's keep them separate and use this issue to track finding the right ICU version. For more info, see here: #52 (comment)

#52 can then be used to focus on the wrong sort order.

[kasini3000]

utf16le +bom my .ps1 file same issue
Suggest adding:
apt-get install libicu-dev
dnf install libicu-devel
on error message .

[emk2203]

Adding a Unicode-aware regex engine (like the regex crate) to the project would increase the binary size from 200KB to over 700KB. Enabling its performance features would increase it to about 1100KB. Because of this, the editor depends on your OS to provide libicu. In the future it would be nice to have a fallback for the search that at least works with ASCII (and matches Unicode literally, byte-by-byte).

I can confirm the issue exists also in Kubuntu 24.10 dev. Even with libicu76 installed, an installation of libicu-dev is needed.

Regarding the filesizes: I was thinking about using edit in rescue systems, but the need to install 52.6 MB of libicu-dev on top of 38.7 MB of libicu76 defeats the purpose. A 197 kB binary is meaningless if it needs 91.3 MB libraries.

In contrast, the standard rescue system editor nano has a 285 kB binary and depends on libc6 (>= 2.38), libncursesw6 (>= 6), libtinfo6 (>= 6) -- 7.1 MB of libraries.

Is it possible to get a self-contained binary which includes a regex-crate? Just the instructions to build on Linux would be fine if they lead to this 1.1 MB binary including everything. Better than having the need for 91.3 MB libraries. In the future, a version including a search fallback would be great.

[lhecker]

If anyone wants to send a PR that adds support for a different regex engine, I'll happily accept it. It has to be a compile-time feature though (i.e. a feature in Cargo.toml). Since the buffer is chunked, it needs to use something like the regex-cursor crate.

However, I'd prefer skipping that part and immediately going to the destination: We should have a fallback that works without a large regex crate. It would disable the regex button entirely (and perhaps even the whole-word button?) and perform only ASCII-case-insensitive matching (non-ASCII would get matched literally). It would be easy to build something like that with a basic Boyer–Moore search algorithm (probably needs a custom solution since the buffer is chunked).

[diabloproject]

I was not able to replicate the issue, even in ubuntu docker, but maybe something like this will fix the "ICU not found" issue?

172.patch.zip

[lhecker]

That's the approach used by C# as far as I know and I'd prefer not adopting it. ICU releases 2 (?) major versions each year and so the list of hardcoded version numbers will quickly run out.

DHowett was prototyping an alternative approach, I believe by peering into the /etc/ld.so.cache IIRC.

[diabloproject]

Not every distribution/environment has it, plus having specific versions means that if they will break the API/ABI somehow, editor will not pick up faulty versions

I agree that this is not the most elegant solution, reading values that will be absent on many environments also does not sound great.