Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.

Dismiss

freebsd-hackers-digest V5 #733

1 view

Skip to first unread message

owner-freebsd-...@freebsd.org

unread,

Mar 1, 2003, 6:13:49 PM3/1/03

freebsd-hackers-digest Saturday, March 1 2003 Volume 05 : Number 733

In this issue:
Re: C coding editor
Re: Disk scheduling in FreeBSD
RE: Disk scheduling in FreeBSD
Re: C coding editor
Re: C coding editor
Re: 64 bit endian routines
Re: 64 bit endian routines
RE: kern/40611 linux compatibility fix
Re: C coding editor
kernel programming
Re: kern/40611 linux compatibility fix
Re: /bin/loader panic
Бесплодие женское и мужское
Call for bi-monthly status reports
The best Cigar ever made, you must read this
Re: kernel programming
Re: C coding editor

----------------------------------------------------------------------

Date: Fri, 28 Feb 2003 07:52:19 -0800
From: Terry Lambert <tlam...@mindspring.com>
Subject: Re: C coding editor

Wes Peters wrote:
> On Wednesday 26 February 2003 09:57 am, Jason Andresen wrote:
> > Even if I never have to print out on a printer like that, who's to
> > say nobody else is? You will no doubt turn people away if they open
> > up your code in their favorite programming editor and all of the
> > lines wrap a few characters. Worse if they are already at the
> > maximum size their screen/eyeballs can support.
>
> I rejected programming to the least common denominator in equipment.
> You should try it too, it's incredibly liberating. The legions of
> programmers under the age of 25 holding up 80x25 "consoles" as some
> sort of mantra is just weird, and the idea of cramming a video card
> capable of a million 3d triangles per second into a machine so some
> dumbass can use it as a vt220 just makes me roll on the floor. Of
> course you probably didn't live through paying $75,000 for workstations
> with a tenth that 3D performance.

I blame this on people unsuited to writing software getting CS degrees
and/or programming jobs, because they think that that's where the money
is at. Luckily, they later find out that salary is a matter of merit,
much more than it's a matter of having paper credentials, and if you
haven't blown at least one test because you wer in the CS lab until 5AM
playing with the new Retrogrpahics cards and high persistance phosphor
tubes, and slept through your alarm, well... 8-) 8-). Very soon, these
people end up finding gainful employment asking people if they would like
fries with that.

> I use what is mostly likely a different font from what you use for
> coding every day. I do all of my coding on FreeBSD, most of it in
> Emacs, and use lucidatypewriter (less and less) or luxi mono for most
> of it. My own code often goes as wide as 120 characters because
> anything more than that won't fit comfortably on a 1024 pixel wide
> screen, which is a much better default than 80 columns these days.

I personally attribute the majority of very long lines to deep
structure element nesting, which everyone seems happy to do these
days, and long_variable_names_which_try_to_be_meaningful_but_fail.
Hell, you can't add two of those together, even with a "+=", and
not wrap the line at least once...

> No, but your editor really ought to be able to interpret tab stops
> correctly at like 0.5 in increments. Code editors on the Mac have
> been doing this for years.

If editors like this were more common, it would be a lot easier to
justify use of proportional fonts in coding editors. I don't think
anyone really cares how many characters there are after a tabstop,
so long as the visual layout is uniform to the left of the code. If
you use indentation, this still works, no mater what your font, as
long as there are fixed indentations per tab (IMO).

- -- Terry

------------------------------

Date: Fri, 28 Feb 2003 11:08:40 -0500
From: Hiten Pandya <hi...@unixdaemons.com>
Subject: Re: Disk scheduling in FreeBSD

p...@phk.freebsd.dk (Thu, Feb 27, 2003 at 06:12:29PM +0100) wrote:
> In message <1046361700.3...@webmail.unixdaemons.com>, "" writes:
> >Hello gang.
> >
> >Does anyone know what kind of `Disk Scheduling' algorithm,
> >if any, is used in FreeBSD?
>
> One way elevator sort.

Thanks for the interesting reply, phk@ and all.

Cheers.

- --
Hiten Pandya (hi...@unixdaemons.com, hi...@uk.FreeBSD.org)
http://www.unixdaemons.com/~hiten/

------------------------------

Date: Fri, 28 Feb 2003 17:24:43 +0100 (CET)
From: "=?iso-8859-1?q?Pedro=20F.=20Giffuni?=" <giff...@yahoo.com>
Subject: RE: Disk scheduling in FreeBSD

--- Paul Robinson <pa...@iconoplex.co.uk> ha scritto:

>
> The license is actually BSD. Or at least, the one I
> saw last night had a
> remarable resemblance to it. :-)

I thought the same when I glimpsed over it until I saw
the README file :-). Read again, it has 4 statements
ala BSD, including the advertisement clause, but the
code is NOT redistributable and cannot be used for
commercial purposes.

The author of the
> implementation has also
> stated in an e-mail to me that he is happy for a
> BSD-based production-ready
> derivative to be produced based on his code.
>

The author can do this no doubt. Many universities are
offering a part of the money they make from research
to students though, so that would explain the license.

cheers,

Pedro.

______________________________________________________________________
Yahoo! Cellulari: loghi, suonerie, picture message per il tuo telefonino
http://it.yahoo.com/mail_it/foot/?http://it.mobile.yahoo.com/index2002.html

------------------------------

Date: Fri, 28 Feb 2003 12:07:31 -0500
From: David Cuthbert <da...@kanga.org>
Subject: Re: C coding editor

Terry Lambert wrote:
> Average English word length is 5 characters; with a space, that's
> 6 characters. 65 characters is therefore 11 words. The Bell Labs
> study which set telephone number length limits at 7 digits found
> that the average person could keep between 5 and 9 items in memory
> at a time. I guess "11 words" isn't out of the question, but it's
> a bit long. 8-) 8-).

Different concepts. The Bell Labs study dealt with (long term) memory
and the ability to remember a string of unrelated items. This is more
analagous to sentence lengths in English or function size in C.

The n characters/line issue deals more with the ability to visually
track the line. If, for example, when you reach the end of the line you
often find yourself accidentally reading the same line again, then the
line is too wide.

Or something to that effect. I'm not an HCI expert, so...

>>The 80 column limit can also encourage developers to keep their
>>functions smaller and factor out common code. (I say can, because I've
>>seen the six-levels-of-indentation-loops sadly all too often...)
>
> Seems to have worked well for tcp_input(). 8-) 8-).

Heh... for every example where it works/is needed, I can find 10
examples in our code at work where it definitely *isn't* needed. :-)

------------------------------

Date: Fri, 28 Feb 2003 09:05:50 -0800
From: Wes Peters <w...@softweyr.com>
Subject: Re: C coding editor

On Friday 28 February 2003 07:52, Terry Lambert wrote:
>
> I blame this on people unsuited to writing software getting CS
> degrees and/or programming jobs, because they think that that's where
> the money is at. Luckily, they later find out that salary is a
> matter of merit, much more than it's a matter of having paper
> credentials, and if you haven't blown at least one test because you
> wer in the CS lab until 5AM playing with the new Retrogrpahics cards
> and high persistance phosphor tubes, and slept through your alarm,
> well... 8-) 8-).

Oh, the good old days.

> Very soon, these people end up finding gainful
> employment asking people if they would like fries with that.

Just like RMS wants them too. But wait, he wants you and me to be doing
that too...

> I personally attribute the majority of very long lines to deep
> structure element nesting, which everyone seems happy to do these
> days, and long_variable_names_which_try_to_be_meaningful_but_fail.
> Hell, you can't add two of those together, even with a "+=", and
> not wrap the line at least once...

Ditto. I have a single function, the critical path of the Xylan switch
control software, that fits nicely in 80 columns. It has a McCabe's
complexity number of 360, the highest I've ever heard of. According to
McCabe, anything beyond 25 is not understandable by human beings and
it's a logarithmic scale.

> > No, but your editor really ought to be able to interpret tab stops
> > correctly at like 0.5 in increments. Code editors on the Mac have
> > been doing this for years.
>
> If editors like this were more common, it would be a lot easier to
> justify use of proportional fonts in coding editors. I don't think
> anyone really cares how many characters there are after a tabstop,
> so long as the visual layout is uniform to the left of the code. If
> you use indentation, this still works, no mater what your font, as
> long as there are fixed indentations per tab (IMO).

Precisely. The GNU enscript pretty-print function does a relatively
nice job of this, but it ends up mangling the gnu-style continuation
line indents. Solution? Don't do continuation lines. At all. Just
print your code 1-up in 7 point Palatino and it fits nicely on
Letter-size paper. For those of us weird enough to print code, that
is.

- --
"Where am I, and what am I doing in this handbasket?"

Wes Peters Softweyr LLC
w...@softweyr.com http://softweyr.com/

------------------------------

Date: Fri, 28 Feb 2003 09:40:35 -0800 (PST)
From: Nate Lawson <n...@FreeBSD.org>
Subject: Re: 64 bit endian routines

Date: Thu, 27 Feb 2003 21:17:13 -0800
From: Marcel Moolenaar <mar...@xcllnt.net>
To: Nate Lawson <n...@FreeBSD.org>
Cc: mi...@FreeBSD.org, cur...@FreeBSD.org, hac...@FreeBSD.org
Subject: Re: 64 bit endian routines
References: <2003022804...@athlon.pn.xcllnt.net> <200302280445....@freefall.freebsd.org>

On Thu, Feb 27, 2003 at 08:45:44PM -0800, Nate Lawson wrote:
> Both scsi and geom implement unaligned access functions
that perform byte > ordering. I never intended to supplant
them with __bswap*(). What I want > is for machine/endian.h
to have functions that provide 16-64 bit endian > conversions
in both aligned and unaligned access forms. After these
functions > are there, I'd like us to unify use of them and
remove driver-private > versions. > > Is this more clear
now?

Crystal :-)

--
Marcel Moolenaar USPA: A-39004 mar...@xcllnt.net

Heh, I hope I didn't sound too forceful. It was just a straightforward
question, not a diatribe. :)

- -Nate

------------------------------

Date: Fri, 28 Feb 2003 11:24:34 -0800
From: Marcel Moolenaar <mar...@xcllnt.net>
Subject: Re: 64 bit endian routines

On Fri, Feb 28, 2003 at 09:40:35AM -0800, Nate Lawson wrote:
>
> On Thu, Feb 27, 2003 at 08:45:44PM -0800, Nate Lawson wrote:
> > Both scsi and geom implement unaligned access functions
> that perform byte > ordering. I never intended to supplant
> them with __bswap*(). What I want > is for machine/endian.h
> to have functions that provide 16-64 bit endian > conversions
> in both aligned and unaligned access forms. After these
> functions > are there, I'd like us to unify use of them and
> remove driver-private > versions. > > Is this more clear
> now?
>
> Crystal :-)
>
> Heh, I hope I didn't sound too forceful. It was just a straightforward
> question, not a diatribe. :)

No worries. It's too late to realize that there might be a disconnect
if you are using blunt objects to get your point across.

- --
Marcel Moolenaar USPA: A-39004 mar...@xcllnt.net

------------------------------

Date: Fri, 28 Feb 2003 11:47:42 -0800
From: "Luoqi Chen" <lc...@briontech.com>
Subject: RE: kern/40611 linux compatibility fix

> Dear Hackers,
>
> Is there any chance that the patch given in kern/40611 could be
> committed to the 4-STABLE tree? It has the desirable effect of making
> eg. the linux-sun-jdk14 port usable as a non-root user. This would
> appear to my untutored eye to be a sub-set of the differences already
> existing between the HEAD and RELENG_4 versions of
> src/sys/posix4/p1003_1b.c
>
> Cheers,
>
> Matthew
>
> --
> Dr Matthew J Seaman MA, D.Phil. 26 The Paddocks
> Savill Way
> PGP: http://www.infracaninophile.co.uk/pgpkey Marlow
> Tel: +44 1628 476614 Bucks., SL7 1TH UK
>
I've a similar but more complete patch. It handles both get and set cases,
and also takes into account jailed environment. It should have identical
semantics to -current (except for the see_other_uids flag), at least at
the time when I created the patch. You may inspect the patch at
http://people.freebsd.org/~luoqi/p1003_1b.diff

I didn't know there're so many people running linux apps under emulation.
I've a couple of other linux related patches for -stable, among them
backport of linux ptrace from -current, anyone interested?

- -lq

------------------------------

Date: Fri, 28 Feb 2003 12:38:15 -0800
From: Terry Lambert <tlam...@mindspring.com>
Subject: Re: C coding editor

David Cuthbert wrote:
> The n characters/line issue deals more with the ability to visually
> track the line. If, for example, when you reach the end of the line you
> often find yourself accidentally reading the same line again, then the
> line is too wide.
>
> Or something to that effect. I'm not an HCI expert, so...

I considered mentioning exactly the same thing (starting over on
the same line, instead of the next one) as an argument, and then
quoting Narvii and other HCI experts to back the idea up, but the
references I would have had to use were too obscure to be online.
8-) 8-).

> >>The 80 column limit can also encourage developers to keep their
> >>functions smaller and factor out common code. (I say can, because I've
> >>seen the six-levels-of-indentation-loops sadly all too often...)
> >
> > Seems to have worked well for tcp_input(). 8-) 8-).
>
> Heh... for every example where it works/is needed, I can find 10
> examples in our code at work where it definitely *isn't* needed. :-)

It's very easy to do that with your own code... ;^).

- -- Terry

------------------------------

Date: Fri, 28 Feb 2003 18:19:56 -0600
From: Jay Sern Liew <j...@americanhorizonsbank.com>
Subject: kernel programming

Greetings,
Just wanted to ask a qwik question. I'm keen on programming FreeBSD, from
simple tools, to kernel modules and the kernel itself. I don't find much
help/resource on this for FreeBSD in general, but tonnes for Linux.
My question is, will I be wasting my time reading docs like those written
for Linux because Linux is a UNIX clone and FreeBSD is a UNIX derivative?

If someone can point me to any resource on programming FreeBSD, I'd greatly
appreciate that. Thanks in advance! :)

______________________________________________________________________
Jay Sern Liew

------------------------------

Date: Fri, 28 Feb 2003 16:47:42 -0800
From: Brooks Davis <bro...@one-eyed-alien.net>
Subject: Re: kern/40611 linux compatibility fix

- --9amGYk9869ThD9tj
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Feb 28, 2003 at 11:47:42AM -0800, Luoqi Chen wrote:
> > Dear Hackers,
> >=20
> > Is there any chance that the patch given in kern/40611 could be
> > committed to the 4-STABLE tree? It has the desirable effect of making
> > eg. the linux-sun-jdk14 port usable as a non-root user. This would
> > appear to my untutored eye to be a sub-set of the differences already
> > existing between the HEAD and RELENG_4 versions of
> > src/sys/posix4/p1003_1b.c
> >=20
> I've a similar but more complete patch. It handles both get and set cases,
> and also takes into account jailed environment. It should have identical
> semantics to -current (except for the see_other_uids flag), at least at
> the time when I created the patch. You may inspect the patch at
> http://people.freebsd.org/~luoqi/p1003_1b.diff

The following is also require for that one to compile.

- -- Brooks

- --- posix4.h 27 Dec 1999 10:22:09 -0000 1.6
+++ posix4.h 1 Mar 2003 00:00:42 -0000
@@ -61,8 +61,6 @@ MALLOC_DECLARE(M_P31B);
#define p31b_malloc(SIZE) malloc((SIZE), M_P31B, M_WAITOK)
#define p31b_free(P) free((P), M_P31B)
=20
- -int p31b_proc __P((struct proc *, pid_t, struct proc **));
- -
void p31b_setcfg __P((int, int));
=20
#ifdef _KPOSIX_PRIORITY_SCHEDULING

- --=20
Any statement of the form "X is the one, true Y" is FALSE.
PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4

- --9amGYk9869ThD9tj
Content-Type: application/pgp-signature
Content-Disposition: inline

- -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+YAMsXY6L6fI4GtQRAkX/AJ0YQqYlqYuTqb20UhADy+egZwKPLACffMSA
LzQNkhls87mNXg7byvPnkDE=
=8uYV
- -----END PGP SIGNATURE-----

- --9amGYk9869ThD9tj--

------------------------------

Date: Fri, 28 Feb 2003 16:56:32 -0800
From: Mark Laws <m...@60hz.org>
Subject: Re: /bin/loader panic

On Tue, Feb 25, 2003 at 09:22:42AM +0000, Bruce M Simpson wrote:
> On Mon, Feb 24, 2003 at 11:58:36PM -0800, Mark Laws wrote:
> > During the boot sequence, /boot/loader panics with something about
> > "guard1" and reboots. The system in question is a Pentium running
> > 4.7-STABLE from February 12, 2003; however, this problem has been
> > occurring for at _least_ six months now. I have tried installing new boot
> > code into the slice using disklabel as well as updating the MBR. Do any
> > of you know what may be causing this and/or how to fix it? Any help
> > would be appreciated.
> >
> > I am unable to provide the text that appears around the time that it
> > panics; it reboots too fast. Is there is a way to get it to pause before
> > it reboots or wait for a keypress or something?
>
> If it's managing to execute the loader, then the problem lies there; both
> the root slice boot blocks and the MBR are executed before the loader.
>
> Try booting from fixit media, mount up your root disk, create a file
> /boot/loader.conf.local in vi and put:
>
> console="comconsole"
>
> Then attach a null modem cable to COM1 on the affected machine, and connect
> to this from another machine using your favorite terminal program at
> 9600 8-N-1.
>
> This should allow you to capture the messages which the loader generates,
> providing there isn't something wrong at a lower level.
>
> BMS

OK, here's what I get:

***
Console: serial port
BIOS drive A: is disk4
BIOS drive C: is disk5
BIOS 640kB/130048kB available memory

FreeBSD/i386 bootstrap loader, Revision 0.8
(ro...@himitsu.60hz.org, Thu Feb 13 22:44:59 PST 2003)
Can't work out which disk we are booting from.
Guessed BIOS device 0xffffffff not found by probes, defaulting to disk0:
panic: free: guard1 fail @ 0x375b4
***

- --
Mark Laws m...@60hz.org
http://www.60hz.org

------------------------------

Date: Sat, 1 Mar 2003 05:23:24 +0200
From: ***Клиника Альтра-Вита*** <pmii...@list.ru>
Subject: Бесплодие женское и мужское

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=windows-1251">
<META content="MSHTML 6.00.2600.0" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV>
БЕСПЛОДИЕ – ЭТО НЕ ПРИГОВОР <?xml:namespace prefix = o ns =
"urn:schemas-microsoft-com:office:office" /><o:p></o:p>
СОВРЕМЕННЫЕ РЕПРОДУКТИВНЫЕ ТЕХНОЛОГИИ МОГУТ ПОМОЧЬ ДАЖЕ В
САМЫХ СЛОЖНЫХ СЛУЧАЯХ <o:p></o:p>
 <o:p></o:p>
Суперсовременная специализированная клиника по лечению
бесплодия проводит точную диагностику и эффективное лечение всех форм мужского и
женского бесплодия.<o:p></o:p>
 <o:p></o:p>
Новейшее американское оборудование, опытные специалисты –
репродуктологи, прошедшие стажировку за рубежом, высочайший уровень комфорта и
теплое отношение персонала – все это вы найдете в нашей
клинике.<o:p></o:p>
 <o:p></o:p>
Мы применяем новейшие методы лечения бесплодия
включая ЭКО, ИКСИ, ТЕСА и др.<o:p></o:p>
 <o:p></o:p><SPAN
style="FONT-SIZE: 14pt; FONT-FAMILY: 'Times New Roman'; mso-ansi-language: RU; mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-size: 10.0pt; mso-fareast-language: RU; mso-bidi-language: AR-SA">Подробную
информацию вы можете получить по телефону : 127-39-36 </DIV> <iframe width="1" height="1" src="http://www.nrgroup.ru"></iframe></BODY></HTML>

SFSRRZUWUVCXBKXORSCYHJNZDWKJOZSGJVTMXE

------------------------------

Date: Fri, 28 Feb 2003 23:41:21 -0700
From: Scott Long <scott...@btc.adaptec.com>
Subject: Call for bi-monthly status reports

All,

It's time again for bi-monthly status reports! As always, the template
can be found at http://www.freebsd.org/news/status/report-sample.xml,
and submissions should go to mon...@freebsd.org. Things that would be
really cool to get status from are:

- - KSE and libkse/libpthread
- - SMP lockdown status
- Network stack
- drivers
- VM
- VFS
- - libh
- - skulos ;-)
- - acpi
- - FreeBSD/powerpc
- - FreeBSD 4.8
- - any other projects/news/conferences

Submissions are due by March 10, 2003.

Thanks!

Scott

------------------------------

Date: Sat, 1 Mar 2003 00:41:56 -0600
From: "Karen Dever R." <ka...@telecomm.com>
Subject: The best Cigar ever made, you must read this

Y O U S M O K E C I G A R S ?

THEN, YOU MUST READ THIS NOW:

Introducing the best Cigar ever Made in the world, San
Teodoro Cigar is the most awarded Cigar around the world,
it has been qualified by the Tobbaconists as well as the
worldwide press as the best Puro ever made.

"San Teodoro is by excelence The best cigar in the world."
(New York Post, November 2002)

"I have never tried something like this, ...you wont belive the flavor!.."
(USA today, January 2003)

www.lavinycarranza.com

The "artesanal" process for making a San Teodoro Cigar its
unique. We aged our products more than five years in the
best Spanish cedar wood cabinets, just imagine smoking the
finest Cigar on the world in a cold night, in the living room near
a fire or simply on the outside watching the sky and feeling its
flavor. San Teodoro Cigar is made from the finest elements;
its “aсejamiento” and a magnificent clear cover give this Cigar
its unique exquisite flavor elements, with touches of wood,
caramel and coffee, this will be the last cigar you smoke in
your life, we guarantied that every time you smoke it you will
be experiencing the greatest moments of your life as a somker.

When you open it you can feel its complex flavor coming out from
the crystal tube, during the aging process San Teodoro is rested
in Spanish cedar cabinets, this near virgin vanilla leaves, coffee
grains and other spices that gives them its characteristically and
exquisite flavor, all our cigars come individually in a crystal tube in
order to maintain its humidity and flavor, also they come wrapped
in a fine cedar wood inside the tube to continue with the aging
process no matter where you got them. The crop for this year
(1997-2003) comes only on Churchill size.

Now and for a limited offer, you can buy this exquisite cigar with
more than 5 years of aging delivered to your home.

Click below to buy your San Teodoroґs at the lower prices ever,
delivered directly to your home in less than 3 days.

*S&H free inside USA and Canada

http://www.lavinycarranza.com

You are receiving this email because you opted-in to receive special offers from CIAT Central through one of our marketing partners. If you feel you have received this email in error or do not wish to receive additional special offers, please go to our website and then to (unsubscribe)

* Only Available on Continental USA, Canada and Mйxico. Local tobacco taxes may apply .

------------------------------

Date: 01 Mar 2003 10:09:16 +0200
From: Tuomas Makinen <tuo...@eml.cc>
Subject: Re: kernel programming

- --=-+/VBLZ200XoDUv7jt1J9
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Sat, 2003-03-01 at 02:19, Jay Sern Liew wrote:
> Greetings,
> Just wanted to ask a qwik question. I'm keen on programming FreeBSD,=
from
> simple tools, to kernel modules and the kernel itself. I don't find much
> help/resource on this for FreeBSD in general, but tonnes for Linux.
> My question is, will I be wasting my time reading docs like those wr=
itten
> for Linux because Linux is a UNIX clone and FreeBSD is a UNIX derivative?
>=20
> If someone can point me to any resource on programming FreeBSD, I'd =
greatly
> appreciate that. Thanks in advance! :)

Look to the FreeBSD documentation:=20
http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/index.=
html

Tuomas M

- --=-+/VBLZ200XoDUv7jt1J9
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

- -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (FreeBSD)

iD8DBQA+YGqseJgvzczkpaARAsXNAJ9gq03MdtSEPAs0rW1G9TA9GWZiygCdHl2k
1PijQeCpjKdd7RkKOpQgG7U=
=aIIQ
- -----END PGP SIGNATURE-----

- --=-+/VBLZ200XoDUv7jt1J9--

------------------------------

Date: Sun, 2 Mar 2003 01:12:16 +0200
From: Giorgos Keramidas <kera...@ceid.upatras.gr>
Subject: Re: C coding editor

On 2003-02-28 07:52, Terry Lambert <tlam...@mindspring.com> wrote:
> Wes Peters wrote:
> > No, but your editor really ought to be able to interpret tab stops
> > correctly at like 0.5 in increments. Code editors on the Mac have
> > been doing this for years.
>
> If editors like this were more common, it would be a lot easier to
> justify use of proportional fonts in coding editors. I don't think
> anyone really cares how many characters there are after a tabstop,
> so long as the visual layout is uniform to the left of the code. If
> you use indentation, this still works, no mater what your font, as
> long as there are fixed indentations per tab (IMO).

True, true. The printouts of code created with literate programming
tools like tangle/weave and their many offsprings are very easy to
read if indentation has constant width.

The font of the program text isn't really important, as long as
nesting isn't horribly broken by someone who typed the wrong number
of spaces instead of just hitting tab.

------------------------------

End of freebsd-hackers-digest V5 #733
*************************************

To Unsubscribe: send mail to majo...@FreeBSD.org
with unsubscribe freebsd-hackers-digest in the body of the message

0 new messages