I hate you all

Steven D'Aprano steve+comp.lang.python at pearwood.info
Tue Apr 9 01:19:11 EDT 2013


On Mon, 08 Apr 2013 21:06:42 -0700, rusi wrote:

> On Apr 9, 7:51 am, Steven D'Aprano <steve
> +comp.lang.pyt... at pearwood.info> wrote:
>> On Mon, 08 Apr 2013 19:43:51 +0100, Nobody wrote:
>> > On Sun, 07 Apr 2013 01:30:45 +0000, Steven D'Aprano wrote:
>>
>> >> Am I the only one here who has used a typewriter?
>>
>> >> Tab stops were set manually, to a physical distance into the page,
>> >> using a mechanical stop. This long predates the "rule" that tab
>> >> stops are every 8 characters.
>>
>> > And your point is?
>>
>> > Typewriters don't have a tab "character". The information regarding
>> > tab stops is conveyed out-of-band from the typist to the typewriter,
>> > and doesn't need to persist beyond the time taken to type the
>> > document.
>>
>> Both text editors and typewriters encode information about tab settings
>> out of band. Editors encode that information in some combination of
>> program configuration, command-line switches, environment variables,
>> and embedded mode lines in the document itself. Typewriters encode that
>> information in the typists' memory, or failing that, in the actual
>> physical space left on the page. That's a difference that makes no
>> difference.
>>
>> My point is that there were well-established semantics for what a tab
>> should do, and the "8 character tab" is not that. Pressing the tab key
>> on a keyboard while entering text ought to instruct the editor to
>> advance to a specified tab stop capable of being set anywhere on the
>> page. Word processors use that model: the word processor stores the
>> positions of the tab stops out of band, usually in the "paragraph
>> formatting" or "style sheet", but in principle they could keep the
>> position of the tab stops global to the document or even global to the
>> application.
> 
> Dunno what you mean by 'out-of-band'

I mean that the information about the tab stops are not inherent to the 
tab itself.


> If I set tabstops for a para to say 4-13-25-36 in a wordprocessor, save
> the file and look inside, I will find the tuple (4,13,25,36) in some
> encoded form.

There's nothing about the *tab character itself* that says "jump to 
column 25". That information is metadata, stored external to the tab. 
That doesn't necessarily mean external to the file. A word-processing 
file carries a lot of metadata about the document.

A plain text file is a better example. If I type up a document in (say) 
OpenOffice and use tabs to align a table, I might manually set the tabs 
to 4cm, 9cm, 18cm. When I hit tab, the cursor will jump to (say) 18cm, 
but if I save the document as plain text, that information is not stored 
anywhere in the document. It may be encoded in the OpenOffice config, 
e.g. in the "Normal" stylesheet.

The same applies for documents created in a text editor, say Vim or 
Emacs. They may store the metadata about tab settings as mode lines in 
the document, or in an environment variable, or in a config file, or 
perhaps nowhere at all. Just like a typewriter.


> For a typewritten page, if the margin seems to be at 11th col, the
> reader cannot know from the page alone whether the typist 1. set the tab
> at 11
> 2. set the tab at 8 and pressed TAB followed by 3 SPC 3. Started with 2
> and switched to 1

Very true. Manual typewriters are not identical to text editors. 
Typewriters can do both more *and* less than text editors. E.g. you can 
compose extra symbols by backspacing and overtyping, but you cannot 
usually distinguish between space-tab and space-space-tab.

But from the perspective of "duplicate what you see on the page", the 
difference between space-tab and space-space-tab does not matter. What 
matters is where you end up, not how you get there.



-- 
Steven



More information about the Python-list mailing list