Conversation
| if type(v) == "table" and not v.ignored_by_menu_search then | ||
| local entry_text = v.text_func and v.text_func() or v.text | ||
| is_disabled = is_disabled or v.enabled == false or (v.enabled_func and v.enabled_func() == false) | ||
| local entry_displayed_text = is_disabled and "\u{2592} " .. entry_text or entry_text -- Medium Shade + Hair Space |
There was a problem hiding this comment.
(If that space that looks like a space in github is really a hair space, I'd rather see it as \u{200A}.)
oh, also on next line, so may be there: all spaces here and above are Hair Space U+200A
| local indent = text and ((" "):rep(math.min(depth-1, 6)) .. "→ ") or "→ " -- all spaces here are Hair Space U+200A | ||
| local walk_text = text and (text .. "\n" .. indent .. entry_text) or (indent .. entry_text) | ||
| is_disabled = is_disabled or v.enabled == false or (v.enabled_func and v.enabled_func() == false) | ||
| local entry_displayed_text = is_disabled and "▒ " .. entry_text or entry_text |
There was a problem hiding this comment.
I preferred when you used "\u{2592} " ... - Medium Shade + Hair Space.
That's been our usage recently (may be not here with the arrows, but recently in the skimwidget rtl arrows).
There was a problem hiding this comment.
On average I don't really like the look of \u{2592} and such and I prefer to avoid it when reasonable, but the comment saying there's a hair space is quite important either way to avoid future mishaps.
Edit: but I don't particularly mind the \u{} thing when it's not strictly necessary either, we're talking a very minor preference. And the shade looks more weird than clear like an arrow. :-)
There was a problem hiding this comment.
Answer please:
(1) ▒ or \u{2592}
(2) → or \u{2192}
(3) "Hair Space" comment in both lines or in the second line only ("here and above")
koreader/frontend/ui/widget/touchmenu.lua
Lines 1031 to 1032 in c433c1b
There was a problem hiding this comment.
My preference is to use \u{} notation for anything not ASCII.
On github and in proper editors (ie. all but mine :)), they will look OK. (I use a latin1 terminal, so these look like crap, but it's my problem I know).
But the fact is that nobody will be able to type it, we all must be just copy & paste ▒ from somewhere else. And to find out what it is, I had to copy it into a google search to get its codepoint.
So, I prefer \u{} which 1) shows up in all kind of editors and in github and 2) document the codepoint.
For stuff that is translatable and/or is only regular ASCII and may have/need hairspaces, I'll be ok to just have a comment saying these spaces are hairspaces, to keep the longer string readable.
There was a problem hiding this comment.
(1) ▒ or \u{2592}
Probably the latter; the former looks a bit like a rendering bug. :-)
(2) → or \u{2192}
I much prefer →
But there's certainly no need to go changing any if they happen to be different, and if @poire-z prefers the latter I'm okay with that too. It might be worth putting the → in the comment alongside the name in that case.
(3) "Hair Space" comment in both lines or in the second line only ("here and above")
I'd just stick it on each line for the future.
3 participants
(1) Do not open the upper menu when Menu search dialog is called by a gesture/profile.
(2) In search results dialog mark disabled items with "medium shade".
(3) "Open/walk" doesn't highlight disabled items (text of disabled highlighted item is not visible).
(4) "Open/walk" stops on the first disabled menu item if it has subitems.
"Open/walk" will show:
This change is