problems in mail buffers using orgalist

[ouboub]

Hi

First for all thanks for nice package, this is much more useful for me than visual-line-mode, especially in org buffers. It is even quite useful in mails, however there are two issues:

1. a minor one considers the address fields such as CC, these are
   sometimes strangely displayed when visual-fill-column mode is on.

2. The second one concerns the use of orgalist-mode in mail buffers.
   This mode allows to have (enumerated) lists. When I turn
   visual-fill-column, while they are not when visual-fill

So the prefix is not taken into account. Is there any change to add such a feature?

regards

Uwe Brauer

[joostkremers]

Hi Uwe,

The first issue probably has to do with there being hard newlines at the end of the relevant lines. The only way to deal with it that I know of is to simply widen the text area (set fill-column or visual-fill-colum to a larger value). Unfortunately, it's not possible to enable the effect of visual-fill-column-mode in only parts of the buffer.

As for the second problem, I'm not entirely sure if it's really a bug, but if it is, it's probably not in visual-fill-column-mode. If I start Emacs with -Q and then activate just visual-line-mode, orgalist-mode and adaptive-wrap-prefix-mode, I get the effect seen in your first screenshot (i.e., it occurs without visual-fill-column-mode).

The only way I get the effect in the second screenshot is when I hard-wrap the list items (which I suspect the list item in your example is, as well, otherwise it wouldn't be wrapped in the second screenshot). So, at least in non-Org buffers (I tried this in text-mode), adaptive-wrap-prefix-mode doesn't seem to add some additional indent to the second visual line of a list item.

It's different in Org files, where adaptive-wrap-prefix-mode does indeed cause the second visual line of the list item to be indented beyond the item number. But I'm not sure how that works, and I'm not sure if orgalist-mode is supposed to have the same effect in non-Org buffers.

Anyway, a proper analysis would require more info, but like I said, I'm pretty sure visual-fill-column-mode is not the cause of the bug, nor is it the place to fix it. After all, visual-fill-column-mode doesn't do much more than widening the margins, so that the text area is narrowed. It does not handle wrapping, and it's oblivious of adaptive-wrap-prefix-mode.

[ouboub]

>> "JK" == Joost Kremers ***@***.***> writes:

Hi Joost Thanks for the detailed answer.

Hi Uwe, The first issue probably has to do with there being hard newlines at the end of the relevant lines. The only way to deal with it that I know of is to simply widen the text area (set `fill-column` or `visual-fill-colum` to a larger value). Unfortunately, it's not possible to enable the effect of `visual-fill-column-mode` in only parts of the buffer.

Ok

As for the second problem, I'm not entirely sure if it's really a bug, but if it is, it's probably not in `visual-fill-column-mode`. If I start Emacs with `-Q` and then activate just `visual-line-mode`, `orgalist-mode` and `adaptive-wrap-prefix-mode`, I get the effect seen in your first screenshot (i.e., it occurs without `visual-fill-column-mode`). The only way I get the effect in the second screenshot is when I hard-wrap the list items (which I suspect the list item in your example is, as well, otherwise it wouldn't be wrapped in the second screenshot). So, at least in non-Org buffers (I tried this in `text-mode`), `adaptive-wrap-prefix-mode` doesn't seem to add some additional indent to the second visual line of a list item.

Ok, the question is how does a hard-wrap (or a hard-newline occur) I just checked here in this bufer ,---- | use-hard-newlines is a variable defined in ‘paragraphs.el’. | Its value is nil `----

It's different in Org files, where `adaptive-wrap-prefix-mode` does indeed cause the second visual line of the list item to be indented beyond the item number. But I'm not sure how that works, and I'm not sure if `orgalist-mode` is supposed to have the same effect in non-Org buffers.

This is what puzzles me, I asked on the org list but I did not obtain really useful information, save one proposal that I tried but what did not work.

Anyway, a proper analysis would require more info, but like I said, I'm pretty sure `visual-fill-column-mode` is not the cause of the bug, nor is it the place to fix it. After all, `visual-fill-column-mode` doesn't do much more than widening the margins, so that the text area is narrowed. It does not handle wrapping, and it's oblivious of `adaptive-wrap-prefix-mode`.

So do you thing that the culprit would be adaptive-wrap-prefix-mode?

[joostkremers]

So do you thing that the culprit would be adaptive-wrap-prefix-mode?

Actually, I don't think "culprit" is the right word for it. It doesn't seem that adaptive-wrap-prefix-mode by itself is meant to take care of this. In Org and Markdown buffers, using visual-line-mode and adaptive-wrap-prefix-mode, the second line of a list item is visually indented beyond the list marker, but in a text-mode buffer, the very same Org or Markdown file is displayed without the extra indentation.

The difference is that org-mode and markdown-mode each set adaptive-fill-function to a function that computes a wrap prefix, while text-mode does not. It's this function that is responsible for providing the correct wrap prefix. Without it, adaptive-wrap-prefix-mode is probably not smart enough to handle lists correctly.

[ouboub]

>> "JK" == Joost Kremers ***@***.***> writes: > So do you thing that the culprit would be adaptive-wrap-prefix-mode? The difference is that `org-mode` and `markdown-mode` each set `adaptive-fill-function` to a function that computes a wrap prefix, while `text-mode` does not. It's this function that is responsible for providing the correct wrap prefix. Without it, `adaptive-wrap-prefix-mode` is probably not smart enough to handle lists correctly.

Very interesting, so I tried first (add-hook 'orgalist-mode-hook (setq-local adaptive-fill-function #'org-adaptive-fill-function)) (add-hook 'message-mode-hook (setq-local adaptive-fill-function #'org-adaptive-fill-function)) (add-hook 'text-mode-hook (setq-local adaptive-fill-function #'org-adaptive-fill-function)) That resulted in an error: ,---- | | Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p nil) | org-adaptive-fill-function() | run-hooks(change-major-mode-after-body-hook text-mode-hook message-mode-hook) | apply(run-hooks (change-major-mode-after-body-hook text-mode-hook message-mode-hook)) | run-mode-hooks(message-mode-hook) | message-mode() | message-pop-to-buffer("*unsent mail*" nil) | message-mail() | gnus-group-mail(nil) | funcall-interactively(gnus-group-mail nil) | call-interactively(gnus-group-mail nil nil) | command-execute(gnus-group-mail) `---- So somebody on the org list suggested some time ago, to try out ,---- | (defun org-adaptive-fill-function () | "Fill headlines to the beginning of headline in org." | (save-excursion | (cond | ((org-at-heading-p) | (beginning-of-line) | (looking-at org-complex-heading-regexp) | (goto-char (or (match-beginning 4) (match-end 0))) ;; at headline | (make-string (current-column) ?\ )) | ((org-at-item-p) | (beginning-of-line) | (looking-at org-list-full-item-re) | (goto-char (or (match-beginning 4) (match-end 3) (match-end 2) (match-end 1))) | (skip-chars-forward " \t") | (make-string (current-column) ?\ ))))) `---- Which is not the original function, but a simplified one. That I could load without problems, but it did not do the adaptive filling I was looking for. I will write again to the org mailing list. Regards Uwe

[ouboub]

I just saw this on the mailing list by a lead developer Nicolas Goaziou ***@***.***> ,---- | | > So the prefix is not taken into account. Anybody seeing this and knows | > a solution? | | Orgalist mode does not handle virtual indentation. Patches welcome, | however. `---- So I will close that bug, sorry for the noise.

[ouboub]

the culprit is orgalist