Emoji / Icons in filenames

… is this really needed? :stuck_out_tongue:

It is cool. Looks nice. But, it produces some difficulties in some use cases. Which admittedly might be edge-edge-edge-case.

Im my case, I encapsulated it in an app (see MacOS App... really!?)
I now enhanced that app so show a sidebar navigator of all files inside the chosen folder for SB.

And that works great. Clicking folders unfolds them, clicking files opens them, even if they have empty spaces in the name.
Unless when there is an icon, emoji inside the filename.
Then, it won’t open it and I get some errors in the Swift debug console + Internal Server Error from Deno.

Of course, this is not an issue with SB itself or actually anywhere else I have run SB (the files open just fine anywhere else and it is not technically forbidden, nor unsupported, at least not on a Mac).
But clearly it presents an issue in some cases, and researching it a bit, I read that it is generally something not “really suggested” :wink: due to potential issues.

So my question(s)…

  • could it be avoided? :smiley: (yes I can just edit the files myself. I am referring to, is it “best practice” and should it be “released” with icons?)
  • can anyone hint how to deal with it in a Swift application that calls the file via URL?

The error I get is not actually even related to the Swift app itself, it is from deno:

Requested file 📌 EXAMPLE.md

TypeError: Failed to execute 'set' on 'Headers': Argument 2 is not a valid ByteString
    at makeException (ext:deno_webidl/00_webidl.js:91:10)
    at Array.converters.ByteString (ext:deno_webidl/00_webidl.js:434:11)
    at Headers.set (ext:deno_fetch/20_headers.js:412:44)
    at tl.redirect (file:///home/runner/work/silverbullet/silverbullet/dist/silverbullet.js:27:3113)
    at file:///home/runner/work/silverbullet/silverbullet/dist/silverbullet.js:2378:13384
    at eventLoopTick (ext:core/01_core.js:168:7)
    at async c (file:///home/runner/work/silverbullet/silverbullet/dist/silverbullet.js:27:4231)
    at async file:///home/runner/work/silverbullet/silverbullet/dist/silverbullet.js:27:11451
    at async c (file:///home/runner/work/silverbullet/silverbullet/dist/silverbullet.js:27:4231)

And this is how I build the URL in my sidebar view:

func getEncodedURL(for fileURL: URL) -> URL {
		let relativePath = fileURL.path.replacingOccurrences(of: selectedFolderURL.path, with: "")
		guard let encodedPath = relativePath.addingPercentEncoding(withAllowedCharacters: .urlQueryAllowed) else { fatalError("Failed to encode path") }
		let urlString = "http://localhost:3000\(encodedPath)"
		guard let url = URL(string: urlString) else { fatalError("Invalid URL string") }
		return url
	}

I am totally aware this is not “really” an SB issue. Only somewhat. Thus feel free to remove this post if deemed inadequate for this forum.

At some point (a year or more ago) I thought putting emoji in page names was a clever idea. Early versions of the intro video even suggested you do this. I’ve since stepped away from this practice and don’t do it anymore. With the advent of Page Decorarions there is really no valid reason to still do this, because even if you like the looks you can add those via the prefix decoration.

So my short answer: I’d recommend you not put emojis in page names at this point.

1 Like

Ah you’re talking a out the pin emoji and search emoji. For those virtual pages! Now
I get it.

Right. Yeah I’m open to changing that, but I need a safe alternative (some recognizable prefix) that won’t clash with what people already naturally use in their spaces.

I agree :sweat_smile:

Ah you’re talking a out the pin emoji and search emoji. For those virtual pages! Now
I get it.

Right. Yeah I’m open to changing that, but I need a safe alternative (some recognizable prefix) that won’t clash with what people already naturally use in their spaces.

Yep, exactly. For now I will just exclude them from my navigator, they are not “mine” anyway, so not really needed for the nav.
As for prefix: silverbullet should do? I mean, it is the product name, so reserving it, even if it might clash with a minor subset of users who thought it was good to use, should be OK?