MIME-encode long lines in outgoing mail?

[Uday Reddy]

Left over from Bug Report #515717

[vm-fill-paragraphs-containing-long-lines modified in release 8.1.0. vm-fill-long-lines-in-reply is yet to be handled.]

This is now taken care of. Word-wrapping is not working correctly with fill-prefixes. So, disabled it.

But, a new problem is brought forth by Eli below.

[mere user (emacs-user)]

Hi Uday, I am not sure this is related to this problem, but it might be the closest place for this: I am now using
(add-hook 'vm-presentation-mode-hook 'turn-on-visual-line-mode)
and it seems to do fine with filling paragraphs when I view messages. but when I reply, a message such as the one attached below shows in the quoted text as unfilled lines. best, E

Mime-Version: 1.0 (Apple Message framework v1078)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
X-Mailer: Apple Mail (2.1078)
From:
To:
Subject:
Date:

Xx xxxs. (X'x xxxxxxxxx xx xxxxxxxxx Xxx xx xxxs xxssxxx)=20

Xx xxxxxsxxxxxxx xs xxxx xxx x-xxxx xxxxs xxx xxxx xxpxxxxxx xx xxx =
spxxxxxx xxxxx xxxxxx xxxx xxx xx2 xxxxxx. Xxx xxx xxxx-xx2 =
sxxxxxxxxxs, xxx xxxsx xxxxx X xxx wxs xxx xxx sxxxxxxx XXX *wxxxxxx* =
xxx sxxb xxxxx xxxxx (x.x., xxxxx SSXs) xxx 5 xxxxs xxx xxxx xsxx xxx =
xxxxxxxxx xxx xxxxxxxxxxx pxxxxxxs xxxx xxx pxxvxxxx xx xxx xxx xxxbxxx =
xx xxxxxxxx xxx x-xxxx xxxxs xxx xxx sxxb xxxxx sxx. Xxxx X xxx xxx =
XXX+SXX sxx xxx xbxxx 45 xxxxs xx xxkx sxxx xx xxx xxxxxxx xxxxxxbxxxx.

[Uday Reddy (reddyuday)]

mere user writes:

> Hi Uday, I am not sure this is related to this problem, but it might
> be the closest place for this: I am now using (add-hook
> 'vm-presentation-mode-hook 'turn-on-visual-line-mode) and it seems
> to do fine with filling paragraphs when I view messages. but when I
> reply, a message such as the one attached below shows in the quoted
> text as unfilled lines. best, E

You are right. VM & mail-mode are not doing the message sending
right. If there are long lines, they should be mime-encoding it.
This will need some work.

Cheers,
Uday

[Uday Reddy (reddyuday)]

At the moment, there are two solutions to this problem.

- You can use C-c C-q to fill the yanked text. (This is standard
mail-mode.) Or,

- You can set the variable vm-fill-long-lines-in-reply-column to
something, say the same value as that of fill-column.

Cheers,
Uday

[mere user (emacs-user)]

ok, will try that
thanks

[mere user (emacs-user)]

I am getting some error message that **might** be related to vm-fill-long-lines-in-reply-column. is the attached helpful? I could investigate this a bit more if needed, let me know.

  (setq ad-return-value (ad-Orig-vm-do-reply to-all include-text count))
  (progn (vmpc-init-vars (quote reply)) (vmpc-build-true-conditions-list) (vmpc-build-actions-to-run-list) (vmpc-run-actions) (setq ad-return-value (ad-Orig-vm-do-reply to-all include-text count)) (vmpc-create-sig-and-pre-sig-exerlays) (vmpc-make-vars-local) (vmpc-run-actions))
  (let (ad-return-value) (progn (vmpc-init-vars ...) (vmpc-build-true-conditions-list) (vmpc-build-actions-to-run-list) (vmpc-run-actions) (setq ad-return-value ...) (vmpc-create-sig-and-pre-sig-exerlays) (vmpc-make-vars-local) (vmpc-run-actions)) ad-return-value)
  vm-do-reply(nil t 1)
  vm-reply-include-text(1)
  call-interactively(vm-reply-include-text nil nil)
  (setq ad-return-value (ad-Orig-vm-do-reply to-all include-text count))
  (progn (vmpc-init-vars (quote reply)) (vmpc-build-true-conditions-list) (vmpc-build-actions-to-run-list) (vmpc-run-actions) (setq ad-return-value (ad-Orig-vm-do-reply to-all include-text count)) (vmpc-create-sig-and-pre-sig-exerlays) (vmpc-make-vars-local) (vmpc-run-actions))
  (let (ad-return-value) (progn (vmpc-init-vars ...) (vmpc-build-true-conditions-list) (vmpc-build-actions-to-run-list) (vmpc-run-actions) (setq ad-return-value ...) (vmpc-create-sig-and-pre-sig-exerlays) (vmpc-make-vars-local) (vmpc-run-actions)) ad-return-value)
  vm-do-reply(nil t 1)
  vm-reply-include-text(1)
  call-interactively(vm-reply-include-text nil nil)

[Uday Reddy (reddyuday)]

mere user writes:

> I am getting some error message that **might** be related to vm-fill-
> long-lines-in-reply-column. is the attached helpful? I could
> investigate this a bit more if needed, let me know.

I don't see any error here. Most of the backtrace is in vm-pcrisis
and seems quite normal. What is the error you are getting?

By the way, please feel free to open *new* bug reports unless you are
sure that your report is really duplicating an earlier bug. (I know
that Launchpad encourages you to reuse old bug reports.) It is easy
enough to merge them if they are duplicates. But it isn't possible to
seperate the bug reports if they are already merged.

Cheers,
Uday

[mere user (emacs-user)]

The error message is

fill-delete-newlines: Invalid search bound (wrong side of point)

I was indeed trying to be a good citizen by following the launchpad instructions... promise not to do so again
:)

[Uday Reddy (reddyuday)]

Boy, you are really unlucky.

If you recall, you had a very similar error earlier in:

  https://bugs.launchpad.net/vm/+bug/493958

However, it was for viewing messages and you tracked it down to
u-vm-color.

Now, you seem to be getting the same error while sending messages and
this time vm-pcrisis seems to be doing the mischief. I will have a
think about it.

Cheers,
Uday

[Uday Reddy (reddyuday)]

mere user writes:

> The error message is
>
> fill-delete-newlines: Invalid search bound (wrong side of point)

I gather that setting debug-on-error did not stop at the error? If
so, please try it with debug-on-signal set to t. This is a really
painful setting. The debugger gets entered at spurious places. When
it does, you should just type c to continue.

I will definitely need a backtrace at the point of error to know what
is going wrong.

Cheers,
Uday

[mere user (emacs-user)]

here it is with debug-on-signal set to t. are you not using u-vm-color? is there something more fun I should be using instead?

Debugger entered--Lisp error: (error "Invalid search bound (wrong side of point)")
  re-search-forward("\\([.?!][]\"'”)}]*\\($\\|[  ]$\\| \\|[  ][  ]\\)\\|[。．？！]+\\)[   \n]*$" #<marker (moves after insertion) at 1994 in reply to xx> t)
  fill-delete-newlines(1998 #<marker (moves after insertion) at 1994 in reply to xx> left nil nil)
  fill-region-as-paragraph(1994 1989 nil nil)
  fill-region(391 1955)
  vm-fill-paragraphs-containing-long-lines(window-width 333 2270)
  vm-fill-long-lines-in-reply()
  ad-Orig-vm-do-reply(nil t 1)
  vm-do-reply(nil t 1)
  vm-reply-include-text(1)
  call-interactively(vm-reply-include-text nil nil)

[Uday Reddy (reddyuday)]

Good, vm-pcrisis didn't give the error. It looks like Emacs library
fill.el might be at fault. VM has asked Emacs to fill the region
between positions 391 and 1955. You can also probably try and do the
same interactively. If it gives an error, then you should file a bug
report with Emacs.

Cheers,
Uday

[Uday Reddy (reddyuday)]

Uday Reddy writes:

> *** This bug is a duplicate of bug 515717 ***
> https://bugs.launchpad.net/bugs/515717
>
> ** This bug has been marked a duplicate of bug 515717
> filling and word wrapping
>
> --
> vm-fill-long-lines-in-reply
> https://bugs.launchpad.net/bugs/549180
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in VM (View Mail) for Emacs: Confirmed
>
> Bug description:
> Left over from Bug Report #515717
>
> The vm-rfaddons library in 8.0.x series automatically located the longlines
> library and used it for word wrapping. The 8.1.x version does not do this.
> Instead the function vm-fill-paragraphs-by-longlines asks the user to use
> advice to invoke it instead of the usual filling.
>
> The change was made in revision 516, dated 2008-02-09, which says "Rewrote
> vm-fill-paragraphs-containing-long-lines handling and related." It is not clear
> why this was done. vm-fill-long-lines-in-reply was also eliminated.
>
> This needs to be looked at again, and the missing functionality brought back.
>
> [vm-fill-paragraphs-containing-long-lines modified in release 8.1.0.
> vm-fill-long-lines-in-reply is yet to be handled.]
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/vm/+bug/549180/+subscribe
>
>

[mere user (emacs-user)]

I had to turn off vm-fill-long-lines-in-reply. I believe it led to changes in filling behavior in latex (auctex): when I write a long line in a latex file, it would be filled with a prefix of " > " at the beginning of the new line... :-) !! this might be due to the interaction of fill-lines-in-reply and the open-line features of vm, somehow leaking to the latex mode. Given that you are already working on this, I wont attempt a detailed bug report for now... (?)
E

[Uday Reddy (reddyuday)]

mere user writes:

> I had to turn off vm-fill-long-lines-in-reply.

I have now turned on vm-fill-long-lines-in-reply by default. Perhaps
I shouldn't.

> I believe it led to changes in
> filling behavior in latex (auctex): when I write a long line in a latex file,
> it would be filled with a prefix of " > " at the beginning of the new line...
> :-) !!

Sounds terrible. Please send me a vm-submit-bug-report along with a
sample message, whenever you get a chance. This won't be easy to
track down.

Cheers,
Uday

[mere user (emacs-user)]

> Good, vm-pcrisis didn't give the error. It looks like Emacs library
> fill.el might be at fault. VM has asked Emacs to fill the region
> between positions 391 and 1955. You can also probably try and do the
> same interactively. If it gives an error, then you should file a bug
> report with Emacs.

> Cheers,
> Uday

Hi Uday, I finally looked at this some more. I saved the email text into a text file, and called (fill-region a b) with a, b numbers that point to the empty lines with only ">" just before and after the main text paragraph. If I do this with a fresh emacs session called with -Q (not loading my settings) I don't get an error message. if I start vm, quit and try again outside of vm, I still don't get an error message. if I do this within vm, while replying to a message, I do get this error message. If I do this outside of vm, but after a reply in which I get the error message, I still do get this error message. I wonder if this has to do with some interference between vm-filling and emacs fill-region? some vm settings that stay in effect even after I quit vm? can you reproduce this error message? just to be clear, here is a typical text that leads to the error message:

 > Xxxxx Xxxx, Xxx, xxx Xxxxy,
 >
 >
 >
 > X fxw xxxxxxxx xxvx xxxx xxxy xxxx'x gxxxg xx xxx gxxxxxxx fxxxx
 > xxxp bxcxxxx xxxy'xx bx wxxkxxg xx xxxxx fxxxx yxxx xympxxxxm
 > xxxkx. X'x xxkx xx xxmxxx xxx xxxxx G1x xbxxx xxxx, xvxx xf xxx
 > xxxxx xxx xxxxxxxvx. Xx yxx xxxxk xx wxxxx bx xxfx xx xxxxmx xxx
 > xxxkx wxxx bx xxxxxx Mxxxxy & Xxxxxxy Xxpx. 13 & 14 xx Xxpx 20 &
 > 21? Xxxxx wxxx bx ~10 xxxkx xx xx wxxxx xxkxxy bx xvxx xwx xxyx.
 >
 >
 >
 > XB:
 >

and the error message and traceback are:

Debugger entered--Lisp error: (error "Invalid search bound (wrong side of point)")
  re-search-forward("\\([.?!][]\"'”)}]*\\($\\|[  ]$\\| \\|[  ][  ]\\)\\|[。．？！]+\\)[   \n]*$" #<marker (moves after insertion) at 820 in reply to xx> t)
  fill-delete-newlines(823 #<marker (moves after insertion) at 820 in reply to xx> left nil nil)
  fill-region-as-paragraph(820 811 nil nil)
  fill-region(393 812)
  vm-fill-paragraphs-containing-long-lines(window-width 309 1193)
  vm-fill-long-lines-in-reply()

[Uday Reddy (reddyuday)]

mere user writes:

> can
> you reproduce this error message? just to be clear, here is a typical text
> that leads to the error message:

Hi Eli, I can't reproduce it. You need to give me a precise recipe
for reproducing it. Also, the exact contents of the buffer which gave
rise to the error. Editing the buffer is fine, but you need to
regenerate the error and the backtrace for the edited buffer. Save
the buffer contents to a file and attach it to the email message so
that it doesn't get corrupted in transmission.

This is certainly an Emacs bug, but we need to isolate it so that it
can be reported to them.

Cheers,
Uday

[mere user (emacs-user)]

ok, will try