|
Re: Pretty Print
by LanX (Saint) on May 28, 2016 at 02:00 UTC
|
I just realized that I totally misunderstood your question (it's late here)
you want what's called untabify in emacs?
Theoretically one could do a regex to s/^\t/ /g (roughly), but what if multi line code incidentally starts with a tab?
The edge cases are so hairy that I doubt that our dev will try, especially because it needs to be configurable per user.
Of course you could extend my wiki solution with such js code...
See Good Intentions: Wikisyntax for the Monastery
| [reply]
[d/l] |
Re: Pretty Print (already)
by tye (Sage) on May 29, 2016 at 06:30 UTC
|
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.
| [reply] |
|
|
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. (:
| [reply] |
|
|
> 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.
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"
or using <tt><pre> instead of <c> ¹
123456789012345678901234567890
1tab
2tab
print " 2tabinquotes"
but being rendered after preview as
123456789012345678901234567890
1tab
2tab
print " 2tabinquotes"
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] |
Re: Pretty Print (perltidy integration)
by LanX (Saint) on May 28, 2016 at 01:52 UTC
|
Actually there are three questions involved
A) how to do this in a backwards compatible way to still be able to see the unformatted code. (Much posted code is broken, we need a fallback)
B) if syntax highlighting should be added too
C) how to implement this into the process chain
Brainstorm:
A) The only chance I see is an additional displaytype, like this users could switch between raw and formated source
B) perltidy can also produce highlighted code, but startup is slow and would cause a lag
C) patching perltidy to run in a server mode might be a solution.
Alternatives?
| [reply] |
|
|
> B) perltidy can also produce highlighted code, but startup is slow and would cause a lag
> C) patching perltidy to run in a server mode might be a solution.
FWIW:
Actually no patch needed, this code from Perl::Tidy is very fast after initialization (which can take 1-2 secs)
use Perl::Tidy;
# ...
# run in a loop reading source and outputting dest
my $error = Perl::Tidy::perltidy(
argv => $argv,
source => \$source_string,
destination => \$dest_string,
stderr => \$stderr_string,
errorfile => \$errorfile_string,
+
);
Indenting some lines on laptop took under 0.05 sec and own formatters for "special" html are easily implemented.
(trying to implement a so called "asynchronous process" interface for emacs now)
| [reply]
[d/l] |
Re: Pretty Print
by GrandFather (Saint) on May 31, 2016 at 03:20 UTC
|
Simple answer: don't use tab characters in code. Any decent modern editor understands how to indent code using spaces and most will unindent with backspace too.
Tab characters in code lead to too much strangeness as code moves about between different editors and display technologies. It's not like storage is so expensive these days that the small file size difference is important any more. Just do it, eschew tab characters.
Premature optimization is the root of all job security
| [reply] |
|
|
| [reply] |
Re: Pretty Print for code tags (js)
by Anonymous Monk on May 28, 2016 at 02:30 UTC
|
| [reply] |
|
|
| [reply] |
|
|
actually it's not really difficult to add something like a s/\t/ /g
to Good Intentions: Wikisyntax for the Monastery
The function exclude must be called with a 4th argument untabify in the line with
text = exclude(text,/<(c|code)>[^]*?<\/\1>/g,"code",untabify);
If defined apply the callback to substring = transform(substring)
before exclusions.push( [placeholder,substring] ); is done.
like this users can do personal adjustments to the way the transformation is done
(not everyone wants 4 spaces for tab) in untabify()
Just documenting it for future implementation if a real demand rises.
| [reply]
[d/l]
[select] |
