Subject: RE: [hackers-il] An observation about standards compliance in clo sed software vs. open source

From: Chen Shapira <[email-masked]>
Date: Sun, 8 Jul 2001 15:46:58 +0200

> could you give an example, please?

I thought I just did. But in any case, if you write a program, take an hour
or two to figure out good defaults for all options.
Which data should be shown by default? what should be the default font?
Small things like that.
Don't be lazy and think that the user can configure it, he can, but he'll be
happier if he won't have to.
 
> > Case study:
> > I tried to print code in emacs, emacs cut off any character 
> after the 80th
> > in line.
> > I couldn't find out how to show column numbers so I could 
> see where is it
> > going to cut.
> 
> m-x column-number-mode

:-) Thanks.

> > I also couldn't force the printer to wrap. Do note that I 
> had less than 15
> > minutes to do so.
> 
> first of all, why print from emacs, in this case? 

Beats the hell out of me.
I was working in emacs, and there was that "print" button, and I needed that
printout, so it seemed like a good idea at the time 

> second of 
> all, why not
> write a simple shell script  (or perl script, or python, whatever) to
> simply wrap any line over 80 characters?

Because I have no idea how to do that.
I know perl a bit, so I could try, but it was 15 minutes before a test, and
I was in a hurry.
The idea actually didn't come to my mind. 

> 
> when faced with a similar problem (printer's toner was shot 
> to hell and
> didn't print the first 10 characters on a each line) and a 10 page
> homework assignemnt, i wrote a two liner perl script to add 
> 10 spaces at
> the front of each line. worked like a charm and took all of three
> minutes.

Ok, OK, I'll study perl.
But its still no excuse for emacs cutting lines.

My point is not that those problems have no solutions, they have many
solutions, but the fact that they exist make emacs a bit less useful.

Emacs as a program will be a better program if it didn't cut lines when
printing.
Since I use Emacs, I wish it was better.
 
> yes, i do have a point - if one tool sucks, use a different  
> tool better
> fitted for the task at hand. no tool will ever be perfect for 
> everyone,
> which means you are better off writing your own *perfect* 
> little tools.
> imho.

I agree that no tool can be perfect, but many could be made better. The less
I have to write my own tools the happier I am with existing ones.

Look, Notepad doesn't show line numbers.
I often work in enviroments where I can only use notepad, and I need to find
line 549, so I wrote a small VB widjet that adds numbers to notepad.
Still Notepad would have been a better tool if it did that for me.

> > 2) Every programming mode (C/C++/JAVA etc.) should show 
> line and column
> > number by default.
> 
> a bit of elisp in your .emacs file should take care of it. not the
> easiest way to do it, and requires knowing elisp, but *the most
> extensible* way of doing it.

I agree, but I still think good defaults are worth thinking about.
Do make everything configurable, and give many many options, and have a
scripting language around, but still spend the time to think of the user.
Sometimes the right thing is obvious, sometimes it isn't, but if the right
thing is obvious - it better be a default.

> by making something "work" for you, isn't it conceivable that you are
> breaking it for somebody else? i, for example, find line numbers
> essential and column numbers annoying.

I still think that good defaults are essential.
Look, I think we can agree that every programmer in the world will need line
numbers, right? GCC report errors by line numbers.
So why isn't it in C mode? Every single C programmer will need it, but it
isn't there!
BTW, I agree with you about column numbers, they annoy me too (mostly
because I confuse them with line numbers).
I wouldn't need them if GCC didn't chop my lines at the printer.
I think that if Emacs cares about column numbers, he should show them
(perhaps on "print preview" mode?).
In anycase, I should have an easy way to find out it *can* show the damn
numbers, and sadly both menu's and help are pretty broken in this respect.

> i prefer an infinitely extensible tool to an 'easy to use' 
> tool. because
> what's easy to use for you may be completely incomprehensible to me.

*sigh*.

OK, I promise this is the last time I say this:
You leave the exect same power. Same elisp, same everything. don't take away
one bit of useful options.
Only have users test the menus and let a professional design them, and spend
few hours to think of good defaults.

you don't take away anything, but you possibly helped many people.

I'll repeate myself: Have good defaults in addition to powerful
configuration and scripting.

Thanks,
Chen.

---

From: "Nadav Har'El" <[email-masked]>
Date: Sun, 8 Jul 2001 18:24:33 +0300

> Which data should be shown by default? what should be the default font?

There's a problem with what you're saying. Emacs (and better, XEmacs)
*already* has defaults. Whether or not these defaults are good is debatable.
Certainly, the Emacs/XEmacs developers thought that the defaults they put
were good.

They, for example, decided that column numbers should not be the default.
Almost nobody except Fortran programmers (and people who don't know how to
print ;)) care about them. So they are not default, and can be enabled
with a command (M-x column-number-mode), a menu operation (Options ->
Frame Appearance -> Column Numbers in XEmacs), or permanently by adding
a suitable command to your ~/.emacs.

The problem is that each person has his or her own set of favorite commands
and options. There are hundreds of possible operations and settings, and it
is impossible to make them all default, and all appear in the default menu.
The developers have to choose operations which are more easily accessible, but
make all the other operations slightly less accessible, but completely
accessible to someone who bothers to spend an hour learning to use the tool
(for example, in XEmacs your friend is M-x hyper-apropos - type "column" and
look for lines with "*" (commands).

By the way, you shouldn't have any of the printing problems you describe -
just use M-x ps-print-buffer-with-faces, and look at the nice results. Again,
M-x hyper-apropos and typing "print" would find you this.

> happier if he won't have to.

Nobody argues with that statement: all programs should (and in my opinion,
do) have good defaults. But they'll never be good for everybody. Once you
take the hour (or day) to learn how to configure the tool, and configure it
to your every whim (e.g., I didn't like the color of the comments in XEmacs
and wanted to change it) you'll never be sorry, and your usage of the tool
would be forever more efficient. I have over 1000 lines of lisp code in my
XEmacs configuration, but I wrote most of them 7 years ago, and since then
I've been enjoying an editor fitting my wishes perfectly. That day I "wasted"
7 years ago is now long forgotten, but its benefits are emence.

> printout, so it seemed like a good idea at the time 

Yes, that's an example of a really lousy default in XEmacs - the print button
doing the File -> Print Buffer instead of File -> Pretty Print Buffer (the
latter is what you should do on a postscript printer - the former just dumps
the text on the printer). In my configuration I changed the action of the
"print" button.

> But its still no excuse for emacs cutting lines.

It doesn't. It's your printer. Don't use "print buffer" - it's as simple
as that. Again, I agree, the "print buffer" is a pretty stupid operation
to have enabled by default...

> numbers, right? GCC report errors by line numbers.

I don't agree!!! I never want to see line numbers. Line numbers are
meaningless, most of the time when I'm programming. When I have an error
and want to see a line with some number, I use ALT-G (goto line). When I want
to know (for some crazy reason) what line I'm on, being the vi junky that I
am, I have written a command that mimics vi's ^G, which I bind to ALT-P:

[sorry it's so long - people more proficient in lisp than me could probably
write it in a more efficient manner]

;; my version of what-cursor-position
;; this could probably be simplified (there are really 2 cases, not 4, etc.)
(defun nyh-position ()
  "Print info on cursor position (on screen and within buffer)."
  (interactive "_")
  (let* ((char (following-char))
         (beg (point-min))
         (end (point-max))
         (pos (point))
         (total (buffer-size))
         (nline (save-restriction
                  (widen)
                  (save-excursion
                    (beginning-of-line)
                    (1+ (count-lines (point-min) (point)))
                    )))
         (percent (if (> total 50000)
                      ;; Avoid overflow from multiplying by 100!
                      (/ (+ (/ total 200) (1- pos)) (max (/ total 100) 1))
                    (/ (+ (/ total 2) (* 100 (1- pos))) (max total 1))))
         (hscroll (if (= (window-hscroll) 0)
                      ""
                    (format " Hscroll=%d" (window-hscroll))))
         ;; the 1+ is so that our column number is the same as the one
         ;; shown by column-number-mode, and vi's ^G.
         (col (1+ (current-column))))
    (if (= pos end)
        (if (or (/= beg 1) (/= end (1+ total)))
            (message "\"%s\" line %d/%d byte %d/%d %d%% <%d - %d> column %d %s"
                     (buffer-file-name)
                     nline
                     (count-lines (point-min) (point-max))
                     pos total percent
                     beg end col
                     hscroll)
          (message "\"%s\" line %d/%d byte %d/%d %d%% column %d %s"
                   (buffer-file-name)
                   nline
                   (count-lines (point-min) (point-max))
                   pos total percent
                   col
                   hscroll))
      (if (or (/= beg 1) (/= end (1+ total)))
          (message "\"%s\" line %d/%d byte %d/%d %d%% <%d - %d> column %d %s"
                 (buffer-file-name)
                 nline
                 (count-lines (point-min) (point-max))
                 pos total percent
                 beg end col
                 hscroll)
        (message "\"%s\" line %d/%d byte %d/%d %d%% column %d %s"
                 (buffer-file-name)
                 nline
                 (count-lines (point-min) (point-max))
                 pos total percent
                 col
                 hscroll)))))

(global-set-key '(meta p)      'nyh-position)

> So why isn't it in C mode? Every single C programmer will need it, but it

Again, it is there, even on the menu (at least in XEmacs): options ->
Frame Appearance -> Line Numbers.

> > what's easy to use for you may be completely incomprehensible to me.

Actually, Emacs *is* an easy-to-use extensible tool. When you consider vi,
emacs *is* easy to use for beginners (every simple operation can be done
with pointing and clicking with the mouse). And when you consider things
that came before vi, like 'ed', vi is easy to use too ;) (I knew a person
who used ed before vi was invented, and got so used to this incredibly
unintuitive editor that he refused to switch to vi...)

> configuration and scripting.

Again, they *think* they already did that. If you find something bad with
their defaults, maybe you should tell them about it?
Or write elisp code to change the defaults and distribute it as
a Chens-wonderful-defaults-solve-your-every-emacs-problem.el package.

-- 
Nadav Har'El                        |      Sunday, Jul  8 2001, 17 Tammuz 5761
[email-masked]             |-----------------------------------------
Phone: +972-53-245868, ICQ 13349191 |Someone offered you a cute little quote
http://nadav.harel.org.il           |for your signature? JUST SAY NO!

---

From: "Nadav Har'El" <[email-masked]>
Date: Sun, 8 Jul 2001 18:54:37 +0300

On Sun, Jul 08, 2001, Nadav Har'El wrote about "Re: [hackers-il] An observation about standards compliance in clo sed software vs. open source":
>...

Sorry, I see there's already a what-line command which prints the current line
(it's not bound to any key on XEmacs, so you just do M-x what-line.)
Not as "suphisticated" as my nyh-position (it only prints the line, not the
full filename, total number of lines and byte number like mine does), but
probably enough for most people.

-- 
Nadav Har'El                        |      Sunday, Jul  8 2001, 18 Tammuz 5761
[email-masked]             |-----------------------------------------
Phone: +972-53-245868, ICQ 13349191 |How do you get holy water? Boil the hell
http://nadav.harel.org.il           |out of it.

---

From: Oleg Goldshmidt <[email-masked]>
Date: 10 Jul 2001 08:54:22 -0400

"Nadav Har'El" <[email-masked]> writes:
 
> Sorry, I see there's already a what-line command 

Why don't you just toggle line-number-mode? You'll see the current
line number in the mode line, and it's unobtrusive enough even for a 
purist like you ;-)

-- 
Oleg Goldshmidt | [email-masked] 
If it aint't broken it hasn't got enough features yet.