in reply to Pretty Print

Last I looked at that part of the code, tabs were already being expanded. They are expanded to 4 spaces each. Since it is my experience that nobody can agree on how large a tab should be, I think that is a reasonable compromise choice.

Most of the replies seem to have missed that you are most concerned about the tabs that fall between code near the start of the line and comments that hang near the end of the line. So, expanding tabs to tab stops that appear every 4 spaces might make you a bit happier. But, unless you just happen to use such tab stops, then you likely still won't be totally happy.

So, if somebody would like something simple to implement, a user setting for tabstop choice when posting might be nice. Though, the simple way to implement that means that downloading of the code will get you spaces not tabs.

Another solution, and one that I've used for many years, is to not store tabs in one's source code. If I type a tab, my editor knows to turn it into an appropriate number of spaces for me. Then I never have to worry about how any number of web sites or other tools that my code may pass through think that tabs should be expanded.

- tye        

Replies are listed 'Best First'.
Re^2: Pretty Print (already)
by jdporter (Paladin) on May 31, 2016 at 01:29 UTC
    If I type a tab, my editor knows to turn it into an appropriate number of spaces for me.

    What I don't like about that approach, and why I don't enable that option in my editor, is because it isn't smart enough to do the reverse: to delete an appropriate number of spaces when I hit the backspace key.

[reply]

      Get a better editor? That "just works" for me in vim across a single insert operation. And even though vim's scripting features can be a bit awkward, making a single backspace over whitespace that extends to the prior tab stop behave as you describe isn't beyond what is possible. But then, maybe you also want backspace to not do that in some of those cases, but this is pretty far afield from the thread subject. (:

      - tye        

[reply]
Re^2: Pretty Print (example updated)
by LanX (Saint) on May 29, 2016 at 13:27 UTC
    > Last I looked at that part of the code, tabs were already being expanded. 

    Since when? I remember having tab problems before configuring my editor to never use \t for tab.

    IIRC the main problem was that the textarea did show differently to preview. (Something like using the old 8 character standard)

    > So, if somebody would like something simple to implement, a user setting for tabstop choice when posting might be nice

    Are you talking about arbitrary tab stops like column 40 for comments?

    I'd personally rather prefer a perltidy button.

    Personal preferences can vary too much to be reasonably reflected here.

    Cheers Rolf
    (addicted to the Perl Programming Language and ☆☆☆☆ :)
    Je suis Charlie!

    update

    I tried this

    print qq(<c>\n\t1tab\n\t\t2tab\nprint "\t\t2tabinquotes"\n</c>)

    showing in in the console (gterm) and in the html-textarea (Firefox) like this ( I manually replaced with space)

    123456789012345678901234567890 

            1tab
                2tab
print "         2tabinquotes"

    [download]

    or using <tt><pre> instead of <c> ¹

    123456789012345678901234567890
	1tab
		2tab
print "		2tabinquotes"

    but being rendered after preview as

    123456789012345678901234567890 

        1tab
        2tab
print "        2tabinquotes"

    [download]

    so textarea and console are displaying with tab-stops at 8 char distance, while we transform each \t to 4 spaces.

    This should clarify the source of confusion.

    footnote

    ¹ not sure what your browser will display in this case, I see tabstops taking effect in pre-tag

[reply]
[d/l]
[select]

In Section Perl Monks Discussion