Open Bug 1587153 Opened 6 years ago Updated 5 months ago

Add dynamic control over wraplength to editor

Categories

(Thunderbird :: Message Compose Window, enhancement)

Product:
Thunderbird
Component:
Message Compose Window
Type:
enhancement

Tracking

(Not tracked)

Status:
UNCONFIRMED

People

(Reporter: jan.kiszka, Unassigned)

Details

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Firefox/68.0

Steps to reproduce:

Generally, I compose emails with wraplength set to the default 72 characters. However, sending out patches or content that should not be wrapped requires to disable this frequently as well. So far, I was using the Toggle Word Wrap addon to provide direct, per message control over this feature.

Actual results:

Well, that addon broke over TB API changes, the maintainer stepped back (apparently), and I had to fix this locally (will be submitted for the addon registry soon).

Expected results:

I wonder if such an essential feature for us developers shouldn't finally become part of the official UI. That would likely be simple to add and maintain, much simpler than an addon.

I addition, I'd like to see the current mode being visualized as well, to avoid sending out messages with the wrong mode active. E.g. when wrapping is on, the composer window could mark the area where no text will ever end up gray.

Wow, some people are discussing the usefulness of plaintext mail and here is someone who wants to control the wrapping in the UI.

I don't think that will happen, so we're back in add-on territory.

Magnus?

Flags: needinfo?(mkmelin+mozilla)

TB is THE bridge between the HTML fanboys, corporate environments and all that stuff on one side and professional developers with "classic" email-based workflows like me on the other. Plaintext email support is a cornerstone in this. Removing that would kill TB from our desktops.

That said, I would be fine with add-on as well if that were no unstable area now. For me, the future of add-ons, namely their ability of changing significant parts of the UI, is totally unclear. If you are really shutting down legacy extensions with TB78 while webextension do not have the same power, yet or by design, that will bring a massive friction. It already does so because not all add-on developers have enough bandwidth to follow the pace of changes in the recent versions. My TB68 add-on tab is still half grey.

FWIW, I've also re-animated Toggle Word Wrap: https://addons.thunderbird.net/de/thunderbird/addon/toggle-word-wrap/. Still a legacy add-on because I have no time to dig into the details of the new APIs - probably until the TB78 security upgrade of my distro forces me again.

I'd like to understand why you want this? Are you sending diffs inline? Why not as attachment instead? How are you inserting it into the mail?

Flags: needinfo?(mkmelin+mozilla)

Yes, inline diffs is what you want for emai-based workflows. Patches as attachments are generally disliked because they make it hard to impossible to comment on them, well, inline. If you want to know what we are looking for:

So the mails contains only the patch, or also some preamble? So you then need to manually linebreak your preamble text?
Is there samples somewhere? I'm thinking of ways we could possibly automate doing the "right thing".

The linebreaks are added during patch editing already, usually on git commit (of course, works equally with hg ;) ). Then I extract the patch, e.g. via git format-patch, and paste it into the editor window. I've some local script to even fill subject and addresses automatically by calling thunderbird -compose. Here is a sample commit: https://github.com/siemens/jailhouse/commit/0943a095a97df22273c128b5dafe838edc1be537.patch. Of course, this process is only for single patches, not for series that are better submitted via git send-email.

Before only thinking of patches though: There is another use case around pasting in wider text blocks that should not be wrapped, e.g., logs. When doing that, I tend to disable wrapping as well. For paragraphs that should still be wrapped, I use the following pattern: While wrapping is on, mark them and select "rewrap" (Ctrl-R), then disable wrapping before submission.

Actually, that rewarp trick no longer seem to work, it longer injects enforced line breaks.

Any update on this request?

Meanwhile I had to rewrite the add-on for TB78 (https://addons.thunderbird.net/de/thunderbird/addon/toggle-line-wrap). As it still hooks deeply into the core, a proper upstream solution would be preferred.

So this boils down to either:

  • automatically detect desired wrap behavior
  • adding a UI option to set and reset gMsgCompose.wrapLength
  • allowing get, set and reset of gMsgCompose.wrapLength via WebExtension API

Which route do we want to take?

Severity: normal → S3

As the Toggle Line Wrap add-on has to use an Experiment API, maintaining it will become harder and harder. So, solving this issue upstream would be even more valuable soon.

To whom did you direct those questions back then, John?

Nobody answered here, so I think this is add-on territory. But doable. I will create a pure WebExtension POC.

I need to bring up this unsolved issue again: The demand for this feature persists, see e.g. https://lore.kernel.org/lkml/20251226-docs_thunderbird-toggle-line-wrap-v2-1-aebb8c60025d@kernel.org/, and we still have the unfortunate situation that neither there is native, addon-free support for it, nor is there an official addon API so that we can drop the experiment from https://github.com/jan-kiszka/togglelinewrap. The latter now regularly receives micro-updates, just to follow latest TB versions, re-validating the that custom API still works. The POCs to implement the feature with the existing APIs failed.

You need to log in before you can comment on or make changes to this bug.