Do you know a more concise way doing the following
(format output "~&~A~C~A~C~A~C~D~%" g #\Tab (person-name p) #\Tab
(person-agreementno p) #\Tab (person-id p))
e.g. outputing a real Tab character w/o expanding it by spaces as ~T
does ? Something like \t in C strings ?
Vladimir Zolotykh wrote:
> Do you know a more concise way doing the following
>
> (format output "~&~A~C~A~C~A~C~D~%" g #\Tab (person-name p) #\Tab
> (person-agreementno p) #\Tab (person-id p))
>
> e.g. outputing a real Tab character w/o expanding it by spaces as ~T
> does ? Something like \t in C strings ?
I'd suggest taking a look at cl-interpol <http://weitz.de/cl-interpol/>
which can handle these escape characters (among other things),
allowing you to say :
(format output #?"~&~A\t~A\t~A\t~D~%" g (person-name p)
(person-agreementno p) (person-id p))
Cheers,
Sean.
C-q Tab :)
(No the smiley is not part of the suggestion) :)
Cheers
--
Marco
Vladimir Zolotykh wrote:
> Do you know a more concise way doing the following
>
> (format output "~&~A~C~A~C~A~C~D~%" g #\Tab (person-name p) #\Tab
> (person-agreementno p) #\Tab (person-id p))
>
> e.g. outputing a real Tab character w/o expanding it by spaces as ~T
> does ? Something like \t in C strings ?
Marco Antoniotti wrote:
> C-q Tab :)
I thought of that, the reason why I didn't use it is that to
me it lacks the benefit of visibility, I mean it's less obvious what's
meant than something expressed explicitly like \t
Vladimir Zolotykh <······@eurocom.od.ua> writes:
> Marco Antoniotti wrote:
>> C-q Tab :)
> I thought of that, the reason why I didn't use it is that to
> me it lacks the benefit of visibility, I mean it's less obvious what's
> meant than something expressed explicitly like \t
TAB is not a good idea. The author of make has regretted it forever.
(BTW, I'm suprized GNU make doesn't accept spaces, since they intend
to do better than the competition...)
If you want to generate some indentation, ~T is correct in generating
spaces, you shouldn't use anything else than spaces (or markup such as
<indent>...</indent>).
If you have to send a byte = 9 for a communication protocol or a
binary file, then you can just write:
(write-sequence (concatenate 'vector
(list ascii:+tab+)
(string-to-ascii-bytes "data")
(list ascii:+cr+ ascii:+lf+)) binfile)
--
"This machine is a piece of GAGH! I need dual Opteron 850
processors if I am to do battle with this code!"
Pascal Bourguignon wrote:
> Vladimir Zolotykh <······@eurocom.od.ua> writes:
>
> > Marco Antoniotti wrote:
> >> C-q Tab :)
> > I thought of that, the reason why I didn't use it is that to
> > me it lacks the benefit of visibility, I mean it's less obvious what's
> > meant than something expressed explicitly like \t
>
> TAB is not a good idea. The author of make has regretted it forever.
> (BTW, I'm suprized GNU make doesn't accept spaces, since they intend
> to do better than the competition...)
Unfortunately, this is problematic. If leading spaces were allowed to
indicate a rule command, it would be ambiguous against directives,
which can have leading spaces.
target : dependent
FOO=BAR
Is this a FOO=BAR assignment to be done by the shell as the rule body?
Or is it a rule with an empty body followed by a make directive to
assign to a variable?
The answer hinges on whether that leading whitespace is a tab.
For every make misfeature, you can probably find a Makefile which will
break if you alter that misfeature.
They should have a compatibility mode for running make, analogous to
bison --yacc, or :vim compatible, etc. :)
On 2005-11-23 09:35:32 +0000, Pascal Bourguignon <····@mouse-potato.com> said:
> TAB is not a good idea.
Good idea or not, that's the simplest possible way to export
your tabular data so that it will open in Excel (or other
spread-sheets which followed suit)
--
JFB ()