emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
* Query for S. Vauban
@ 2010-09-19 22:47 Thomas S. Dye
  2010-09-20  7:51 ` Sébastien Vauban
  0 siblings, 1 reply; 3+ messages in thread
From: Thomas S. Dye @ 2010-09-19 22:47 UTC (permalink / raw)
  To: emacs-org list

Aloha Sebastian,

While using the listings setup you sent to the list a while back, I  
found this line and wondered why you chose not to break long lines?

         breaklines=false, %!! don't break long lines of code

The !! in the comment led me to believe you might have some strong  
reasons.

I'm asking because I'm finding it difficult to configure the listings  
package so it works perfectly.

All the best,
Tom

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Query for S. Vauban
  2010-09-19 22:47 Query for S. Vauban Thomas S. Dye
@ 2010-09-20  7:51 ` Sébastien Vauban
  2010-09-20  8:18   ` Thomas S. Dye
  0 siblings, 1 reply; 3+ messages in thread
From: Sébastien Vauban @ 2010-09-20  7:51 UTC (permalink / raw)
  To: emacs-orgmode-mXXj517/zsQ

Aloha Thomas,

"Thomas S. Dye" wrote:
> While using the listings setup you sent to the list a while back, I found
> this line and wondered why you chose not to break long lines?
>
>         breaklines=false, %!! don't break long lines of code
>
> The !! in the comment led me to believe you might have some strong reasons.

You're right guessing that the !! do have a meaning. Yes, they mean: this is
not a standard comment, that's something you really must be aware of...

I guess I did that for 2 reasons:

- be sure to easy locate what could be a wrong setting, in case I would not be
  happy with the listings results

- emphasize on the importance of that setting.

Now, why choosing this?  First, let me tell you I'm sometimes a bit of a crazy
perfectionist. I want the things to be perfectly output, and my reports to be
of great quality on the presentation side as well -- I cannot easily judge on
my own for the contents ;-)

One of the constraints I use in my daily life is: no more than 80 rows in
files, be it text (Org) or code (.emacs, bash scripts, etc.). In fact, even
not more than 78, when possible. I have Emacs column markers in columns 78, 79
and 80, showing me when I reach the limits.

I want my code in my files to be formatted in such a way as well, and have
chosen the right font size (in LaTeX) so that my code is displayed in the
LaTeX PDF with the biggest font possible, so that an 80-wide line is displayed
on one line, within the normal allowed space.

What about longer lines, then?

Either I let LaTeX listings decide for me. Either I don't. I've explicitly
chosen the second one, with the above setting in Listings. Why?  Because I
consider that lines longer than 80 characters are bad, and that *I* have to
correct them somehow. I don't want to rest on Listings to rearrange my code.
Plus, Listings does not do it good, if I remember good. The wrapped text never
won't be placed in the way you would do it if you had to break the line
yourself, explicitly.

So, in a nutshell, by forbidding long lines to be wrapped by Listings, I have
a clear indication that my code is too wide at some spots, and that I do have
to cut it in a clean way, directly in the source.


> I'm asking because I'm finding it difficult to configure the listings
> package so it works perfectly.

You're welcome.

Do I answer your question in an understandable way?  Just asking if I'm clear
about *my* objectives; I can perfectly understand that others don't share this
quite strict point of view.

Best regards,
  Seb

-- 
Sébastien Vauban


_______________________________________________
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode-mXXj517/zsQ@public.gmane.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Re: Query for S. Vauban
  2010-09-20  7:51 ` Sébastien Vauban
@ 2010-09-20  8:18   ` Thomas S. Dye
  0 siblings, 0 replies; 3+ messages in thread
From: Thomas S. Dye @ 2010-09-20  8:18 UTC (permalink / raw)
  To: Sébastien Vauban; +Cc: emacs-orgmode

Aloha Sebastien,

Yes, that makes perfect sense for situations where the line length is  
specified in advance.

Changing the font size to get a particular line length is an  
interesting idea.  My sense is that typographers would look first to  
change the size of the text block.  I can see benefits to both  
approaches.

Thanks for your help.

All the best,
Tom

On Sep 19, 2010, at 9:51 PM, Sébastien Vauban wrote:

> Aloha Thomas,
>
> "Thomas S. Dye" wrote:
>> While using the listings setup you sent to the list a while back, I  
>> found
>> this line and wondered why you chose not to break long lines?
>>
>>        breaklines=false, %!! don't break long lines of code
>>
>> The !! in the comment led me to believe you might have some strong  
>> reasons.
>
> You're right guessing that the !! do have a meaning. Yes, they mean:  
> this is
> not a standard comment, that's something you really must be aware  
> of...
>
> I guess I did that for 2 reasons:
>
> - be sure to easy locate what could be a wrong setting, in case I  
> would not be
>  happy with the listings results
>
> - emphasize on the importance of that setting.
>
> Now, why choosing this?  First, let me tell you I'm sometimes a bit  
> of a crazy
> perfectionist. I want the things to be perfectly output, and my  
> reports to be
> of great quality on the presentation side as well -- I cannot easily  
> judge on
> my own for the contents ;-)
>
> One of the constraints I use in my daily life is: no more than 80  
> rows in
> files, be it text (Org) or code (.emacs, bash scripts, etc.). In  
> fact, even
> not more than 78, when possible. I have Emacs column markers in  
> columns 78, 79
> and 80, showing me when I reach the limits.
>
> I want my code in my files to be formatted in such a way as well,  
> and have
> chosen the right font size (in LaTeX) so that my code is displayed  
> in the
> LaTeX PDF with the biggest font possible, so that an 80-wide line is  
> displayed
> on one line, within the normal allowed space.
>
> What about longer lines, then?
>
> Either I let LaTeX listings decide for me. Either I don't. I've  
> explicitly
> chosen the second one, with the above setting in Listings. Why?   
> Because I
> consider that lines longer than 80 characters are bad, and that *I*  
> have to
> correct them somehow. I don't want to rest on Listings to rearrange  
> my code.
> Plus, Listings does not do it good, if I remember good. The wrapped  
> text never
> won't be placed in the way you would do it if you had to break the  
> line
> yourself, explicitly.
>
> So, in a nutshell, by forbidding long lines to be wrapped by  
> Listings, I have
> a clear indication that my code is too wide at some spots, and that  
> I do have
> to cut it in a clean way, directly in the source.
>
>
>> I'm asking because I'm finding it difficult to configure the listings
>> package so it works perfectly.
>
> You're welcome.
>
> Do I answer your question in an understandable way?  Just asking if  
> I'm clear
> about *my* objectives; I can perfectly understand that others don't  
> share this
> quite strict point of view.
>
> Best regards,
>  Seb
>
> -- 
> Sébastien Vauban
>
>
> _______________________________________________
> Emacs-orgmode mailing list
> Please use `Reply All' to send replies to the list.
> Emacs-orgmode@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-orgmode

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2010-09-20  8:18 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-09-19 22:47 Query for S. Vauban Thomas S. Dye
2010-09-20  7:51 ` Sébastien Vauban
2010-09-20  8:18   ` Thomas S. Dye

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).