On Fri, Aug 23, 2002 at 08:59:36AM +0200, Ketil Z. Malde wrote:

Ashley Yakeley writes:

...

At 2002-08-21 03:42, Sven Moritz Hallberg wrote:

...

...

variable-width characters: Unicode specifically doesn't say anything about the glyph representation of the characters.

...

Some characters are considered "half-width", see UTR #11.

What a mess!

I think at this point I'll suggest that the indentation column is defined as the number of Chars, and to hell with character widths -- if you need to have Chinese identifiers, then use an editor which understands layout properly.

I don't recommend using Unicode's notion of half-width/full-width; for one thing, there are some very odd choices due to historical brokenness; e.g., some greek letters are full-width. But I also really don't recommend using the number of Chars as any sort of measure of the width. That can be extremely misleading. In fact, I'd recommend redoing the layout rule in a more robust way so that it will also work with, e.g., proportional fonts. Requiring a new-line before a target column is set would work. (I'd go further and require that the leading white-space always be identical, not just get you to the same column. Tabs are not always equal to 8 spaces...) Best, Dylan Thurston

Dylan Thurston writes:

In fact, I'd recommend redoing the layout rule in a more robust way so that it will also work with, e.g., proportional fonts. Requiring a new-line before a target column is set would work.

Just want to be clear about what you mean here. I think you're saying that code like: case x of Left _ -> False Right _ -> True should be disallowed (we should require a newline after 'of'). I hope you're not saying that we should count pixels occupied by proporional fonts. This would be a bad idea because different machines might assign different widths to the same character.

(I'd go further and require that the leading white-space always be identical, not just get you to the same column. Tabs are not always equal to 8 spaces...)

Your suggestion reminds me very strongly of Makefiles. Makefiles make a huge distinction between tabs and spaces. My editor makes tabs and spaces look the same. So does cat, less, lpr, enscript and every other tool I know. The result is that when I write a bad Makefile I have a hell of a time debugging it because the code looks fine. [I vaguely remember similar problems if the last rule in your file doesn't end in a newline.] Let's not even think about following Make's example here. If we feel a need to fix this problem in Haskell, the best choice seems to be to say that tabs are not allowed in Haskell. That way, everyone will use a preprocessor appropriate to their local environment to generate legal Haskell code. [This may just be the reaction of an emacs user. Emacs largely takes the view that tabs are a weak file compression technique. When I hit the TAB key, emacs figures out which column I want to be in (e.g., which may vary when editing Perl code, Linux kernel code, Hugs C code, Haskell, etc.) and moves there. If I want, emacs will use a tab character to encode 8 spaces when saving to file or it will use space characters. As a result, I lean towards the belief that pressing the TAB key will only generate a TAB in the file if my tabs are 8 spaces. Obviously, not all editors can be configured to behave the same way.] -- Alastair Reid alastair@reid-consulting-uk.ltd.uk Reid Consulting (UK) Limited http://www.reid-consulting-uk.ltd.uk/alastair/