My Sample file:
As I Come Into Your Presence
Key: F
1 As I come into Your presence
Past the gates of praise
Into Your sanctuary
Till we are standing face to face
And look upon Your countenance
I see the fullness of Your glory
And I can only bow down and say
Chorus:
Your awesome in this place
Mighty God
You are awesome in this place
Abba Father
You are worthy of all praise
To You our lives we raise
You are awesome in this place
Mighty God
<--- Empty line here
<--- Empty line here
I wrote this perl one-liner to get <i></i> tags around the entire chorus block:
perl -p0e "s#Chorus:(.*?)\n\n#<i>Chorus:$1</i>#gsm" file
The result:
As I Come Into Your Presence
Key: F
1 As I come into Your presence
Past the gates of praise
Into Your sanctuary
Till we are standing face to face
And look upon Your countenance
I see the fullness of Your glory
And I can only bow down and say
<i>Chorus:</i>%
I can't get the desired result where the </i> tag would be printed after the entire chorus after the Mighty God.
Where is the error? How can I achieve this?
Your solution would work if you just put it in single quotes instead of double quotes. You should pretty much always use single quotes for one-liners from the shell, no matter what language/interpreter you're running, to keep shell interpolation from messing things up.
In your code:
perl -p0e "s#Chorus:(.*?)\n\n#<i>Chorus:$1</i>#gsm" file
The $1 is being expanded by the shell before it ever gets to Perl, so Perl sees this:
perl -p0e "s#Chorus:(.*?)\n\n#<i>Chorus:</i>#gsm" file
and happily deletes your chorus. If you use single quotes instead:
perl -p0e 's#Chorus:(.*?)\n\n#<i>Chorus:$1</i>#gsm' file
it will work as intended.
Note, however, that the -0 means any NUL characters that creep into the input will still cause Perl to split it into multiple records at that point. A more correct solution would be to use -0777 instead, which tells Perl that no value should split the input; it is treated as a single record no matter what data it contains.
perl -p0777e 's#Chorus:(.*?)\n\n#<i>Chorus:$1</i>#gsm' file
escape the $
perl -p0777e "s#Chorus:(.*?)\n\n#<i>Chorus:\$1</i>#gsm" file.
also as #Kenney mention in the comment:
Use single quotes on the commandline to wrap perl expressions otherwise the shell expansion will kick in.
I'd like to use emacs in some kind of batch mode to just render a file with syntax highlighting and exit. Specifically, I want to dump the fontified buffer with ANSI escape codes so that it shows up reasonably syntax-highlighted on my terminal. Is there any way to do this?
The ansi-lpr.el library seems to be kind of along the lines of what I want, but the output isn't colorified. I can't figure out how to get over that final hurdle — there are a lot of modules to digest ANSI escape codes into Emacs text properties (e.g. ansi-color.el) but I haven't found anything that does the reverse. If anyone can point me to something that does, I think I can piece together the rest.
Alternatively, I've seen some hacky approaches like this answer (using script and capturing the output) but in my experiments that approach has seemed unlikely to be fruitful — you get tons of undesirable control sequences mixed in with the highlighted text.
The overarching motivation here is to use emacs in a $LESSOPEN pipe to get syntax highlighting when I page files. In case you're going to say it, I've tried and "just page files in Emacs" is not acceptable for me.
I'm glad to announce a new package, e2ansi, that (hopefully) does what you asked for.
The package provides a command-line tool e2ansi-cat that starts Emacs in batch mode, opens files, syntax highlight them (using font-lock), and creates ANSI-colored versions of the syntax highlighted files.
You can integrate this into less by setting the following variables to, for example:
export "LESSOPEN=|emacs --batch -Q -l ~/.emacs -l bin/e2ansi-cat %s"
export "LESS=-R"
export MORE=$LESS
The end result looks like the following:
You can vary the colors and attributes like bold, underline, and
italics by using a suitable Emacs theme.
The e2ansi package is located at https://github.com/Lindydancer/e2ansi
Personal note
I would like to thank you for posting this question, it directly inspired me to write e2ansi.
There are two operators that I am questioning. When I put # or $ at the top of a script, my script editor changes their colors to the same as the comment color and pre-processor color respectively. If they are pre-processor macros, could someone give an example use or situation when they'd be used for?
Probably a shebang, a Unix script file convention.
The perlstyle pod states
No space before the semicolon
and I can see no reason for that. I know that in English there should not be any space before characters made of 2 parts ( like '?',';','!' ), but I don't see why this should be a rule when writing Perl code.
I confess I personally use spaces before semicolons. My reason is that it makes the statement stands up a bit more clearer. I know it's not a very strong reason, but at least it's a reason.
print "Something\n with : some ; chars"; # good
print "Something\n with : some ; chars" ; # bad??
What's the reason for the second being bad?
From the first paragraph of the Description section:
Each programmer will, of course, have his or her own preferences in regards to formatting, but there are some general guidelines that will make your programs easier to read, understand, and maintain.
And from the third paragraph of the Description section:
Regarding aesthetics of code lay out, about the only thing Larry cares strongly about is that the closing curly bracket of a multi-line BLOCK should line up with the keyword that started the construct. Beyond that, he has other preferences that aren't so strong:
It's just a convention among Perl programmers for style. If you don't like it, you can choose to ignore it. I would compare it to Sun's Java Style guidelines or the suggestions for indenting in the K&R C book. Some environments have their own guidelines. These just happen to be the suggestions for Perl.
As Jon Skeet said in a deleted answer to this question:
If you're happy to be inconsistent with what some other people like, then just write in the most readable form for you. If you're likely to be sharing your code with others - and particularly if they'll be contributing code too - then it's worth trying to agree some consistent style.
This is only my opinion, but I also realize that people read code in different ways so "bad' is relative. If you are the only person who ever looks at your code, you can do whatever you like. However, having looked at a lot of Perl code, I've only seen a couple of people put spaces before statement separators.
When you are doing something that is very different from what the rest of the world is doing, the difference stands out to other people because their brain don't see it in the same way it. Conversely, doing things differently makes it harder for you to read other people's code for the same reason: you don't see the visual patterns you expect.
My standard is to avoid visual clutter, and that I should see islands of context. Anything that stands out draws attention, (as you say you want), but I don't need to draw attention to my statement separators because I usually only have one statement per line. Anything that I don't really need to see should fade into the visual background. I don't like semi-colons to stand out. To me, a semicolon is a minor issue, and I want to reduce the number of things my eyes see as distinct groups.
There are times where the punctuation is important, and I want those to stand out, and in that case the semicolon needs to get out of the way. I often do this with the conditional operator, for instance:
my $foo = $boolean ?
$some_long_value
:
$some_other_value
;
If you are a new coder, typing that damned statement separator might be a big pain in your life, but your pains will change over time. Later on, the style fad you choose to mitigate one pain becomes the pain. You'll get used to the syntax eventually. The better question might be, why don't they already stand out? If you're using a good programmer font that has heavier and bigger punctuation faces, you might have an easier time seeing them.
Even if you decide to do that in your code, I find it odd that people do it in their writing. I never really noticed it before Stackoverflow, but a lot of programmers here put spaces before most punctuation.
It's not a rule, it's one of Larry Wall's style preferences. Style preferences are about what help you and the others who will maintain your code visually absorb information quickly and accurately.
I agree with Larry in this case, and find the space before the semicolon ugly and disruptive to my reading process, but others such as yourself may find the exact opposite. I would, of course, prefer that you use the sort of style I like, but there aren't any laws on the books about it.
Yet.
Like others have said, this is a matter of style, not a hard and fast rule. For instance, I don't like four spaces for indentation. I am a real tab for block level indentation/spaces for lining things up sort of programmer, so I ignore that section of perlstyle.
I also require a reason for style. If you cannot clearly state why you prefer a given style then the rule is pointless. In this case the reason is fairly easy to see. Whitespace that is not required is used to call attention to something or make something easier to read. So, does a semicolon deserve extra attention? Every expression (barring control structures) will end with a semicolon, and most expressions fit on one line. So calling attention to the expected case seems to be a waste of a programmers time and attention. This is why most programmers indent a line that is a continuation of an expression to call attention to the fact that it didn't end on one line:
open my $fh, "<", $file
or die "could not open '$file': $!";
Now, the second reason we use whitespace is make something easier to read. Is
foo("bar") ;
easier to read than
foo("bar");
I would make the claim that is harder to read because it is calling my attention to the semicolon, and I, for the most part, don't care about semicolons if the file is formatted correctly. Sure Perl cares, and if I am missing one it will tell me about it.
Feel free to put a space. The important thing is that you be consistent; consistency allows you to more readily spot errors.
There's one interesting coding style that places , and ; at the beginning of the following line (after indentation). While that's not to my taste, it works so long as it is consistent.
Update: an example of that coding style (which I do not advocate):
; sub capture (&;*)
{ my $code = shift
; my $fh = shift || select
; local $output
; no strict 'refs'
; if ( my $to = tied *$fh )
{ my $tc = ref $to
; bless $to, __PACKAGE__
; &{$code}()
; bless $to, $tc
}
else
{ tie *$fh , __PACKAGE__
; &{$code}()
; untie *$fh
}
; \$output
}
A defense can be found here: http://perl.4pro.net/pcs.html.
(2011 Update: that page seems to have gone AWOL; a rescued copy can be seen here: http://ysth.info/pcs.html)
Well, it's style, not a rule. Style rules are by definition fairly arbitrary. As for why you shouldn't put spaces before semicolons, it's simply because that's The Way It's Done. Not just with Perl, but with C and all the other curlies-and-semicolons languages going back to C and newer C-influenced ones like C++, C#, Objective C, Javascript, Java, PHP, etc.
Because people don't expect it . It looks strange when you do it .
The reason I would cite is to be consistent within a project. I have been in a project where the majority of programmers would not insert the space but one programmer does. If he works on a defect he may routinely add the space in the lines of code he is examining as that is what he likes and there is nothing in the style guide to say otherwise.
The visual diff tools in use can't determine this so show a mass of line changes when only one may have changed and becomes difficult to review. (OK this could be an argument for a better diff tools but embedded work tends to restrict tool choice more).
Maybe a suitable guide for this would be to choose whichever format you want for you semicolon but don't change others unless you modify the statement itself.
I really don't like it. But it's 100% a personal decision and group convention you must make.
Code style is just a set of rules to make reading and maintaining code easier.
There is no real bad style, but some are more accepted than others. And they are of course the source for some "religious battles" (to call curly braces style ;-) ).
To make a real life comparison, we have trafic lights with red, yellow/orange and green. Despite the psychological effects of the colors, it is not wrong to use Purple, Brown and Pink, but just because we are all used to the colors there are less trafic accidents.
I would like to edit text in boustrophedon in emacs. For those of you who don't know boustrophedon text direction goes "like an ox turns" in a field or like a printer inkjet. For the same reasons this is efficient on a farm or in a printer this text is very efficient to read once you get used to it (which doesn't take too long).
more on boustrophedon typesetting/layout:
http://www.ntg.nl/pipermail/aleph/2004-March/000094.html
To my knowledge there are no implementations of this typesetting style and I am stumped on how to implement it.
Any ideas as to how this could be done?
Thanks,
Andreas
I assume that advising self-insert-command, intercepting the events, and modifying the buffer accordingly is what you want to do. You will then need to rebind the directional commands (forward-char and friends are reversed on opposite lines), and so on.
A lot of work, but definitely possible.
Before you write anything too complicated, ask on emacs-devel. As the comments suggest, it might be useful to have generic support for something like this... although arbitrary snippets of text with different directions won't word-wrap (when inserting) the same way your text will.
Edit: Apparently advising self-insert-command doesn't quite work for this, so you will need to setup a keymap (and bind ?a to (my-new-insert-command ?a) and so on...).
You could write it in sed I hacked the rev script from the sed1liners text to skip a line and then rev every other line:
alias boustrophedon='sed -n "1{p;b a};{/\n/!G;s/\(.\)\(.*\n\)/&\2\1/;//D;s/.//;p};n;p;:a"'
$> echo -en "This\nis\nBoustrou...\ntext\non\ndisplay\nhere.\n" | boustrophedon
This
si
Boustrou...
txet
on
yalpsid
here.
Or, if you want to process a whole file:
$> boustrophedon <filename>