[9fans] handling tabs in text frames - Plan9

This is a discussion on [9fans] handling tabs in text frames - Plan9 ; 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 ...

+ Reply to Thread
Results 1 to 8 of 8

Thread: [9fans] handling tabs in text frames

  1. [9fans] handling tabs in text frames

    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

  2. Re: [9fans] handling tabs in text frames

    > 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. ;-)

  3. Re: [9fans] handling tabs in text frames

    On 8/26/07, erik quanstrom 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.

  4. Re: [9fans] handling tabs in text frames

    > 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

  5. Re: [9fans] handling tabs in text frames

    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 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
    >


  6. Re: [9fans] handling tabs in text frames

    On 8/26/07, erik quanstrom 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.

  7. Re: [9fans] handling tabs in text frames

    > 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?


  8. Re: [9fans] handling tabs in text frames

    > 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 .

+ Reply to Thread