[9fans] handling tabs in text frames

[9fans] handling tabs in text frames

[Francisco J Ballesteros]

Hi,

I'm considering an alternative to the current tab behaviour in text frames.
I'm tired of adding/removing tabs to keep adt declarations aligned, and I think
the machine should do it, not me. Thus, for a experimental implementation
for text frames I'm playing with now, I plan
to implement tab handling  as follows:

1.
Tabs get a default width, say 4 chars, but their actual width depends
on what is found
on lines of text before and after the tab considered. That is, their
width will grow to
actually tabulate the text shown.
For example, the tabs in
a \t b
c \t d
e \t f \t g
will make three aligned columns, no matter the widths of a ... g.

2.
Tabs right after a new line will be a exception in that why will have
a fixed width and will
not be subject to this rule.

One minor detail is that my aim is to make empty lines boundaries
regarding tabulation,
so that not all the file has to be tabulated according to the same widths.

I'd like to hear what others think regarding this behaviour before
actually implementing
it.

thanks

Re: [9fans] handling tabs in text frames

[erik quanstrom]

> Hi,
> 
> I'm considering an alternative to the current tab behaviour in text frames.
> I'm tired of adding/removing tabs to keep adt declarations aligned, and I think
> the machine should do it, not me. Thus, for a experimental implementation
> for text frames I'm playing with now, I plan
> to implement tab handling  as follows:

i think it will be hard to make other formatting work.  sometimes two tabs mean
that things didn't quite line up with one tab.  sometimes they mean skip a field.

it's hard being incompatable.  even when it's better.  maybe hueristics will be
"good enough".

- erik

p.s.  tabs are 8 spaces. ;-)

Re: [9fans] handling tabs in text frames

[Anthony Sorace]

On 8/26/07, erik quanstrom <quanstro@quanstro.net> wrote:

> p.s.  tabs are 8 spaces. ;-)

tabs are tabs. spaces are spaces.

seriously: i'm less concerned about what actual visual representation
is used (i like 4-space equivalent, 8 wouldn't make me upset, and
leaving it user-specified is lovely), but it's important that whatever
you're doing not mess around with the actual character strings in the
stream.

i agree tab handling is imperfect and often frustrating (especially
when working with people who code in variable-width fonts, which,
personally, still seems a bit odd to me) and that programs could do
more for me there, but i have a hard time coming up with consistent
rules i'd like to see implemented.

Re: [9fans] handling tabs in text frames

[erik quanstrom]

> i agree tab handling is imperfect and often frustrating (especially
> when working with people who code in variable-width fonts, which,
> personally, still seems a bit odd to me) [...]

why?  no one reads books in fixed-pitch type.
just because teletypes did it, isn't a compelling
reason to continue the tradition on bit-mapped
displays.

part of the reason that 8-space-width tabs
(or whatever) seem wide with a fixed-pitch font
is that fixed-pitch fonts have to squeeze `W' into
the same space as `i.'

- erik

Re: [9fans] handling tabs in text frames

[Uriel]

When I first read rob calling coding in variable-width fonts
'liberating' I was skeptical, but with time (and acme) I have come to
understand his point of view;  when you are forced to stop worrying
about character width, writing code becomes much more like writing
prose and you actually have one less thing to worry about. Sadly I'm
still sometimes distracted trying to get everything to align 'right',
but that is more my fault for not being able to give up control over
tedious details.

I like nemo's idea for tabs, but I agree with erik that it will be
hard to make it work in practice given how much text out there will
probably become messed up, you could add yet another toggle to
enable/disable this, but that would create yet another thing one has
to worry about fiddling with, having to worry about eight or four
space tabs is already painful enough.

Best wishes

uriel

P.S.: I wonder how 'liberating' rob finds the 'two spaces indentation'
policy at google ;)

On 8/27/07, erik quanstrom <quanstro@quanstro.net> wrote:
> > i agree tab handling is imperfect and often frustrating (especially
> > when working with people who code in variable-width fonts, which,
> > personally, still seems a bit odd to me) [...]
>
> why?  no one reads books in fixed-pitch type.
> just because teletypes did it, isn't a compelling
> reason to continue the tradition on bit-mapped
> displays.
>
> part of the reason that 8-space-width tabs
> (or whatever) seem wide with a fixed-pitch font
> is that fixed-pitch fonts have to squeeze `W' into
> the same space as `i.'
>
> - erik
>

Re: [9fans] handling tabs in text frames

[Anthony Sorace]

On 8/26/07, erik quanstrom <quanstro@quanstro.net> wrote:
> > i agree tab handling is imperfect and often frustrating
>> (especially when working with people who code in
>> variable-width fonts, which, personally, still seems a bit
>> odd to me) [...]
>
> why?

no good reason. intellectually, i entirely agree with your arguments.
emotionally, however, i just still find it jarring. much less so than
i did even a few years ago (thanks, like uriel says, to acme)

i'm less concerned about existing text getting messed up, provided you
do something sensible (read: very much like what is done today) with
the common case of beginning a paragraph with a tab. beyond that,
aligning tabs is already wrong frequently enough when dealing with
text from one environment in even a slightly different one that i
don't think the new marginal incorrect cases would be too bad.

Re: [9fans] handling tabs in text frames

[lucio]

> I'd like to hear what others think regarding this behaviour before
> actually implementing
> it.

I think you ought to just go for it.  I know that the present
implementation of tabs is inadequate, but enough of a convention for
everyone to have adjusted to it.  A new implementation will either be
easier or more difficult to get tuned into and only time will tell
which one applies.  That's what happens when the object of one's
attention is capable of extraordinary feats of adaptability.

As for the proposal itself, it sounds useful, very much so.  Is it
likely that you'll be able to default the traditional tab expansion
(8-space _equivalent_ I have to partially agree with Erik) for
fixed-width font and the new technique for variable width font, with a
switch to select the alternative?

++L

PS: Personally, I think my next "alphabet" will have no such concept
as "tabs", when last did anyone get a typewriter to work properly with
those in the first place?  So why do we carry the concept where it
belongs even less?

Re: [9fans] handling tabs in text frames

[y i y u s]

> I'm considering an alternative to the current tab behaviour in text frames.
...


I just found this one, I think it is what you want to implement. It
looks very useful to me:
http://nickgravgaard.com/elastictabstops/

regards to the list (my first post after months quietly listening...),

--


- yiyus || JGL .