text/plain with 80 char wrap vs the flowed mime-type (whatever it is)

text/plain with 80 char wrap vs the flowed mime-type (whatever it is)

[Wes Hardaker]

So, I was co-writing a mail message with my wife yesterday and I noticed,
after sending her my copy of the proposed text, using the standard wrap
length (76 or whatever it is), that it looked fairly messed up on her
small phone screen.

What are people using for wrapping text these days?  Sticking with an
assumed 80 char screen?  Always using non-wrapped text?

Sadly, what I suspect I need to is set up different parameters in
different topics depending on who I'm writing to.

I suspect that the 80-char battle finally sunk with the massive change
in form factors that people read mail on now.  Should I bother to
continue assuming I know how I want to lay out my message, when the
reader really should have their preference for generic paragraphs (as
opposed to structured things like code or ascii diagrams).

Thoughts?

-- 
Wes Hardaker                                     
My Pictures:       http://capturedonearth.com/
My Thoughts:       http://blog.capturedonearth.com/

Re: text/plain with 80 char wrap vs the flowed mime-type (whatever it is)

[Jorge A. Alfaro-Murillo]

Wes Hardaker writes:

> So, I was co-writing a mail message with my wife yesterday and I 
> noticed, after sending her my copy of the proposed text, using 
> the standard wrap length (76 or whatever it is), that it looked 
> fairly messed up on her small phone screen. 
> 
> What are people using for wrapping text these days?  Sticking 
> with an assumed 80 char screen?  Always using non-wrapped text? 
> 
> Sadly, what I suspect I need to is set up different parameters 
> in different topics depending on who I'm writing to. 
> 
> I suspect that the 80-char battle finally sunk with the massive 
> change in form factors that people read mail on now.  Should I 
> bother to continue assuming I know how I want to lay out my 
> message, when the reader really should have their preference for 
> generic paragraphs (as opposed to structured things like code or 
> ascii diagrams). 
> 
> Thoughts?

I have:

#+BEGIN_SRC emacs-lisp
  (add-hook 'message-mode-hook 'use-hard-newlines)
#+END_SRC

That allows the message to be sent with format=flowed.

Best,
-- 
Jorge.

Re: text/plain with 80 char wrap vs the flowed mime-type (whatever it is)

[Wes Hardaker]

jorge.alfaro-murillo@yale.edu (Jorge A. Alfaro-Murillo) writes:

> That allows the message to be sent with format=flowed.

Thanks for your data point.  I think I'll switch to that.
-- 
Wes Hardaker                                     
My Pictures:       http://capturedonearth.com/
My Thoughts:       http://blog.capturedonearth.com/

Re: text/plain with 80 char wrap vs the flowed mime-type (whatever it is)

[Mark Simpson]

>>>>> On Wed, 27 Jan 2016 20:52:46 -0500, jorge.alfaro-murillo@yale.edu (Jorge A. Alfaro-Murillo) said:

  Jorge> (add-hook 'message-mode-hook 'use-hard-newlines)
  Jorge> That allows the message to be sent with format=flowed.

I have not had luck with that, specifically with cited text. Do you have
luck with it and cited text? I use supercite but I don't know if that
matters.

(Cited text ends up being interpreted as having soft-newlines instead of
having hard-newlines so ends up all jumbled together.)

Ciao
Mark

Re: text/plain with 80 char wrap vs the flowed mime-type (whatever it is)

[Teemu Likonen]

[-- Attachment #1: Type: text/plain, Size: 945 bytes --]

Mark Simpson [2016-02-03 21:54:07-05] wrote:

> (Jorge A. Alfaro-Murillo) said:
>> (add-hook 'message-mode-hook 'use-hard-newlines)
>> That allows the message to be sent with format=flowed.
>
> I have not had luck with that, specifically with cited text. Do you
> have luck with it and cited text?

I've noticed the same but it's probably easy to fix. One could add a
function to gnus-message-setup-hook variable. The function would look
for any "^>" lines (as in regexp) in the message body, go to the end of
line and add text property HARD to value T. I haven't tested this idea,
though.

> I use supercite but I don't know if that matters.

This problem is not about Supercite. (A different issue: I don't like
Supercite style. It's non-standard, thus more difficult to parse as a
human.)

-- 
/// Teemu Likonen   - .-..   <https://github.com/tlikonen> //
// PGP: 4E10 55DC 84E9 DFF6 13D7 8557 719D 69D3 2453 9450 ///

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]

Re: text/plain with 80 char wrap vs the flowed mime-type (whatever it is)

[Teemu Likonen]

[-- Attachment #1: Type: text/plain, Size: 706 bytes --]

Teemu Likonen [2016-02-04 07:18:24+02] wrote:

> I've noticed the same but it's probably easy to fix. One could 
> add a
> function to gnus-message-setup-hook variable. The function would 
> look
> for any "^>" lines (as in regexp) in the message body, go to the 
> end of
> line and add text property HARD to value T. I haven't tested 
> this idea,
> though.

I meant code like this:

    (add-hook 'gnus-message-setup-hook #'tl-format-flowed)

    (defun tl-format-flowed ()
      (use-hard-newlines nil 'always)
      (save-excursion
        (message-goto-body)
        (save-match-data
          (while (re-search-forward "^>.*$" nil t)
            (put-text-property (point) (1+ (point)) 'hard t)))))

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]

Re: text/plain with 80 char wrap vs the flowed mime-type (whatever it is)

[Mark Simpson]

[-- Attachment #1: Type: text/plain, Size: 217 bytes --]

>>>>> On Thu, 04 Feb 2016 16:30:53 +0200, Teemu Likonen <tlikonen@iki.fi> said:


  Teemu> I meant code like this:

  Teemu> [...useful code elided...]

Ooh, that looks useful. I'll give it a try!

Thanks!

Ciao
Mark

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 800 bytes --]

Re: text/plain with 80 char wrap vs the flowed mime-type (whatever it is)

[Jorge A. Alfaro-Murillo]

Hi, Mark.

Mark Simpson writes:

> Jorge A. Alfaro-Murillo) writes: 
> 
>> (add-hook 'message-mode-hook 'use-hard-newlines) 
> 
> I have not had luck with that, specifically with cited text. Do 
> you have luck with it and cited text?

Most of the time I actually do not want to have hard newlines for 
cited text. For example citing you above I still want it with 
format=flowed, generally mail viewers do a good job presenting it 
in the right way for any line length, at least emacs and my 
android phone do. If you really want a hard newline you can use 
C-m or C-o to insert it. The only issue I have is when copying 
code. Generally I yank the code, mark the region and use 
multiple-cursors mc/edit-ends-of-lines to insert the hard 
newlines. I should write some code for a special yank that 
substitutes newlines for hard-newlines.

> I use supercite but I don't know if that matters.

I do not use supercite, so I don't know either.

-- 
Jorge.

Re: text/plain with 80 char wrap vs the flowed mime-type (whatever it is)

[Nikolaus Rath]

On Jan 27 2016, jorge.alfaro-murillo@yale.edu (Jorge 
A. Alfaro-Murillo) wrote:
> I have: 
> 
> #+BEGIN_SRC emacs-lisp 
>   (add-hook 'message-mode-hook 'use-hard-newlines) 
> #+END_SRC 
> 
> That allows the message to be sent with format=flowed.
 
For me that breaks e.g. text pasted from a terminal or from a C 
mode window (the pasted stuff is refilled when the message is 
displayed by the recipient).

Is that a general problem or something specific to my setup?


Best,
-Nikolaus
 
(No Cc on replies please, I'm reading the list)
-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

             »Time flies like an arrow, fruit flies like a Banana.«

Re: text/plain with 80 char wrap vs the flowed mime-type (whatever it is)

[Magnus Henoch]

Nikolaus Rath <Nikolaus@rath.org> writes:

> On Jan 27 2016, jorge.alfaro-murillo@yale.edu (Jorge 
> A. Alfaro-Murillo) wrote: 
>> I have:  
>> 
>> #+BEGIN_SRC emacs-lisp   (add-hook 'message-mode-hook 
>> 'use-hard-newlines) #+END_SRC  
>> 
>> That allows the message to be sent with format=flowed. 
> 
> For me that breaks e.g. text pasted from a terminal or from a C 
> mode window (the pasted stuff is refilled when the message is 
> displayed by the recipient). 
> 
> Is that a general problem or something specific to my setup? 

I eventually came up with this:

  (defun my-mark-hard-newlines (beg end &rest _ignore)
    (interactive (list (point-min) (point-max)))
    (save-excursion
      (goto-char beg)
      (while (search-forward "\n" end t)
        (let ((pos (1- (point))))
          (if (get-text-property pos 'hard)
              ;; Use `copy-sequence', because display property 
              values must not be `eq'!
              (add-text-properties pos (1+ pos) (list 'display 
              (copy-sequence "⏎\n")))
            (remove-text-properties pos (1+ pos) '(display 
            nil)))))))

  (defun my-use-and-mark-hard-newlines ()
    (interactive)
    (use-hard-newlines)
    (add-hook 'after-change-functions 'my-mark-hard-newlines nil 
    t))

  (with-eval-after-load "message"
    (add-hook 'message-mode-hook 'my-use-and-mark-hard-newlines))

It doesn't fix things automatically, but it lets me see which 
newlines are hard, so I get the hint to fix code snippets manually 
before sending.

Regards,
Magnus

Re: text/plain with 80 char wrap vs the flowed mime-type (whatever it is)

[Nikolaus Rath]

On Feb 04 2016, Magnus Henoch <magnus.henoch@gmail.com> wrote:
> Nikolaus Rath <Nikolaus@rath.org> writes: 
> 
>> On Jan 27 2016, jorge.alfaro-murillo@yale.edu (Jorge 
>> A. Alfaro-Murillo) wrote:  
>>> I have:   
>>> 
>>> #+BEGIN_SRC emacs-lisp   (add-hook 'message-mode-hook 
>>> 'use-hard-newlines) #+END_SRC   
>>> 
>>> That allows the message to be sent with format=flowed.  
>> 
>> For me that breaks e.g. text pasted from a terminal or from a C 
>> mode window (the pasted stuff is refilled when the message is 
>> displayed by the recipient).  
>> 
>> Is that a general problem or something specific to my setup?  
> 
> I eventually came up with this: 
> 
>  (defun my-mark-hard-newlines (beg end &rest _ignore) 
>    (interactive (list (point-min) (point-max))) (save-excursion 
>      (goto-char beg) (while (search-forward "\n" end t) 
>        (let ((pos (1- (point)))) 
>          (if (get-text-property pos 'hard) 
>              ;; Use `copy-sequence', because display property 
> values must not be `eq'! 
>              (add-text-properties pos (1+ pos) (list 'display 
> (copy-sequence "⏎\n"))) 
>            (remove-text-properties pos (1+ pos) '(display 
> nil))))))) 
> 
>  (defun my-use-and-mark-hard-newlines () 
>    (interactive) (use-hard-newlines) (add-hook 
>    'after-change-functions 'my-mark-hard-newlines nil  t)) 
> 
>  (with-eval-after-load "message" 
>    (add-hook 'message-mode-hook 'my-use-and-mark-hard-newlines)) 
> 
> It doesn't fix things automatically, but it lets me see which 
> newlines are hard, so I get the hint to fix code snippets 
> manually before sending.

Hmm. Trying to call this gives me (on Emacs 24.4):

Debugger entered--Lisp error: (wrong-number-of-arguments (lambda 
(beg end &rest _ignore) (interactive (list (point-min) 
(point-max))) (save-excursion (goto-char beg) (while 
(search-forward " " end t) (let ((pos (1- (point)))) (if 
(get-text-property pos (quote hard)) values must not be (quote eq) 
(quote !) (add-text-properties pos (1+ pos) (list (quote display) 
(copy-sequence "⏎ "))) (remove-text-properties pos (1+ pos) (quote 
(display nil)))))))) 0) 
  my-mark-hard-newlines() 

Emacs 24.4. 

I always considered myself able to read backtraces - but the above 
leaves me clueless. Which function has the wrong number of 
arguments?  Why is the whole function definition included in the 
error?


Best,
-Nikolaus
 
(No Cc on replies please, I'm reading the list)
-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

             »Time flies like an arrow, fruit flies like a Banana.«

Re: text/plain with 80 char wrap vs the flowed mime-type (whatever it is)

[Mark Simpson]

Magnus -

This is an interesting idea. It does seem like the work of choosing
where the hard newlines go may need a human to decide - and this makes
it easier.

Thanks.

Ciao
Mark