Re: `current-column', column count in general is broken.

The following message is a courtesy copy of an article that has been posted to comp.emacs.xemacs as well. I don't think we can do anything about this for 21.4. We should think carefully about how to handle it in the future. Le> The documentation for `current-column'. It clearly states Le> that control charactes have a width of 2 or 4. A conflict between documentation and behavior is a bug. You should use M-x report-emacs-bug in this case: you are likely to get faster and more useful answers that way. On any channel, you can increase both probability and speed of useful answers by writing[1] """According to the documentation for <name of object here> <cut and paste docstring here> But the following recipe <exact quote here>, which should <describe the expected effect> gives the unexpected answer <exact quote here>.""" Eg: ------------------------------------------------------------------------ The documentation for current-column states in part: Return the horizontal position of point. Beginning of line is column 0. This is calculated by adding together the widths of all the displayed representations of the character between the start of the previous line and point. (e.g. control characters will have a width of 2 or 4, tabs will have a variable width.) However executing (progn (beginning-of-line) (insert (int-to-char 1)) (current-column)) gives 1, where I expected 2. ------------------------------------------------------------------------ Le> the point is that the width of control characters should be 2. Unfortunately, this whole idea is broken by design. It can't possibly work with proportional fonts, for one thing. It typically fails badly with multiple faces or with mixed charsets, too. Currently the implementation expands tabs to an integral number of spaces; that's about the best you can do in general unless you seriously restrict the flexibility of the face mechanism. Fortunately, that's all you really need for code indentation. With the current 21.4 code, getting this right (even for the case you presumably have in mind, character cell terminals) requires a lot of analysis of how redisplay works. So don't expect it in 21.4. The following hack probably works for you. It's not acceptable in general for the reasons that the comments hint at (and they're only the ones that happen to be paged in to wetware). (defun column-at-hack (&optional pos buf) "Guess the display column for the character at POS. POS defaults to the current value of point, BUF to the current buffer." (save-excursion (if buf (set-buffer buf)) (if pos (goto-char pos)) (beginning-of-line) (let ((col (if column-number-start-at-one 1 0))) (while (< (point) pos) (let* ((ch (char-after (point))) (chint (char-to-int ch)) ;; This does not do the right thing with values of ctl-arrow ;; other than nil and t. It does not respect display tables, ;; if any are in effect. (ctlwidth (if ctl-arrow 2 4))) (setq col (+ col (cond ((< ch 32) ctlwidth) ((< ch 127) 1) ((= ch 127) ctlwidth) ((< ch 160) 4) ;; this fails for several ISO-8859 sets ;; as well as for ASCII-only fonts ((< ch 255) 1) ;; hack which works for all character cell ;; fonts I know of but need not be correct ((fboundp char-width) (char-width ch))))))) col))) Footnotes: [1] I'm going into detail because I'm x-posting to xemacs-beta, not because I think you can't figure it out for yourself. It will end up in the faq and other useful places this way. -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN My nostalgia for Icon makes me forget about any of the bad things. I don't have much nostalgia for Perl, so its faults I remember. Scott Gilbert c.l.py