Some headline tags not visible when many tags present

[amake]

An issue not directly related to this commit, but since you delved into the tags improvement, I would like to bring it up here. Multiple tags are being truncated based on the screen width, and there is no way to view the entire tags. See the example below.

Org-mode source:

* multiple headline tags  :BAR:FOO:BAZ:タグ:QUX:Archive:

_Originally posted by @llcc in a3795a1_

[amake]

This is ultimately a design problem.

The current implementation tries to show the tags on right, regardless of the width of the screen. This requires that we don't treat the headline as a regular line of text, but rather two boxes that must split the horizontal space according to some rule. Currently that rule is that the tags can take up to 1/3 of the full width. Also, when the section is closed we show an ellipsis.

Closed

Open

I think it's fairly important to keep the headline to a single line when the section is closed (I do allow the title to wrap, but let's assume a non-wrapping title). So I think the current closed layout is OK. But when open we could stop truncating the tags:

Open (tweak: no truncating)

Another possibility is to give up on aligning the tags to the right, and just treat the headline as a single line of text that can wrap. I don't like that idea for Reader Mode, but it's plausible for when Reader Mode is off.

Closed (Reader Mode off; tweak: no fancy layout)

Open (Reader Mode off; tweak: no fancy layout)

Do you generally use Reader Mode? What do you think of the above tweaks?

[llcc]

Do you generally use Reader Mode?

I rarely use Reader Mode, since it reflows the text in the list, which disrupts the multi-line items I use a lot.

When closed, I agree that tags should be truncated. However, how about adding a sliding gesture to view the full tags? While this might conflict with the TODO cycling gesture, we could limit the sliding functionality to only affect the tags.

When open, I personally prefer treating the headline and tags as a normal line without trying to align them, because it breaks aesthetics if the headline wraps one char to the next line while tags also wrap one. Having them wrap together feels more cohesive. In this case, it might be better to tone down the color of the tags.

What do you think?

[amake]

However, how about adding a sliding gesture to view the full tags?

I think this is a bit too magical and hard to discover.

When open, I personally prefer treating the headline and tags as a normal line without trying to align them

I do think this is compelling, and I tried making that the behavior for both Reader Mode and non-Reader Mode, but it's too jarring in Reader Mode to go from "fancy" layout to textual layout.

it breaks aesthetics if the headline wraps one char to the next line while tags also wrap one.

There are always going to be combinations of content and width that end up with somewhat unfortunate outcomes, so I'm not really that concerned with avoiding that entirely.

it might be better to tone down the color of the tags.

The colors are org-mode defaults, so I wouldn't change them, but a theme customization feature is something I would consider.

My current thinking is to go with the scheme I described above.

[amake]

The changes described above will be available for testing in v1.43.2 soon:

• iOS
• Android

[llcc]

The trailing spaces after the headline should be trimmed as one, or the display gets weird on narrow screen.

* Tags
** Multiple headline tags.         :BAR:FUB:ARCHIVE:DESIGN:EFFORT:FINAL:

Contents

[amake]

If you want the text to be reflowed for narrow screens, you should use Reader Mode.

[llcc]

Yes. It solved part of the issue, but the spaces should still be taken care of.

Also, the line with : inside begins to display not correctly.

** Multiple headline tags.         :BAR:FUB:ARCHIVE:DESIGN:EFFORT:FINAL:

Contents

- Eq.1: [cite:@canale-2014-harden;see page 5]：

[amake]

but the spaces should still be taken care of

If I remove them then someone will complain that they should be there (when the screen does fit the original assumed width).

Also, the line with : inside begins to display not correctly.

Does it look different with Reader Mode off? When I reproduce your layout (by adjusting the font size so that just ： wraps) I find that it wraps regardless of Reader Mode.

I am not able to prevent many cases of wrapping, even if it would correctly not wrap in "plain" text, because rendering various constructs (in this case the citation) with special styling and the ability to tap, etc., means they wrap as a unit instead of at word or character boundaries. If it's even possible to improve on this, it would probably require rearchitecting the entire rendering mechanism.

[llcc]

If I remove them then someone will complain that they should be there (when the screen does fit the original assumed width).

How about filling the spaces dynamically (I mean calculating the space number based on the width) for visualization?

Does it look different with Reader Mode off?

It's not related to Reader Mode from my observation.

means they wrap as a unit instead of at word or character boundaries.

Not sure if it matters about the paragraph alignment. Orgro left-aligned the paragraph, does it change if we make it justified?

[amake]

How about filling the spaces dynamically (I mean calculating the space number based on the width) for visualization?

This will be in v1.43.4.

Orgro left-aligned the paragraph, does it change if we make it justified?

There are no justification controls. I don't see how justification would change line break locations.